Playbooks
Switch email platforms without losing deliverability
5 min read · Updated
Moving platforms is mostly a data problem wearing a deliverability costume. The contacts copy across in an afternoon; what goes wrong is everything that was recorded *about* those contacts and never made it into the export.
What actually breaks
Almost nobody loses their contact list in a migration. The four things that do go missing are the ones no export dialog puts in the file by default:
- Suppression state. Who unsubscribed, who hard bounced, who pressed "this is spam". Mail one of them from the new platform and you have re-sent to someone who already told you to stop.
- The consent record. When each person opted in and through what. You still need to be able to answer that question after the move; the old platform is where the answer currently lives.
- Sending reputation. It belongs to the domain and the IP, not to your account. Change either one and mailbox providers start their assessment again.
- Automations mid-flight. Someone three days into a five-day welcome sequence is in a state that exists only inside the old platform. Nothing exports it.
Plan the move around those four and the rest is data entry.
1. Export everything while you still have an account
Do this before you downgrade, cancel or let the plan lapse. Several platforms cut off exports the moment the subscription ends, and support will not retrieve it for you afterwards.
- Subscribed contacts, with every custom field, not just name and email. Fields you think you no longer use are usually powering a segment you forgot about.
- Unsubscribes, bounces and complaints, as separate files. These are the suppression list, and they matter more than the subscriber file.
- Campaign history, or at least the sends from the last twelve months with their open and click rates, so you can tell later whether the move helped or hurt.
- The emails themselves. Save the HTML of anything you will want to rebuild. A screenshot is not enough.
- A written list of your automations — trigger, wait, condition, email — because the export will not contain them in any form you can replay.
Keep the export files. They are your rollback plan and, for consent questions, your evidence. Store them somewhere with the same access controls as the contact data itself.
2. Carry the suppression list across first
This is the step people skip, and it is the only one that is genuinely irreversible. A contact list can be re-imported. An email sent to someone who unsubscribed two years ago cannot be unsent, and it is the single fastest way to turn a migration into a complaint spike.
Sendtim will not let an import override a suppression: addresses already suppressed in the workspace are skipped whatever the file says, and nobody who unsubscribed can be re-subscribed by uploading a spreadsheet. That protects you from your own second import — but only once the suppressions are actually in there. Load them before the subscriber file, not after.
Treat anything ambiguous as suppressed. A contact your old platform marked "cleaned", "blocklisted" or "inactive" is one you have no reason to mail on day one of a new platform.
3. Give each email type exactly one owner
The expensive migration failure is not a missing field. It is two platforms both believing they own the welcome email, and new signups getting it twice.
Write down every email that currently leaves your business — campaigns, the welcome sequence, the re-engagement flow, receipts — and name one platform responsible for each. Move them one at a time, and turn the old one off for that type on the same day you turn the new one on. Never run both.
The same rule applies to whatever feeds the list. If a form, Zapier zap or API call still writes to the old platform, new signups quietly accumulate somewhere you no longer send from.
4. Re-warm if the sending identity changed
Mailbox providers judge the domain in the From address and the infrastructure behind it. Keep the same From domain and you keep most of the domain reputation; the IPs underneath will be new, which is a smaller change but not nothing. Move to a new domain or subdomain and you are starting from zero.
Either way, do not make your first send on the new platform your biggest. Start with the most engaged slice of the list — people who opened something in the last month — and expand over a week or two while you watch what comes back. Engaged recipients open and do not complain, which is exactly the signal a new sending path needs.
Publish SPF, DKIM and DMARC for the new platform before the first send, and leave the old platform’s records in place until it has stopped sending entirely. Both can be authenticated at once; removing the old records early is how a straggler send ends up unauthenticated.
5. Watch the right numbers for two weeks
Open rate is the number everyone checks and the least useful one here — it moves for reasons that have nothing to do with the migration. These are the ones that tell you whether the move is going well:
| Watch | What a bad reading means |
|---|---|
| Hard bounce rate | The list is older than you thought, or the export included addresses the old platform had already cleaned. |
| Complaint rate | People do not recognise the sender. Usually a changed From name, or a segment that should not have been mailed yet. |
| Delivered vs sent | Authentication or reputation. Check that SPF, DKIM and DMARC all pass on a real received message, not just in the dashboard. |
| Unsubscribes on the first send | A spike is normal and healthy on a list that has not been mailed in a while. A spike on an active list is a sign you mailed the wrong people. |
Compare each against the same figures from your old platform rather than against an industry benchmark. You are looking for a change, not a grade.
Platform-specific guides
The steps above are the same wherever you are coming from. What differs is the vocabulary — what the old platform calls a list, a field, a flow — and where the suppression data hides. Those are in the individual guides: Mailchimp, Brevo, MailerLite and SendGrid.