ESP Migration Without Losing Deliverability: The Step-by-Step Playbook

ESP migration is the single highest-risk moment in an email program’s lifecycle – and most teams underestimate it. A platform switch that takes deliverability from 98% inbox placement to 40% can erase months of revenue in days. Data Innovation, a Barcelona-based CRM and deliverability consultancy orchestrating over 10 billion emails monthly across more than 10 countries, has documented that improperly executed email platform migration causes an average 22–38% drop in inbox placement rates during the first two weeks, with some enterprise programs never fully recovering. This playbook is designed to make sure yours isn’t one of them.

Why Emails Go to Spam After an Email Platform Migration: 3 Root Causes

Before we get to the timeline, you need to understand the failure modes. Every post-migration deliverability collapse we’ve investigated traces back to one (or more) of three root causes:

1. IP reputation starting from zero. Your old ESP’s IPs carried years of accumulated trust with ISPs. New IPs are blank slates – and Gmail, Microsoft, and Yahoo treat unknown senders with suspicion. According to Validity’s 2024 State of Email report, new IPs without proper warmup see spam folder placement rates exceeding 50% at major mailbox providers during the first 7 days.
2. Authentication gaps during the cutover. DKIM keys change. SPF records need updating. If your DMARC policy is anything above p=none, messages signed with the wrong key get rejected outright – not just filtered, rejected. The window between DNS propagation and full authentication alignment is where most damage happens.
3. Dirty data migrating uncleaned. Legacy lists carry dead weight: invalid addresses, spam traps, role accounts, and long-lapsed subscribers. Moving that data onto fresh infrastructure is like lighting a match in a room full of gasoline. ISPs see a brand-new IP suddenly hitting spam traps and draw the obvious conclusion.

Every step in the playbook below exists to neutralize one of these three risks.

The Decision Matrix: What to Migrate First

Not all email streams carry the same risk or the same value. Migrating everything simultaneously is how programs get burned. Use this prioritization framework:

Phase 1: Transactional Email (Weeks 1–2)

Password resets, order confirmations, shipping notifications. These have the highest engagement rates (open rates typically 60–80%) and the lowest complaint rates. They warm your new IPs with overwhelmingly positive signals. Transactional mail also gives you an immediate functional test of your new platform’s API integration, delivery speed, and bounce handling.

Phase 2: Triggered/Behavioral Email (Weeks 3–4)

Welcome series, abandoned cart, browse abandonment. These target recently active subscribers who have explicitly engaged. Engagement rates are strong, volume is moderate, and ISPs continue to see a sender that recipients want to hear from.

Phase 3: Marketing Campaigns (Weeks 5–7)

Promotional sends to your engaged segment (opened or clicked in the last 90 days). Start at 10–15% of your typical daily volume and increase by 20–30% each send. Do not blast your full list on day one of this phase.

Phase 4: Newsletters and Full-List Sends (Weeks 8–10)

Only after inbox placement is stable at 95%+ across all major ISPs do you move your full newsletter program. This is where the older, less-engaged segments live – and where spam traps hide.

If your CFO or CMO is pushing for a “big bang” migration over a single weekend, show them the math: a 30% inbox placement drop on a list of 1M contacts sending weekly at $0.05 revenue per email equals roughly $65,000 in lost revenue over the warmup period. A phased migration costs time. A failed migration costs money.

Week-by-Week Email Platform Migration Timeline

Pre-Migration (Weeks –4 to –1)

• Audit your current state. Pull 90 days of deliverability data from your old ESP: bounce rates, complaint rates, inbox placement by ISP (not just aggregate), and engagement by segment.
• Clean your list. Run the full database through a verification service. In an enterprise migration we supported – a global FMCG brand with 2 legacy sending domains carrying damaged reputation, 1.2M contacts, and DMARC sitting at p=none – list verification revealed 34% invalid addresses. Migrating those addresses would have been catastrophic. After hygiene, the working list dropped to 792K contacts, but those were contacts that actually mattered.
• Set up authentication on the new platform. Generate new DKIM keys, update SPF records, and – critically – do not tighten your DMARC policy during migration. If you’re at p=none, stay there until inbox placement stabilizes. If you’re at p=quarantine or p=reject, ensure your new ESP’s DKIM signing is verified and aligned before any mail flows.
• Establish parallel sending infrastructure. Keep your old ESP active. You need a fallback. If warmup stalls or a major ISP blocks your new IPs, you can reroute critical sends through the old platform while you troubleshoot.
• Set a hard cut-off date. Parallel sending is a safety net, not a permanent state. Define the date (typically 4–6 weeks post-migration start) when the old ESP is decommissioned. Without a cut-off, teams drift into indefinite dual-sending, which creates its own deliverability confusion.

Execution (Weeks 1–10)

Follow the phase sequence above. During each phase:

• Monitor inbox placement per ISP. Aggregate metrics lie. You might show 92% overall while sitting at 60% at Microsoft – which represents 30%+ of many B2C lists. Use seed-based or panel-based monitoring (Everest, GlockApps, or InboxMonster).
• Watch for deferrals, not just bounces. A 4xx response from Gmail saying “try again later” is a throttling signal. Respect it. Reduce volume to that ISP and increase gradually.
• Check Google Postmaster Tools and Microsoft SNDS daily. These are free, first-party reputation signals. If domain reputation drops from “High” to “Medium” at Google, pause volume increases immediately.
• Track complaint rates obsessively. The threshold is 0.1% for Gmail (per their 2024 sender guidelines) and roughly 0.3% for most other ISPs. One bad segment can spike you above this.

Post-Migration (Weeks 11–12)

• Decommission old ESP sending (your cut-off date).
• Tighten DMARC policy incrementally: move from p=none to p=quarantine at 10%, then 25%, then 50%, then 100%, monitoring rejection reports at each stage.
• Run a final deliverability audit comparing pre-migration and post-migration inbox placement, bounce rates, and revenue per email.

The 25-Point Migration Risk Checklist

Print this. Assign an owner to each item. Do not send a single email from the new platform until items 1–12 are complete.

1. Full list verification completed (remove invalids, role accounts, disposable domains)
2. Spam trap detection scan run
3. Suppression lists exported from old ESP and imported to new
4. Unsubscribe records migrated and verified
5. Bounce logs from old ESP reviewed (hard bounces permanently suppressed)
6. Complaint feedback loops (FBLs) registered on new sending IPs
7. SPF record updated to include new ESP
8. DKIM keys generated, published, and verified
9. DMARC record reviewed (policy, RUA/RUF reporting active)
10. Custom tracking domains configured with HTTPS
11. Return-path/bounce domain aligned
12. Seed list inbox placement test passed (>90% inbox at top 5 ISPs)
13. Transactional email integration tested end-to-end
14. Warmup volume schedule documented and approved
15. Old ESP kept active as fallback with rerouting plan documented
16. Cut-off date for old ESP decommission defined
17. Google Postmaster Tools verified for all sending domains
18. Microsoft SNDS enrolled for all sending IPs
19. Per-ISP monitoring tool configured (Everest, GlockApps, or equivalent)
20. Engagement segmentation rebuilt on new platform (30/60/90-day recency)
21. Sunset policy defined for lapsed subscribers on new platform
22. Preference center and unsubscribe links tested on new templates
23. Legal/compliance review of new ESP’s data processing agreement
24. Escalation plan documented: who to contact at new ESP if IPs get blocklisted
25. Post-migration audit scheduled (Week 12) with clear KPIs

Lessons from Enterprise Migration at Scale

In the FMCG migration referenced earlier, the program had two legacy sending domains with accumulated spam trap hits, a complaint rate hovering at 0.25%, and no meaningful engagement segmentation. The team’s initial instinct was to migrate everything to the new ESP and “start fresh.” That instinct would have destroyed their inbox placement.

Instead, the migration followed the phased approach above. Transactional mail went first on dedicated IPs. Marketing sends started only with subscribers who had clicked within 60 days – roughly 18% of the cleaned list. The old ESP continued handling newsletter sends for five weeks. By week eight, inbox placement on the new platform hit 96% at Gmail and 94% at Microsoft. The old ESP was decommissioned on schedule. DMARC moved to p=reject by week fourteen.

The total timeline was longer than leadership wanted. But there was no deliverability dip, no revenue loss, and no panicked war room at 2 AM trying to get IPs delisted from Spamhaus.

Conclusion: Make Your Email Platform Migration Boring

The best ESP migrations are uneventful. They follow a documented plan, respect ISP throttling signals, and treat deliverability as a metric that must be maintained, not rebuilt. If your team is planning an email platform migration – whether driven by cost, capability gaps, or contract expiration – invest the preparation time upfront. The checklist and timeline above have been tested across programs sending hundreds of millions of messages monthly. The next step is mapping this framework to your specific sending volumes, ISP distribution, and engagement profile – and stress-testing your authentication stack before a single message leaves the new platform.