Migrations fail when they are treated as a configuration task rather than a reputation transition. Shared ESPs carry reputation you have built over years. Moving to new dedicated IPs resets that reputation to zero — and warming it correctly requires a structured approach that most teams only discover after the first failed attempt.
When you move from a shared ESP to dedicated IPs, your sending domain carries reputation — but your new IPs carry none. ISPs see new IPs sending at volume as a strong spam signal. A migration that immediately sends at full production volume from new IPs produces high deferral rates, blacklisting events, and deliverability worse than the shared ESP you left.
| Factor | Shared ESP | Dedicated Infrastructure |
|---|---|---|
| IP reputation control | Shared with all ESP customers | 100% yours — isolated |
| Reputation event containment | Co-tenants affect your IPs | Your behavior only |
| Per-ISP throttle control | ESP policy — no customisation | Full per-domain configuration |
| Traffic type separation | Usually not available | Full transactional/bulk/cold isolation |
| Cost at scale | Increases linearly with volume | Fixed infrastructure cost |
| Initial setup complexity | None | 4–8 weeks warming required |
Review current ESP metrics: inbox placement, bounce rates, complaint rates, per-ISP deferral patterns, list quality. Establish baseline measurements that will be used to validate the migration success.
Dedicated IP provisioning, PowerMTA installation and configuration, DNS setup (SPF, DKIM, DMARC, PTR), MailWizz deployment if required. Full authentication verification before any sending begins.
New infrastructure operates in parallel with the existing ESP. During warming, a portion of volume routes through the new infrastructure while the ESP continues handling the remainder. This eliminates cutover risk entirely.
Warming begins with the highest-engagement list segments. Gmail, Outlook, and European ISPs are warmed on separate pools with ISP-specific volume schedules. Weekly volume targets are adjusted based on actual deferral rate data, not calendar dates.
As warming progresses, traffic shifts: 10% new infrastructure / 90% ESP → 30/70 → 50/50 → 80/20 → 100% new. The migration is reversible at any stage if warming signals indicate a problem.
After 2–4 weeks of 100% new infrastructure operation with stable delivery metrics, the ESP subscription is cancelled. Continued monitoring for 30 days post-cutover to confirm stability.
Tell us your current ESP, monthly volume, and whether you're experiencing active deliverability problems or planning a proactive move. We will outline the appropriate migration approach for your situation.
