ESP migrations rank just below ransomware attacks in how much chaos they can inject into a small team. The technical part isn't hard — every modern ESP has good import tools and reasonable APIs. The deliverability part is where everyone gets burned. Mail from the new ESP goes out from IPs you've never used before, on behalf of a domain those IPs have never seen, to a list that's been trained to expect you from different infrastructure. Placement drops. Panic ensues. This checklist keeps it from becoming a crisis.
A marketer, founder, or operator running the migration. Engineering will do the actual domain and DNS work, but this checklist is the project plan you carry through planning meetings so nothing gets forgotten.
BEFORE: The 4-week prep phase
1. Baseline the current program
Before you touch anything, know where you are. Run a full placement test on the current ESP and save the report. Pull Gmail Postmaster numbers, bounce rates, complaint rates, and revenue per send for the last 90 days. Anything you can't measure before the move you can't compare after.
2. Pick the right migration window
Not in Q4. Not during a product launch. Not during a big regulatory deadline. The ideal windows are mid-January to mid-March, or July. Low volume, forgiving audience, minimal competing priorities.
3. Decide: subdomain or same domain?
If you can, send from a subdomain on the new ESP (mail.yourco.com) while the old ESP continues on the root (yourco.com). This isolates reputation and lets you roll back cleanly if things go wrong. Same-domain migrations are simpler but have no safety net.
4. Get DNS right on the new sending identity
The new ESP will give you SPF includes, DKIM records, and DMARC guidance. Your engineer adds them. Then you verify independently — not just through the ESP's "verified" green check. A placement test from the new identity should pass SPF and DKIM. If it doesn't, don't move on.
5. Clean the list before import
Don't import inactives. Don't import addresses you're not sure have consent. Don't import role accounts (info@, contact@) unless you know they engage. A dirty import on day one of a new ESP is the fastest way to torch new-domain reputation.
6. Plan the warmup schedule
New ESPs typically use shared IP pools, but your domain is new to them. Plan a 4–6 week ramp: week 1 send to the top 5% most engaged, week 2 to top 15%, week 3 to 30%, week 4 to 60%, week 5 to 100%. Most ESPs will help you automate this — ask for their ramp plan before contract signing.
7. Export templates, automations, segments
Not just the list. Every welcome series, every abandoned cart flow, every segment definition, every template. The ESP being replaced is often the only place these live. Export to a shared drive before the contract ends.
DURING: The 4-week migration phase
8. Dual-send for two weeks
Run the same campaigns through both ESPs in parallel on different segments. Compare placement. If new ESP placement is within 5pp of old, proceed. If more than 5pp worse, investigate before cutting over.
9. Start with transactional, not marketing
Transactional mail has high engagement (users are waiting for these). Running receipts and password resets through the new ESP first is the cheapest warmup in the world — and it's the least risky because transactional volume is lower than marketing.
10. Launch welcome flows next
New-subscriber welcomes are the second-highest engagement segment. Route these through the new ESP in week 2.
11. Bulk campaigns last, on the ramp
Regular weekly campaigns move to the new ESP in week 3 onward, following the ramp plan (step 6). Segment by engagement: most-engaged go first.
12. Monitor daily
Run a placement test at least twice a week. Watch Gmail Postmaster reputation daily. Check the new ESP's delivery dashboard for block events (550 5.7.1, 421 4.7.0, etc).
13. Keep the old ESP warm
Don't shut the old ESP off on day one. Keep sending something — a weekly newsletter to a subset — so you have a rollback option if things go badly. Kill it only after 30 days of stable new-ESP numbers.
Schedule a placement test twice a week during the migration to catch provider-specific problems early. Or wire it into CI via the API so your team gets a daily report.
AFTER: The 4-week stabilisation phase
14. Retire the old ESP cleanly
Only after 30 days of stable new-ESP numbers. Remove the old ESP's SPF include. Rotate any DKIM keys that were shared. Export final logs. Cancel the contract.
15. Reconcile reporting
Metric definitions differ between ESPs. "Open rate" on ESP A is not always the same calculation as on ESP B. Document the differences so Q2 numbers aren't compared apples-to-oranges against Q1.
16. Capture the before/after placement number
Run the full placement test one last time 30 days after full cutover. Save the report next to the pre-migration baseline. If the new number is within 3pp of the old, the migration succeeded. If it's more than 5pp worse, something still needs fixing.
17. Write a one-page post-mortem
What went wrong, what went right, what you'd change next time. Three years from now when the next migration happens, this page is worth its weight in gold.
Red flags that mean pause
- Placement on new ESP is 10pp+ worse than old after 2 weeks of warmup
- Bounce rate spikes above 3% on new ESP
- Gmail Postmaster reputation drops to Low within 30 days of cutover
- New ESP starts rate-limiting your sends unexpectedly
- Any provider starts blocking with 5.7.1 errors that didn't before
Any of these: pause the migration, investigate, fix, then resume. Pushing through red flags is how a migration becomes a multi-quarter recovery project.