Moving off Mailchimp: what transfers, what doesn't, and the order to do it in

Most Mailchimp migrations fail in one of two ways. Either people export a CSV, import it somewhere else, send to everyone on day one and watch their deliverability collapse. Or they stall for months because rebuilding twelve automations feels like too much to start.

Both are avoidable. This is the order that works, and an honest account of what does not come with you.

What actually transfers

Thing	Transfers?	Notes
Contacts and email addresses	✅	Clean CSV export
Tags	✅	Come through as a column, map on import
Custom fields / merge tags	✅	Map to typed fields on import
Unsubscribes and bounces	✅ and you must	See below — this is the one people forget
Templates	❌	Rebuild. No platform in this category imports another’s templates
Automations / journeys	❌	Rebuild
Signup forms	❌	Rebuild, and repoint them
Reports and historical stats	❌	Export what you want to keep as CSV first
Domain reputation	⚠️ Partly	Your domain’s standing is yours; the sending IPs change

The honest summary: your data comes with you, your setup does not. That is true of every move between platforms in this category, not just this one — nobody has ever built a template or automation importer for a competitor, because the underlying models are too different to map.

Step 1 — Export everything, including the suppressions

In Mailchimp, go to Audience → All contacts → Export Audience. That gives you subscribed contacts with their tags and merge fields.

Then do the part people skip: export your unsubscribed and cleaned contacts too. They are in the same audience view behind the status filter. You need them.

Here is why this matters more than anything else in the migration. If you import only your subscribed contacts, you arrive at your new platform with no record of the 4,000 people who unsubscribed over the years. The moment you send your first campaign, some of them receive it. They did not ask to hear from you again — some of them asked specifically not to — and a meaningful fraction will hit “report spam” rather than unsubscribe a second time.

That is how a migration turns into a deliverability incident in a single send. Export the unsubscribes and load them into your new suppression list before you send anything.

While you are there, export any campaign reports you want to keep. Historical stats do not move, and you lose access when you close the account.

Step 2 — Set up your sending domain first

Do this before you import anything, because DNS propagation is the only genuinely slow part of the whole migration and it can run in the background while you do everything else.

You need:

• DKIM — three CNAME records
• DMARC — a TXT record at _dmarc.<domain>, starting at p=none
• SPF — a TXT record if you are setting a custom MAIL FROM

If you are moving marketing email specifically, this is the moment to put it on its own subdomain rather than your root domain — it costs nothing extra to do now and is tedious to change later. We wrote about why that split matters.

One thing worth knowing if you are moving to your own AWS: new AWS accounts are in the SES sandbox and can only send to addresses you have verified. Getting out is a support request that AWS does sometimes decline. Start it early — it is the one step with a queue in front of it. We wrote a guide to getting approved.

Step 3 — Import contacts, then suppressions

Import your subscribed contacts first, mapping tags and custom fields as you go. Then load the unsubscribed and cleaned lists into your suppression list.

Order matters here. If suppressions go in first, some importers will silently skip those addresses on the contact import and you lose the record entirely. Contacts, then suppressions on top.

Spot-check afterwards: pick five contacts you know had tags or custom fields and confirm the values arrived. A field that silently failed to map is much cheaper to find now than in your first campaign.

Step 4 — Rebuild templates

Start with the one you send most, not the one you like best. For most people that is a single newsletter layout, and everything else is a variation of it.

If your Mailchimp templates were built years ago, this is worth treating as a redesign rather than a reproduction. You are going to rebuild them anyway, and email design has moved on — table-based layouts with inline styles are still the requirement, but dark-mode handling and mobile behaviour have improved a lot.

Rebuild your merge tags as you go. Mailchimp’s *|FNAME|* becomes {{firstName}} in Selva Mail, with dot-paths for custom fields ({{customFields.plan}}) and a fallback syntax for when a value is missing ({{firstName|there}}). Getting the fallbacks right matters more than it sounds — “Hi ,” is the classic migration tell.

Step 5 — Rebuild automations, most valuable first

Do not try to move twelve journeys at once. Rank them by what they actually earn or save, rebuild the top two or three, and leave the rest switched off in Mailchimp while you watch the new ones for a week.

In practice most accounts have one automation that matters — a welcome sequence — and a long tail that fires rarely and could probably be deleted rather than migrated. A migration is a good moment to notice that.

Step 6 — Warm up. Do not send to everyone.

This is where migrations go wrong, and it is entirely self-inflicted.

Your domain may have years of good standing, but you are now sending through different infrastructure. Send your first campaign to your whole 40,000-person list and you look, from the receiving side, like a brand-new sender with suspiciously high volume.

A workable ramp:

1. Days 1–3: your most recently engaged contacts only. A few hundred. People who opened something in the last 30 days.
2. Days 4–10: roughly double every three days, still favouring engaged contacts.
3. Week 3 onwards: widen to the full active list.
4. Your dormant contacts last, if at all. Somebody who has not opened anything in two years is the most likely to complain and the least likely to buy.

Watch bounces and complaints, not opens. Open rates are noisy and have been unreliable since privacy protection started prefetching images. Complaints are the number that gets you throttled.

If complaints rise above roughly 0.1%, stop increasing volume and hold until they settle. That threshold is not arbitrary — it is roughly where mailbox providers and AWS both start paying attention.

Step 7 — Repoint your forms, then close the account

Update your signup forms to post to the new endpoint, and check every place a form is embedded. It is common to find one on a landing page nobody has looked at in a year, quietly still filling a Mailchimp audience.

Run both in parallel for a billing cycle. Then export anything you still want, and close the account — Mailchimp bills on contacts stored, so an account you have stopped using is still charging you for the list sitting in it.

A realistic timeline

Day 1	Export contacts, unsubscribes, reports. Add sending domain, publish DNS. Start the SES production access request.
Days 2–3	DNS propagates. Import contacts, then suppressions. Rebuild the main template.
Days 4–7	Rebuild the top automations. Send test campaigns to yourself and colleagues.
Week 2	Begin the warmup with engaged contacts.
Weeks 3–4	Widen to the full list. Repoint forms.
Week 5	Export what remains, close the Mailchimp account.

About a month, of which most is waiting rather than working.

The thing to get right

If you take one item from this: export your unsubscribes. Everything else on this list is inconvenience if you get it wrong. Emailing people who already opted out is the one mistake that damages the asset you are trying to move.