Email Infrastructure Migration: The Complete Playbook
Moving from a shared ESP to dedicated infrastructure — the 4–8 week timeline, what carries over and what doesn't, suppression list migration, IP warm-up, and the DNS checklist that prevents deliverability failures on day one.
What Transfers and What Doesn't
The most important thing to understand before planning a migration: domain reputation transfers, IP reputation does not. This single fact determines the entire migration strategy.
✓ Transfers with you
- Domain reputation at Gmail and Yahoo
- Subscriber engagement history (tied to your domain)
- DMARC policy and aggregate report history
- Your subscriber list and consent records
- Your suppression list (unsubscribes, bounces)
- Your email templates and campaign data
✗ Starts fresh on new IPs
- IP reputation — every new IP starts with zero history
- Per-IP sending limits with ISPs
- IP-level allowlisting at corporate mail filters
- Feedback loop registrations (must re-register)
- Microsoft JMRP/SNDS data for new IPs
- Postmaster Tools IP-level data
You cannot simply cut over all traffic to the new infrastructure on day one. New IPs have no reputation — ISPs will throttle or reject high-volume sends from them, regardless of how good your domain reputation is. The gradual approach is not optional; it is the only path that avoids a deliverability collapse.
The 4–8 Week Migration Timeline
Based on observed migration patterns, a well-executed migration to dedicated email infrastructure takes 4–8 weeks depending on list size and current volume. Lean migrations with a dedicated team and smaller lists can achieve full cutover in 4 weeks. Complex multi-brand or high-volume migrations require the full 8 weeks. Rushing is the #1 cause of post-migration deliverability crashes.
Setup, Authentication & Suppression Migration
- ✓ Server provisioning and OS configuration
- ✓ MTA installation and initial configuration (PowerMTA, KumoMTA, or Postfix)
- ✓ DNS: publish new DKIM selectors, update SPF to include new IPs, set PTR records
- ✓ DMARC: set to p=none monitoring mode during migration
- ✓ Import suppression list first — unsubscribes, hard bounces, FBL complaints
- ✓ Register new IPs with Yahoo FBL and Microsoft JMRP
- ✓ Verify authentication end-to-end: send test to mail-tester.com — must score 9+/10
Gradual Traffic Migration — 10% to 40%
- ✓ Route 10% of volume through new infrastructure in week 2 — engaged subscribers only (opened within 90 days)
- ✓ Old infrastructure remains active and handles remaining 90% — overlapping sends is intentional
- ✓ Monitor: Gmail Postmaster Tools domain reputation, SNDS per-IP status, deferral rates at Gmail/Yahoo/Microsoft
- ✓ If no negative signals: increase to 25% in week 2 day 4, 40% by end of week 3
- ✓ If deferral rate exceeds 20% at any ISP: hold current split and investigate before increasing
Majority Traffic — 40% to 85%
- ✓ Continue increasing weekly: 55% → 70% → 85% — always monitoring complaint and deferral rates
- ✓ Begin including less-engaged segments (opened 90–180 days) in the new infrastructure sends
- ✓ Verify DMARC alignment on all mail now flowing through new infrastructure
- ✓ Check DNSBL status weekly — new IPs are most vulnerable during the first 4 weeks of sending
- ✓ Inbox placement testing: seed tests to Gmail, Outlook, Yahoo weekly
Full Cutover and Old Infrastructure Decommission
- ✓ Route 100% of traffic through new infrastructure
- ✓ Keep old infrastructure in standby (not sending) for 2 weeks as rollback option
- ✓ Remove old IPs from SPF record after 2-week standby period
- ✓ Export and archive all historical data from old ESP before access expires
- ✓ Decommission old infrastructure after confirmation that all monitoring is healthy
Suppression List Migration — The Step Most Teams Miss
The suppression list must be migrated before any sends from the new infrastructure. This is the step most teams either skip or treat as an afterthought, and it is the single most common cause of immediate post-migration complaint spikes.
What to export from the old ESP and import into the new system before day one:
After importing suppression lists into the new system, run a test send of 100 emails to a randomly sampled set of suppressed addresses — using your MTA's logging only, not actual delivery — to verify that the suppression logic is working. Any send that would have gone to a suppressed address should generate a log entry showing "suppressed" rather than a delivery attempt.
DNS Configuration Checklist
DNS errors during migration are the most common cause of authentication failures that silently destroy deliverability on the new infrastructure. Complete this checklist before the first send:
Transactional Email — Migrate Separately
If your current ESP handles both marketing and transactional email on the same infrastructure, migrate them separately — not simultaneously. Transactional email (2FA, order confirmations, password resets) has zero tolerance for delivery delays. The gradual traffic-shifting approach appropriate for marketing sends creates exactly the kind of delivery uncertainty that is unacceptable for time-sensitive transactional messages.
The recommended sequence: migrate transactional email to a dedicated transactional relay first (ideally using an established provider with pre-warmed IPs), then execute the marketing infrastructure migration independently. Once the marketing migration is complete and stable, move transactional to the new dedicated infrastructure if that was the target state.
This approach isolates risk: a deliverability issue on new marketing IPs cannot cascade to affect your 2FA delivery.
Post-Migration Monitoring — The First 30 Days
The 30 days after full cutover are the highest-risk period of any email infrastructure migration. New IPs have limited reputation history, ISPs are evaluating your sending patterns with fresh eyes, and any configuration errors that were masked during gradual rollout become fully visible at scale.
| Metric | Check frequency | Alert threshold | Source |
|---|---|---|---|
| Domain reputation (Gmail) | Daily | Any drop to Low | Postmaster Tools |
| Spam rate (Gmail) | Daily | > 0.08% | Postmaster Tools |
| Per-IP status (Outlook) | Every 2 days | Any Red/Yellow | Microsoft SNDS |
| Blacklist status | Daily | Any new listing | MXToolbox / Spamhaus |
| Hard bounce rate | Per campaign | > 2% | MTA delivery logs |
| Inbox placement rate | Weekly | < 85% | Seed test tool |
If any metric crosses an alert threshold: pause volume increases immediately, investigate the specific signal, and resolve before resuming. Post-migration problems caught within 48 hours are almost always recoverable. Problems ignored for a week can require partial re-warming of affected IPs.
Rollback Plan
Every migration needs a rollback plan — a documented, tested procedure for reverting all traffic to the old infrastructure if a critical problem emerges on the new one. The rollback window is typically the 2-week standby period after full cutover. After that window, the old infrastructure is decommissioned and rollback is no longer available without rebuilding it.
The rollback procedure is simple: revert DNS SPF record to old IPs, update your MTA or sending platform to route traffic to the old relay, and notify the team. SPF changes propagate within minutes to an hour. If you are using a sending platform that routes via the new relay, the cutover back is a configuration change, not a DNS emergency. Keep the old infrastructure's credentials and configuration documented and accessible for the entire standby period.
Managed Migration to Dedicated Infrastructure
We handle the full migration from shared ESP to dedicated EU infrastructure: server provisioning, authentication setup, suppression list migration, IP warm-up schedule, and 8-week post-migration monitoring. No deliverability surprises — the migration is planned before it starts.
Migration at a Glance
4–8 weeks
Transfers ✓
Starts fresh ✗
Rushing the timeline
Import suppression list