ESP migration introduces three simultaneous risks: fresh IP addresses with no reputation, authentication realignment across SPF and DKIM, and subscriber list transfers that can accidentally reintroduce bad data. A successful migration takes 6 to 10 weeks, uses a parallel-send architecture, and preserves more reputation than it burns. Rushed migrations routinely cost 30 to 60 days of deliverability recovery time.
Switching email service providers ranks among the highest-risk operations an email program will ever undertake. Years of accumulated sender reputation live at the intersection of specific IPs, authenticated domains, and behavioral patterns that receiving systems have learned to trust. Change any of those inputs simultaneously, and the signal that reaches Gmail, Outlook, and Yahoo looks like a completely new sender, regardless of the volume, list quality, or content discipline behind the change.
This playbook covers the full migration arc: the signals that justify a switch, the 6-to-10 week transition timeline, the technical preparation that protects reputation, the parallel-send architecture that prevents volume spikes on new infrastructure, and the post-migration monitoring that catches problems before they compound. The guidance applies whether the migration is enterprise-scale across multiple IPs or a mid-market move between platforms like Mailchimp, Klaviyo, HubSpot, Braze, or Iterable.
- A proper ESP migration takes 6 to 10 weeks. Anything faster either skips IP warmup or migrates so little traffic that the timeline does not matter.
- Keep the old ESP active for 4 to 8 weeks after the new one goes live. This is not redundancy; it is the mechanism that protects reputation during the warmup ramp.
- Authentication realignment is the single highest-risk technical step. SPF, DKIM, and DMARC must be configured on the new platform before a single production send.
- Migrate engaged subscribers first, inactive subscribers last or never. Bringing a full unsegmented list to a cold IP is the fastest way to poison new reputation.
- Monitor Gmail Postmaster Tools and Microsoft SNDS daily during weeks 1 to 6. Reputation degradation shows up there 48 to 72 hours before it reaches ESP-reported deliverability metrics.
When ESP Migration Is Actually Justified
Migration is often pitched as a fix for deliverability problems that have nothing to do with the ESP. Before starting, verify the issue is not portable across platforms:
| Symptom | Likely Cause | Will Migration Help? |
|---|---|---|
| Inbox placement below 85% for 60+ days | List quality, content, or shared IP pool | Only if shared IP neighborhood is compromised |
| Rising spam complaints | Content, frequency, or list hygiene | No. These travel with you. |
| Repeated ESP support failures | Vendor capability gap | Yes, but evaluate the new vendor carefully |
| Feature or integration limits | Platform capability | Yes, directly addressable by migration |
| Cost per message at scale | Pricing structure | Yes, if volume tiers favor alternate vendor |
| Dedicated IP reputation damage | Sender behavior on that IP | Partially. New IP resets but only if sending discipline changes. |
The majority of migration requests driven by deliverability frustration turn out to be fixable in the current platform through list hygiene, authentication repair, and content changes. Genuine migration drivers are capability limits, pricing misalignment, or confirmed shared-pool reputation damage that the current vendor cannot resolve.
Warning: Never migrate during an active deliverability crisis. Fix the immediate problem first (pause sending, remediate list, address blacklist), then evaluate whether migration is the right structural change. Migrating under duress almost always transfers bad patterns to a fresh platform and compounds the damage.
The Full 6 to 10 Week Migration Timeline
Enterprise migrations routinely take 8 to 12 weeks. Small business migrations can complete in 6, but compressing further skips critical reputation-building steps. The standard phased timeline:
Weeks 1 to 2: Audit and Selection
- Export complete subscriber data, engagement history, and campaign archive from the current ESP
- Audit all domains, subdomains, and sending IPs currently in use
- Document every integration (CRM, ecommerce, analytics, data warehouse)
- Finalize ESP selection with explicit deliverability requirements written into contract
- Negotiate migration support with incoming vendor (most enterprise ESPs provide this)
Weeks 3 to 4: Technical Preparation
- Provision new sending infrastructure on the incoming ESP
- Configure SPF, DKIM, and DMARC records for the new platform without removing the old ones
- Verify authentication alignment using a SPF checker, DKIM checker, and DMARC checker
- Rebuild all email templates, segments, and automation workflows in the new platform
- Set up Gmail Postmaster Tools and Microsoft SNDS for the new sending infrastructure
- Configure feedback loops with all major mailbox providers
Weeks 5 to 8: IP Warmup and Parallel Send
- Begin sending from the new ESP at 1 to 2% of normal volume, targeting highest-engaged recipients only
- Keep the old ESP sending the remaining 98 to 99% of traffic to preserve overall deliverability
- Increase new-ESP volume by roughly 50 to 100% per day for the first week, then 20 to 30% per day
- Monitor Gmail Postmaster Tools daily for domain reputation changes
- Scale the new ESP to 100% of volume by end of week 8 if warmup metrics stay healthy
Weeks 9 to 10: Sunset and Validation
- Reduce old ESP sending to zero once new platform consistently handles full volume
- Keep the old ESP account active (not terminated) for another 4 weeks as a rollback option
- Monitor reputation metrics on new infrastructure for sustained health
- Remove old ESP from SPF record only after 4 weeks of stable full-volume sending on new platform
Authentication Realignment Without Breaking Things
Authentication is the single highest-risk technical step because it affects every message sent from both ESPs during the overlap period. The goal is to have both platforms passing SPF, DKIM, and DMARC simultaneously.
SPF Record Updates
A SPF record can include multiple sending sources. Add the new ESP include: mechanism without removing the old one:
v=spf1 include:_spf.oldesp.com include:_spf.newesp.com -allCritical constraint: SPF has a hard 10 DNS lookup limit. Adding a second ESP often pushes domains over this limit, causing PermError and authentication failures. Audit total lookups before and after the change. If the combined record exceeds 10, one option is to use SPF flattening (hardcoding IP ranges) during the migration window.
DKIM Selector Separation
DKIM uses selectors to identify which key signed a given message. Each ESP uses its own selector, so adding the new ESP does not conflict with the old. Publish the new DKIM public keys (typically CNAME records pointing to the new ESP DNS zone) during week 3 of migration:
newesp._domainkey.example.com CNAME newesp._domainkey.newesp.comVerify each ESP signs with aligned domains (d= parameter in the DKIM signature matches the organizational domain) to satisfy DMARC alignment.
DMARC During Migration
If the current DMARC policy is p=reject, leave it there. A migration does not require relaxing DMARC provided both ESPs are properly authenticating. Some teams panic and drop to p=none during migration, which removes protection against active spoofing attempts. Hold the existing policy, verify both platforms pass alignment, and move forward.
Configure DMARC aggregate reports to flow to a dedicated shared mailbox during migration. Both ESPs will generate DMARC activity, and you need to see failures in near-real-time. An unexpected spike in DMARC failures during weeks 5 and 6 is the earliest signal that something in authentication alignment is wrong.
List Segmentation for the Warmup Ramp
The list you migrate with is not the list you send to during warmup. Send to engaged subscribers first, inactive subscribers last, and some subscribers never. Receiving servers judge new sending infrastructure primarily on engagement signals, and bringing a full unsegmented list to a cold IP produces a catastrophic first impression.
The standard warmup segmentation:
| Week | Send to | Target Volume |
|---|---|---|
| Week 5 | Opened within last 7 days | 1 to 5% of normal volume |
| Week 6 | Opened within last 30 days | 10 to 25% of normal volume |
| Week 7 | Opened within last 90 days | 40 to 60% of normal volume |
| Week 8 | Opened within last 180 days | 80 to 100% of normal volume |
| Post-migration | Full list minus sunset segment | 100% |
Subscribers who have not engaged in more than 12 months should not be brought to the new platform at all. Treat the migration as a forced list hygiene event. Archive these addresses on the old platform, and let them remain there until a considered re-engagement campaign is ready. Most of them will never reactivate; sending to them on fresh infrastructure guarantees poor warmup metrics.
The Parallel Send Architecture
During weeks 5 to 8, both ESPs are sending production traffic for the same domain. This sounds chaotic but is actually the safest possible transition pattern. The architecture:
- Segment each campaign audience into two cohorts: warmup-new and warmup-old
- Route the warmup-new cohort to the incoming ESP
- Route the warmup-old cohort to the outgoing ESP
- Shift the ratio week by week as new-ESP metrics confirm healthy reputation
- Maintain suppression list synchronization between platforms so unsubscribes and bounces from one appear on the other
Most enterprise ESPs support this via API-driven audience routing. Mid-market migrations often achieve the same effect with manual segment splits per campaign. The critical point is that overall sending volume to the domain does not drop during migration, which preserves total domain reputation.
Suppression List Coordination
The most commonly missed migration step is suppression list transfer. Every hard bounce, spam complaint, and unsubscribe on the old platform must be replicated on the new platform before the new platform ever sends to those addresses.
Export from the old ESP:
- Global suppression list (all addresses that should never receive mail)
- Hard bounce history (addresses that have hard bounced)
- Spam complaint history (addresses that have filed complaints)
- Unsubscribe list (addresses that have opted out)
- Role-based and disposable addresses that were filtered at acquisition
Import all of these into the new ESP before enabling any sending. Failing to do so creates one of the most expensive failure modes in migration: sending to known bad addresses on fresh infrastructure, spiking bounce rates, and incurring feedback loop complaints that the new platform has no history to contextualize.
Critical: A single campaign sent to a stale unsuppressed list on cold infrastructure can produce bounce rates above 15%, complaint rates above 1%, and a permanent reputation penalty at Gmail that takes 60 to 90 days to recover from. Suppression list migration is not optional and is not a post-launch step.
Monitoring During the Migration Window
ESP-reported deliverability metrics are the last place to look during migration. They lag reality by 48 to 72 hours and are calculated against acceptance, which does not distinguish between inbox and spam folder placement. Real visibility comes from three sources:
Gmail Postmaster Tools
Monitor domain reputation (not IP reputation, which is less meaningful for ESP-provided sending) daily. A drop from High to Medium during warmup is a normal transient; a drop to Low or Bad signals that the ramp is too aggressive and needs to pause.
Microsoft SNDS
Watch for any IP color change (Green to Yellow or Yellow to Red), spam trap hits, and complaint percentage rise. Microsoft responds faster to reputation signals than Google and is often the earliest warning of migration problems.
Seed List Inbox Placement Testing
Send to a seed list of test accounts across Gmail, Outlook, Yahoo, and Apple Mail weekly during warmup. Record actual inbox vs spam vs promotions placement by provider. See our deliverability improvement guide for seed list setup specifics.
Rollback Decision Criteria
Roughly 10 to 15% of enterprise migrations hit serious enough warmup problems to warrant rollback. Decide the rollback triggers before starting, not during panic:
- Gmail domain reputation drops to Bad for 3 or more consecutive days
- Microsoft SNDS shows Red status on any warmup IP
- Bounce rate on new ESP exceeds 8% for any campaign
- Spam complaint rate on new ESP exceeds 0.5%
- Inbox placement at Gmail drops below 70% on seed list tests
If any of these trigger, return 100% of sending volume to the old ESP immediately, investigate root cause, and restart warmup at week 5 after remediation. Losing 2 to 3 weeks to a rollback is dramatically better than losing 60 to 90 days of reputation.
Many ESPs will quietly assign new customers to shared IP pools with existing reputation baked in, which can dramatically accelerate warmup. Ask your new vendor explicitly whether you will be placed on a dedicated IP (full warmup required) or a shared pool (warmup still needed but shorter). Shared pools inherit the reputation, good or bad, of every other sender in the pool.
Post-Migration Optimization
Migration completion is not the end of the reputation story. Weeks 11 to 16 are when the new infrastructure settles into its long-term pattern, and small optimizations here lock in durable deliverability gains:
- Audit authentication with the old ESP removed from SPF (only after 4 weeks of stable sending)
- Progress DMARC from p=quarantine to p=reject if not already there, using a DMARC generator
- Enable BIMI if DMARC is at enforcement and brand logo display has business value
- Implement the List-Unsubscribe header and RFC 8058 one-click unsubscribe if the new ESP offers it
- Set up automated engagement-based sunset rules to prevent list decay over time
- Document the final architecture for the next migration cycle (ESP switches recur roughly every 3 to 5 years)
Frequently Asked Questions
A proper ESP migration takes 6 to 10 weeks end to end. The IP warmup ramp alone takes 4 to 6 weeks, and preparation plus validation adds another 2 to 4 weeks on either side. Attempting to compress below 6 weeks either skips warmup or involves such low volume that timing does not matter. Enterprise migrations routinely take 8 to 12 weeks.
Yes, but not automatically. Domain reputation (tied to your organizational domain and DKIM signing) is portable across ESPs and preserves most of your standing. IP reputation is tied to specific sending IPs and does not migrate. A properly executed parallel-send migration with a managed IP warmup preserves 80 to 90% of effective deliverability through the transition.
Migrate your whole list to the new ESP as a data operation in week 3 or 4, but only send to segments of it during warmup. The full list lives on the new platform from week 3 onward, but sending begins with only the most engaged subscribers in week 5 and expands gradually. Inactive subscribers who have not engaged in 12+ months should generally not be imported or sent to at all.
Rushed warmup to full volume in the first two weeks after migration. Business pressure to hit revenue targets often collides with the technical need for a 4 to 6 week ramp, and marketing teams push through the warmup schedule. The result is a compromised reputation on the new platform that takes 60 to 90 days to recover, often longer than the original migration timeline.
Yes. IP reputation does not follow you to a new ESP. Each dedicated IP starts with no sending history at receiving providers, and the warmup ramp rebuilds that history. Domain reputation and DKIM-based reputation partially carry over, so the warmup is typically faster than a brand new sender, but the 4 to 6 week ramp is still required.