ESP Migration Playbook: Switch Providers Without Killing Deliverability

Why Migrations Go Wrong

The typical migration: company signs up with new ESP on Monday, migrates entire list on Tuesday, sends a campaign on Wednesday. By Thursday, deliverability has crashed.

Why? The new ESP means new IPs with no reputation. They need a proper warmup. Even with perfect authentication, ISPs don't trust new sending patterns from unfamiliar IPs. Add to that the common errors (forgotten DNS records, different sending patterns, list format changes), and you have a recipe for disaster.

The Safe Migration Process

Phase 1: Preparation (Week 1)

Before touching any traffic:

1. Set up the new ESP completely

   • Create account, verify identity
   • Add your sending domain
   • Configure SPF (add new ESP's include to your existing record)
   • Configure DKIM (add new ESP's DKIM records alongside existing)
   • Verify DMARC is published and monitoring

2. Configure custom tracking domain on the new ESP

3. Import your list to the new ESP

   • Clean the list before import (validate with ZeroBounce/NeverBounce)
   • Segment by engagement: hot (opened 30 days), warm (opened 90 days), cold (90+ days)

4. Recreate automation workflows on the new ESP

   • Welcome sequences, abandoned cart, post-purchase
   • Test with internal addresses before going live

5. SPF record during overlap:

v=spf1 include:old-esp-spf include:new-esp-spf -all

Both ESPs must be in SPF simultaneously during migration.

Phase 2: Gradual Traffic Migration (Weeks 2-5)

Week 2: Send to your most engaged segment (opened in last 30 days) through the new ESP. Keep sending everything else through the old ESP.

• Volume: 10-20% of total traffic on new ESP
• Monitor: Google Postmaster Tools, bounce rates, spam complaints

Week 3: Shift more engaged recipients to new ESP.

• Volume: 30-40% on new ESP
• Old ESP handles remaining 60-70%
• Check: reputation building on new ESP? Any delivery issues?

Week 4: Majority of traffic on new ESP.

• Volume: 60-80% on new ESP
• Old ESP handles remaining 20-40% (least engaged)
• If dedicated IP on new ESP: should be well into warmup by now

Week 5: Full traffic on new ESP.

• Volume: 100% on new ESP
• Old ESP: standby only (keep active for rollback)
• Verify: all metrics stable, no deliverability regression

Phase 3: Decommission (Weeks 6-8)

1. Confirm all metrics stable for 2+ weeks on new ESP
2. Remove old ESP from SPF record
3. Remove old ESP's DKIM records (optional — they don't hurt anything if left)
4. Cancel old ESP account
5. Update DMARC monitoring to confirm no failures from old infrastructure

DNS Cutover Timeline

Day	SPF Record	DKIM Records	Active ESP
Day 1	Old + New	Old + New	Old (100%)
Week 2	Old + New	Old + New	Old (80%) + New (20%)
Week 3	Old + New	Old + New	Old (60%) + New (40%)
Week 4	Old + New	Old + New	Old (20%) + New (80%)
Week 5	Old + New	Old + New	New (100%)
Week 7	New only	New only	New (100%)

What to Monitor During Migration

• Google Postmaster Tools: Watch domain reputation daily. Any drop = slow down migration.
• Bounce rate on new ESP: Should stay under 2%. Higher = list quality issue.
• Spam complaint rate: Must stay under 0.1%. Higher = pause and investigate.
• Open/click rates: Compare between old and new ESP. Significant drop = delivery issue.
• DMARC reports: Verify both ESPs show as passing authentication.

Emergency Rollback

If the new ESP's deliverability crashes during migration:

1. Stop sending from the new ESP immediately
2. Shift all traffic back to old ESP (it's still configured and running)
3. Investigate the cause (authentication failure, IP reputation, list issue)
4. Fix the issue
5. Restart migration from Phase 2, slower

This is why you keep the old ESP running throughout migration. It's your safety net.

Practitioner note: The most common migration failure I see: companies move from Mailchimp to Klaviyo, import their full 100K list, and blast a campaign on day one. Klaviyo's shared IPs are different from Mailchimp's. The sending pattern is different. ISPs see an unfamiliar pattern and filter aggressively. Always start with engaged segments at low volume.

Practitioner note: Watch your SPF lookup count during overlap. Both ESPs in one SPF record might exceed 10 lookups. If so, use subdomain routing: run the new ESP from marketing.yourdomain.com with its own SPF record while the old ESP continues on yourdomain.com.

Practitioner note: Don't forget transactional email during marketing ESP migration. If your transactional runs on the same ESP, migrate it separately. Or better: use a dedicated transactional service (Postmark) that doesn't change during marketing ESP migrations.

If you're planning an ESP migration and want it done without deliverability risk, schedule a consultation — I manage ESP migrations for businesses that can't afford downtime.

Sources

• Google: Email Sender Guidelines
• Klaviyo: Migration Guide

---

v1.0 · March 2026