List Migration: Moving to a New ESP Without Losing Subscribers
A migration order that preserves deliverability, and the fields that never survive an export unless you plan for them.
On this page
The short version
- The order matters more than the tooling. Authenticate, warm, then move volume — moving everything on day one is the fastest way to arrive at the new platform with a damaged reputation.
- The fields that vanish are the ones nobody exports: consent records, signup dates, engagement history, suppression lists.
- The suppression list is the one that must not fail. Losing it means mailing people who opted out, which is the worst possible first send from a new platform.
Changing email platform looks like a data transfer and behaves like a reputation event. The new platform sends from different infrastructure, and mailbox providers have no history for it — so a full-volume first send from a new setup is an unknown sender appearing at scale.
That is the risk to plan around, and it is entirely avoidable with a staged approach.
The order
Each step is verifiable before the next begins.
Export everything before you cancel anything
Subscribers, suppression lists, engagement history, consent records, automation content, and the templates. Do this while you still have full access, not during the notice period — several of these are harder to retrieve once an account is downgraded.
Authenticate the new platform
SPF updated to include it, domain-aligned DKIM published, and a custom return-path if supported. Verify with a real received message before sending anything to a subscriber.
Import suppression first
Before any subscriber import. If the two happen the other way round and something interrupts the process, the platform is holding a mailable list containing people who opted out.
Warm the new sending setup
Most engaged segment first, ramping volume over two to four weeks. The domain may carry reputation from the old platform; the sending infrastructure does not.
Run both in parallel briefly
Old platform for the bulk, new one for the warmup segment, with clear suppression between them so nobody receives both. A week or two of overlap costs one month's subscription and removes most of the risk.
Rebuild flows, then switch them over
Rebuilt and tested on the new platform before the old ones are disabled. A gap where neither is running means new subscribers get no welcome sequence, and nobody notices for weeks.
What to export, and what breaks without it
| Data | Exported by default? | Without it |
|---|---|---|
| Email addresses and custom fields | Yes | Nothing to migrate |
| Segments and tags | Usually | Rebuild by hand |
| Automation content | Sometimes | Rewrite the flows |
| Suppression list | Often not | You mail people who opted out |
| Consent timestamps and sources | Rarely | Cannot demonstrate consent |
| Original signup dates | Rarely | Anniversary and tenure logic breaks |
| Per-subscriber engagement history | Rarely | Engagement segments start empty |
Engagement segments start empty
This is the subtle one. Engagement tiers are computed from a history the new platform does not have, so on day one everybody looks either unengaged or unclassified depending on how the rules are written.
If your sending rules suppress the unengaged, that can mean suppressing the entire list — or, worse, mailing everybody as though they were all active, which is the opposite failure.
Two mitigations. Import a computed engagement field from the old platform as a custom value, so the tiers have something to work from. And check what your rules do with a subscriber who has no history at all, before the first send rather than after.
Keep the old account long enough
Longer than feels necessary. Two months of overlap is a small cost against discovering in week six that a field, a flow or a report only existed there.
Before cancelling, export once more — a final snapshot after all the sending has moved — and store it somewhere durable. The one thing you will want later is the thing nobody thought to take.
Migration check
- Everything exported before any account change
- Suppression list imported before subscribers
- SPF, DKIM and return-path verified on a real received message
- Warmup ramp planned, most engaged first
- Parallel running with suppression between platforms
- Flows rebuilt and tested before the old ones are disabled
- An engagement value imported so tiers are not empty
- Rules checked for what they do with no-history subscribers
- Old account kept for two months, with a final export taken
Frequently asked questions
How long should a migration take?
Four to six weeks for a list of any size, most of which is warmup running in parallel. Compressing it into a weekend is where the reputation damage happens.
Will the domain's reputation carry over?
Domain reputation largely does; the sending infrastructure's does not. That is why warmup is still needed even when the from address is unchanged.
Should I clean the list before or after migrating?
Before. There is no reason to pay to import addresses you are about to remove, and a cleaner list makes the warmup safer.