How to Migrate Your Email List from Mailchimp, Klaviyo, or SendGrid

Moving an email list between platforms looks like a data export problem. Download a CSV, upload it somewhere else, cancel the old subscription. People budget an afternoon for it.

The migrations that go badly do not fail at the export step. They fail two weeks later, when the first campaign from the new platform goes to a few thousand people who had unsubscribed years ago, complaints spike, and the shiny new sending domain picks up a reputation problem in its first week — the one week it can least afford one.

Almost all of that is avoidable, and the fixes are unglamorous. This is the order of operations that works.

What Transfers, and What Cannot

Start by being honest about what a migration actually moves, because the mismatch between expectation and reality is where the planning goes wrong.

That last row is the one that determines your timeline. Reputation is built by a sending domain and IP over time, through consistent volume and positive engagement. It belongs to the infrastructure that earned it. Switching platforms means starting that accumulation again — and if you send your usual volume on day one from infrastructure with no history, you look exactly like a spammer who just bought a list.

The Part People Get Wrong: Suppressions

If you take one thing from this guide, take this: your suppression list is more important than your contact list.

Your contact list is people you may email. Your suppression list is people you must not — unsubscribes, hard bounces, and spam complainants accumulated over your platform’s entire history. It usually lives in a completely separate export from your contacts, and it is silently easy to leave behind.

The consequences of leaving it behind are severe, and they compound:

• You email people who explicitly opted out. Depending on where your recipients are, that is a regulatory problem as well as an ethical one.
• Those people complain rather than unsubscribing again, because they already did this once. Complaint rates from a re-mailed unsubscribe list are far worse than from a cold list.
• You re-mail known-dead addresses, and your bounce rate spikes on a brand-new domain with no reputation buffer to absorb it.

All three land in the same week, on infrastructure with no history. It is the single most damaging thing you can do to a new sending setup.

Export three lists from your old platform, not one:

1. Active, subscribed contacts
2. Unsubscribed contacts
3. Bounced and complained addresses

Then import the second and third into your new platform’s suppression list before you import the first, and before you send anything. Order matters — suppression first, contacts second, sending third.

Exporting Cleanly

The mechanics differ per platform, and every provider reorganises its interface periodically — so treat the following as what to look for rather than a click path.

Mailchimp. Audience data exports as CSV from the audience view. The important detail is that unsubscribed and cleaned contacts are tracked as distinct statuses, and a default export of your audience may not include them in a usable form. Export each status explicitly and confirm you have separate files for subscribed, unsubscribed, and cleaned before you move on.

Klaviyo. Profiles export as CSV, and consent state lives in per-channel subscription fields rather than a single status column. Because Klaviyo is event-heavy, decide early how much event history you actually need — most of it does not map onto a new platform and is better exported for archival than migrated.

SendGrid. Marketing contacts and suppressions live in genuinely separate places, and suppressions are further subdivided into categories such as bounces, blocks, spam reports, and global unsubscribes. Export every category. This is the platform where “I exported my contacts” most often means the suppression data was left behind entirely, because it was never in the same screen.

Whatever you are leaving, also export:

• Campaign performance reports, for your own records. You will not get them after the account closes.
• Template HTML, even if you plan to rebuild. Useful reference for copy and structure.
• A written description of every automation — trigger, timing, conditions, and content. Nobody remembers the details of a three-year-old flow, and this is the artifact you will actually rebuild from.

Keep the raw export files unmodified in one place. When something looks wrong after import, the original is what you diff against.

Clean Before You Import, Not After

You are about to send from infrastructure with no reputation. Every dead address in your import is a bounce you cannot afford yet.

Verify the list. A verification service checks syntax, domain validity, and mailbox existence without sending anything. On a list that has been actively mailed and hygienically maintained, this catches little. On a list carrying several years of accumulated contacts, it routinely catches a meaningful share — and each one would otherwise be a bounce on your first send.

Segment by engagement before you migrate, not after. Pull the last-open or last-click date into your export. You need this for the ramp in a later step, and reconstructing it after import is difficult or impossible.

Decide what not to bring. A migration is the cleanest opportunity you will ever get to drop dead weight. Contacts who have not opened anything in a year are not an asset — they are the group most likely to bounce or complain, and they are about to do it on your least resilient infrastructure. Leaving them behind is a decision you can make once, cleanly, at no cost.

Normalise your data while it is in a spreadsheet. Trim whitespace, lowercase addresses, fix the country and phone formats that drifted over the years, and standardise the field names you are about to map. Doing this in the CSV is far easier than fixing it in a platform afterwards.

The list hygiene guide covers the cleaning criteria in more depth. The migration-specific point is simply that the cleaning has to happen before the import, because after the import your first send is already carrying the consequences.

Importing and Mapping Fields

Suppressions first. Then contacts.

Map your fields deliberately. Custom fields rarely have identical names across platforms, and a mismatched mapping silently shifts a column — the classic outcome is phone numbers landing in a field a template later renders as a name. Import a sample of 20 contacts first and inspect the result before running the full file.

Preserve consent metadata where you can. Opt-in date, source, and IP are worth carrying across even into a generic text field. If you are ever asked to demonstrate consent for a specific contact, this is the evidence, and it does not exist anywhere else once the old account closes.

Check the count. Rows in your CSV versus contacts in the platform after import. Discrepancies are normal — duplicates get merged, suppressed addresses get skipped — but you should be able to explain the difference. An unexplained gap means something was silently rejected.

Rebuild segments from criteria, not from exported membership. A segment is a live query. Importing a snapshot of who was in it last Tuesday gives you a static list that stops being true immediately.

Moving Domain Authentication

Your new platform needs its own SPF and DKIM records. This is the step with the most potential for a genuinely visible outage, and it is easy to sequence safely.

Add the new records alongside the old ones. SPF supports multiple include: mechanisms in a single record — you can authorise both platforms at once during the transition:

v=spf1 include:spf.brixus365.com include:oldplatform.example ~all

Watch the 10-lookup limit while both are present. If adding an include pushes you over, SPF fails for everything, which is a much bigger problem than the migration.

DKIM is simpler because the selectors differ — the new platform’s CNAME coexists with the old one without conflict. In Brixus365 that record is bx1._domainkey.yourdomain.com pointing at bx1.dkim.brixus365.com, added when you verify the domain.

Remove the old records only after the final send from the old platform, not on cutover day. Mail already in flight still needs to authenticate.

If you have a DMARC record at p=quarantine or p=reject, confirm the new platform’s mail aligns before you ramp. Failing alignment at enforcement means your mail is rejected outright, not merely filtered — the DMARC rollout guide covers what alignment requires. If you are at p=none, you have a safety margin, but check the reports anyway.

The Ramp: Do Not Send Everything on Day One

This is the part people skip, and it is the part that determines whether the migration succeeds.

Send to your most engaged recipients first, and grow volume gradually. Engaged recipients open and click, and early positive engagement is exactly the signal that builds reputation. Starting with your least engaged segment does the opposite, on infrastructure that has no history to cushion it.

A workable four-week shape:

Adjust to your volume — a list of two thousand needs less ceremony than one of two hundred thousand — but keep the ordering. Engaged first is the principle; the exact percentages are a detail.

Watch bounce and complaint rates at every step, and stop if they move. The thresholds are low: a complaint rate above 0.1% or a bounce rate above 3% is a warning sign, and on new infrastructure it is a reason to pause and diagnose rather than push on to the next week. Finding a problem in week one at 10% volume is a minor inconvenience. Finding it in week four is a reputation you now have to repair.

Keep sending consistently through the ramp. A domain that sends daily and then goes quiet for a week loses the rhythm it was building. Consistency is itself a positive signal.

Running Both, Then Cutting Over

Do not cancel the old account the day you import.

Run both in parallel for at least a full billing cycle. The old platform stays live but stops sending. This gives you a working fallback if something is wrong with the new setup, and — more usefully — it keeps the historical data reachable while you are still discovering what you forgot to export.

Migrate transactional email separately from marketing, and do it first. Transactional volume is steady, goes to engaged recipients who requested it, and generates almost no complaints. It is the ideal traffic for establishing a new domain’s reputation, and moving it first means your marketing ramp starts on a domain that already has some standing. It is also the higher-stakes traffic — password resets and receipts have to work — so it deserves its own attention rather than being bundled into a larger cutover.

A cutover checklist worth running before you close the old account:

• Suppression list imported and count verified
• Sample sends inspected across major mail clients
• Automations rebuilt and tested end to end with real triggers
• Unsubscribe link tested — click it, confirm the contact is actually suppressed
• Bounce and complaint handling wired into whatever you monitor
• Campaign reports exported and archived
• API keys and integrations repointed, old keys revoked
• DNS records updated, old sender records removed after the final legacy send

That unsubscribe test deserves its own line. It is the single most common thing to be broken after a migration, and it is the one thing you cannot afford to be broken — a non-functioning unsubscribe link converts people who would have quietly left into people who press the spam button.

If Brixus365 is where you are landing, domain setup generates and verifies your SPF and DKIM records, one-click unsubscribe headers are set automatically, and bounce and complaint suppression is applied across every list rather than per-campaign. Start free — 9,000 emails a month, no card — and the email setup guide covers the DNS side in detail.

Frequently Asked Questions