Migration Checklist: Moving to Mailchimp

Phase 0

Decide & Plan

Lock scope, audience model, and cutover window before any data moves.

• Define migration scope by Mailchimp object. List every object in scope: contacts (email + SMS), audiences, tags, groups, segments, merge fields, customer journeys, classic automations, campaign archives, templates, signup forms, landing pages, and e-commerce store data. Mark each as in-scope or out-of-scope in writing.

  Risk if skipped: Unscoped objects (especially e-commerce stores and customer journeys) surface mid-migration and extend the freeze window.

• Decide the audience model: single audience vs multiple audiences. Mailchimp bills per contact, and duplicates across audiences each count separately. Decide whether to consolidate into one primary audience with tags and groups, or keep separate audiences for distinct business units. This decision drives every downstream mapping step.

  Risk if skipped: Carrying over the source's audience sprawl inflates the contact bill from day one and prevents Mailchimp's default dedup from working across audiences.

• Decide historical-engagement scope and time horizon. Pick a hard cutoff for opens, clicks, and campaign history (for example: last 24 months). Source engagement metrics do not import natively into Mailchimp's reports — decide whether to preserve them in custom merge fields, attach as tags, or drop.
• Confirm Mailchimp plan tier and contact ceiling. Free, Essentials, Standard, and Premium have different contact ceilings (250 / 50,000 / 100,000 / higher) and per-audience limits (1 / 3 / 5 / unlimited). Importing past the ceiling forces an upgrade or blocks sends.

  Risk if skipped: Crossing the contact ceiling places a hold on live sends until the bill is upgraded.

• Decide whether Mandrill transactional sending is in scope. Mandrill is a separate product with separate billing. If transactional email is part of the move, plan it as a parallel workstream — credentials, templates, and dedicated IP setup do not transfer from the marketing side.

  Risk if skipped: Treating transactional and marketing as one project conflates two pricing models and two sending surfaces, breaking both.

• Choose the upsert key for contacts. Mailchimp uses lowercase email as the primary key. Decide how to handle source records with missing or duplicate emails — drop, hold for manual review, or assign synthetic addresses for SMS-only contacts.
• Document success criteria for the migration. Define falsifiable tests: per-audience contact counts, tag coverage match, merge-field population rate, campaign archive parity, customer journey re-creation completeness, and UAT sign-off from a named owner.
• Set the cutover date, source-system freeze window, and rollback gate. Pick the date when the old platform goes read-only, the cutover window itself, and the hour by which a no-go call must be made if validation fails.

  Risk if skipped: Without a pre-agreed rollback gate, partial loads get pushed through and create reconciliation work that takes weeks.

• Identify legal and compliance constraints. Capture GDPR consent records that must accompany EU contacts, CAN-SPAM unsubscribe lists, CASL express consent timestamps, and any retention or residency rules. Mailchimp is SOC 2 and GDPR-compliant but is NOT HIPAA-compliant — protected health information cannot move into Mailchimp.

  Risk if skipped: Loading PHI into Mailchimp violates HIPAA and forces a forensic deletion.

• Document explicit out-of-scope items. Write down what is NOT migrating (cold contacts older than X, unsubscribed contacts beyond the legally required suppression list, dormant audiences, deprecated automations) so it does not creep back in.

Phase 1

Pre-Migration Prep

Clean the source and build the destination audience schema before any export.

Phase 2

Source Export

Pull every object out of the source in a form you can transform.

• Export all subscribed contacts to CSV with every standard and custom field. Include email, first name, last name, every custom field, source platform's ID (as a future external_id reference), opt-in date, opt-in source, and last-engagement date.
• Export unsubscribed, bounced, and spam-complaint contacts as separate files. These load to Mailchimp as suppressions BEFORE the active list. Capture original unsubscribe timestamps for compliance audit.

  Risk if skipped: Mixing suppressions into the active import re-subscribes people who legally must stay unsubscribed.

• Export SMS contacts as a separate file with E.164 phone numbers. Mailchimp SMS contacts are a separate flow with their own consent requirements. Capture SMS opt-in timestamp and source separately from email opt-in.
• Export the tag-to-contact map. For every tag, list every contact (by email) that carries it. Tags with commas must be wrapped in double quotes when included in the import file.
• Export group memberships as group category + group name columns. Each group category becomes one column in the import file. Multi-group membership uses a comma-and-space separator within the cell.
• Export every active automation, sequence, drip, or journey definition. Mailchimp Customer Journeys do not import from other platforms — capture the source automation logic (triggers, conditions, delays, email content, exit criteria) as documentation for manual rebuild in Phase 7.

  Risk if skipped: Without exported automation documentation, business-critical drip logic is lost on cutover and has to be reverse-engineered from inbox examples.

• Export campaign archives (HTML, subject, send date, recipient counts, opens, clicks). Capture the full HTML of every campaign sent in the historical window decided in Phase 0. Mailchimp will not import historical campaign reports — store them as flat files or in a data warehouse.
• Export email templates as HTML files. Capture every active template from the source as a standalone HTML file with inline CSS. These get re-imported via Mailchimp's Template editor in Phase 7.
• Export signup form definitions and embed codes. Signup forms are rebuilt manually in Mailchimp's Forms builder. Capture field lists, validation rules, post-signup redirect URLs, and any tag-assignment logic from each source form.
• Export e-commerce store data if applicable: customers, products, orders, carts. For each store: customer list (email, total spend, order count), product catalog (SKU, name, price, images), order history (order_id, customer_id, products, totals, timestamps), and abandoned-cart records if surviving.
• Export user list with roles and seat assignments. Capture every active user with their email, role (Owner, Admin, Author, Viewer), and which audiences they own. Mailchimp seat counts vary by plan — confirm headcount fits.
• Capture screenshots and config exports of source reports and dashboards. Mailchimp's reporting differs from most source platforms. Document which source reports must be reproduced and the source-side filters used.
• Document the exact timestamp of every export. Record export start and end times per file. This is the delta anchor for the final cutover export in Phase 5.

  Risk if skipped: Without timestamps, the cutover delta export cannot reliably identify rows added or changed during the freeze window.

Phase 3

Transform & Map

Decide how every source field maps and produce Mailchimp-shaped files.

Phase 4

Sandbox Test Migration

Catch every problem in the test account before it costs you in production.

• Load a 1–5% representative sample of contacts into the sandbox account. Sample must cover every audience, every tag, every group, every merge-field permutation, and every encoding edge case (multi-byte names, very long values, special characters in tags).
• Validate field-by-field on 10–20 random sandbox contacts. For each random contact: open the profile page, compare every visible field to the source row. Look for truncation, wrong encoding, swapped first/last names, mismatched dates.

  Risk if skipped: Skipping per-field validation lets silent encoding or type-coercion bugs into production.

• Test the import of a contact with multi-byte characters in every text field. Load a test contact with emoji, Chinese characters, Arabic, and Latin accents in name and merge fields. Confirm Mailchimp displays them correctly and that 255-byte truncation didn't corrupt them.
• Test tag assignment with comma-containing tag names. Load a contact with a tag like 'Monday, Wednesday' wrapped in double quotes. Confirm Mailchimp creates one tag, not two.
• Test group membership across multiple groups. Load a contact assigned to three groups within one group category, comma-space separated. Confirm all three groups show on the contact profile.
• Test the suppression-list load before the active-list load. Load unsubscribed contacts first, then attempt to load an active-list file that contains one of those unsubscribed addresses. Confirm Mailchimp skips the unsubscribed row.

  Risk if skipped: If the suppression flow does not work as expected in the sandbox, it definitely will not work in production.

• Time the sandbox loads and extrapolate to full production volume. Record load duration per 1,000 contacts. Extrapolate to total contact count to estimate cutover window length.

  Risk if skipped: Without a timing extrapolation, the cutover window can be wildly underestimated and overflow into a workday.

• Test the Combine Audiences tool if consolidating multiple audiences. Mailchimp's native Combine Audiences tool merges audiences inside the destination. Run it on two sandbox audiences and confirm tag preservation, merge-field alignment, and dedup behavior.
• Test the e-commerce store sync order end-to-end. Create store, load 10 customers, load 20 products, load 30 orders. Confirm orders correctly reference both customers and products on each line item.
• Test rebuild of one Customer Journey end-to-end in the sandbox. Pick the most critical source automation and rebuild it in Mailchimp's Customer Journey builder. Trigger it with a test contact and confirm every step fires correctly with the right delays.
• Spot-check 5–10 sandbox contacts with a domain expert from the marketing team. Have someone who knows the source data look at the sandbox records and call out anything wrong. This catches semantic errors that technical validation misses.
• Sign off the sandbox results in writing before proceeding to Phase 5. Capture sandbox load durations, error rates, validation results, and any open issues in a written report. The DRI signs off explicitly to authorize production cutover.

  Risk if skipped: Without explicit sign-off, accountability for production issues is unclear and trust in the migration is hard to rebuild.

Phase 5

Production Cutover

Execute the migration in a tightly sequenced window with idempotent operations.

• Confirm the source-system freeze with a final write-check. Pull source record counts at the start of the freeze window and again one hour later. Counts must match. If they don't, identify the writing user and lock them out before proceeding.

  Risk if skipped: Hidden writes during the freeze produce a moving target and force a re-export mid-cutover.

• Take the final delta export from the source. Capture all records changed since the Phase 2 baseline export. This is the file that authoritatively represents the production source-of-truth state at the moment of cutover.
• Apply Phase 3 transformations to the delta file. Re-run the same transformation scripts used in sandbox testing — do not write new code at cutover time. Confirm output row count matches input row count minus expected suppressions.

  Risk if skipped: Writing transformation code at cutover time introduces untested logic into the production load.

• Load the suppression list (unsubscribes, bounces, complaints) first. Import unsubscribed and cleaned contacts to each destination audience before any active-contact load. This prevents previously-opted-out people from being re-subscribed by the active load.

  Risk if skipped: Loading active contacts before suppressions can re-subscribe people who legally must stay unsubscribed.

• Load active contacts with idempotent upserts keyed by lowercased email. Use the import path that creates or updates the contact based on the email key. This is the only way to make the load safely re-runnable on partial failure.

  Risk if skipped: Insert-only loads duplicate records on re-run and force a manual cleanup pass.

• Capture every import job ID, start time, and result file URL. Persist import IDs to a log file as they return. Results from completed imports are downloadable for a limited time — capture them before they expire.

  Risk if skipped: Missing import IDs make post-load reconciliation impossible — there's no way to verify which rows succeeded.

• Load tags after contacts. Tags must reference an existing contact. Load contacts first, then push tags as a second pass keyed by email.
• Load group memberships per contact. Group categories must already exist (Phase 1b). Apply each contact's group selections in a second pass after the contact exists.
• Load e-commerce data in dependency order if applicable. Order: store → customers → products → orders → abandoned carts. Wait for each step to fully complete before starting the next.

  Risk if skipped: Loading orders before customers exist returns customer_id errors and aborts the orders batch.

• Cross-check destination row counts against expected counts after every step. After each batch completes, open the audience overview for total_count. Compare against the row count submitted. Investigate any delta before proceeding.
• Halt and diagnose on any batch with more than 1% errors. A 1% error rate signals a systematic issue, not random failures. Pause, pull the batch results, classify the errors, fix the root cause, and re-run idempotently.

  Risk if skipped: Pushing through high error rates produces a partially-loaded audience that takes weeks to clean up.

• Swap DKIM DNS records to point at Mailchimp at the planned hour. Apply the DNS swap exactly when the cutover plan calls for it. Verify SPF, DKIM, and DMARC alignment using a public mail-tester tool before the first send.
• Re-enable integrations after all data loads complete. Unpause downstream listeners only after the bulk load is done. Otherwise every loaded contact fires a subscribe event downstream.

Phase 6

Validate

Prove the migration was correct before users start sending.

Phase 7

Post-Migration Cleanup

Decommission the source, rebuild what didn't transfer, and close out the project.

• Communicate go-live to all end users with login URL and support contact. Send the announcement with the Mailchimp login URL, the account name and prefix (us1, us2, etc.), the first-responders' contact info, and links to training material.
• Run role-segmented training sessions on Mailchimp basics. Marketing: audiences, tags, segments, campaign builder. Automation owners: Customer Journey builder. Analysts: reporting and exports. Hold a live Q&A within the first week.
• Set the source system to read-only and announce the read-only date. Source is now reference-only. Users should not write to it. Communicate the read-only date and the eventual decommission date in the same message.
• Rebuild all Customer Journeys from the Phase 2 documentation. Use Mailchimp's Customer Journey builder. Activate each journey only after testing with a test contact end-to-end.

  Risk if skipped: Activating rebuilt journeys without testing can send broken or wrong content to real customers immediately.

• Rebuild signup forms in Mailchimp's Forms builder. For each source signup form, rebuild the field list, validation rules, post-signup redirect, and any tag-assignment automation. Update the form embed code on every page that used the source form.
• Rebuild campaign templates in Mailchimp's template editor. Paste each saved HTML template into the Template editor. Run a side-by-side test render against the source platform's version.
• Re-establish integrations with downstream systems. Reconnect Mailchimp to Shopify, WooCommerce, Salesforce, or other downstream platforms via Mailchimp's integration directory. Confirm bidirectional sync where applicable.
• Configure Mandrill transactional sends if applicable. Cut over transactional sends (order confirmations, password resets, receipts) to Mandrill. Test every transactional template end-to-end before retiring the source.

  Risk if skipped: Order confirmations breaking after marketing cutover damage revenue and customer trust immediately.

• Set up a graduated send-volume ramp for the first 14 days. Day 1: smallest most-engaged segment. Day 3–7: expand by engagement tier. Day 14: full audience. Monitor bounces, complaints, and open rates after every step.

  Risk if skipped: Going to full list day one from a cold domain reputation produces 20–40% spam folder placement that takes weeks to recover.

• Monitor sending reputation for 30 days post-cutover. Watch domain reputation tools and complaint rate inside Mailchimp's reports. Any spike above 0.1% complaint rate requires immediate investigation.
• Schedule a 30-day post-migration retrospective. Capture what went well, what didn't, surprise costs, and the actual vs estimated timeline. Document for the next migration.
• Document the source-system decommission date. Pick a decommission date 90+ days after cutover, after the final retention window and final reconciliation pass. Communicate to all stakeholders.
• Archive source-system exports to long-term storage. Move all Phase 2 and Phase 5 export files to encrypted long-term storage (S3 Glacier, Azure Archive, or equivalent). Retain per the data-retention policy from Phase 0.

  Risk if skipped: Source exports deleted prematurely become impossible to reproduce if a forensic question arises later.

• Close out the migration project formally. Issue a final status report, capture lessons learned, archive the project workspace, and disband the migration team. The destination is now business-as-usual.