Migration Hub
Leaving a shared ESP is half a decision and half a calendar.
Most migration content tells you how to export contacts. That's the easy part. The hard part is knowing whether the move is right for you, when to do it, and what to expect from your IP reputation in the four to six weeks after launch. This hub covers all three — and links to specific guides for the ten ESPs whose migration paths we run most often.
Below this, dedicated infrastructure usually loses to a well-managed shared pool.
The technical migration takes days. The reputation phase that follows takes weeks.
The most common migration disaster: suppressed contacts re-emerge as a fresh active list.
January–March. Avoid late October through December — Q4 ISP filtering is unforgiving.
When does migration make sense?
Three signals point to "migrate now." The first is a hard volume floor. Below 50,000 emails a month, dedicated IPs sit cold for too long — you spend the warming period on bad placement to save shared-pool friction that was never actually hurting you. The second signal is reputation contamination from neighbours in your shared pool. If you can confirm (via Postmaster Tools or seedlist data) that your sender reputation is below your sending behaviour deserves, the pool is the variable to remove. The third is feature ceiling: when your ESP's feature surface no longer matches what your programme needs, and the path forward requires either a sidegrade to another ESP or a step up to dedicated infrastructure.
Migration is wrong when none of those three apply. Volume below 25,000 a month with stable shared-pool placement is a programme whose problems live somewhere other than the IP. Migrating that programme produces a 4-6 week reputation valley followed by performance equivalent to where it started.
The migration timing matrix
| Monthly volume | Dedicated IPs? | Warming time | Realistic ROI window | Notes |
|---|---|---|---|---|
| < 25K | Don't migrate | — | Negative | Use a reputable shared pool. Volume is too low to warm a dedicated IP without sustained throughput. |
| 25K – 50K | Probably not | 6-8 weeks if forced | 12+ months | Edge case. Only if shared pool reputation is verifiably damaging your specific traffic. |
| 50K – 100K | Conditional | 4-6 weeks | 6-9 months | The break-even zone. Migrate only with a clear "why" — feature ceiling, isolation, or compliance. |
| 100K – 500K | Yes | 4-5 weeks | 3-6 months | Sweet spot for managed dedicated infrastructure. Warming volume is comfortable; control is real. |
| 500K – 5M | Yes — multi-IP | 3-5 weeks | 2-4 months | Plan for 2-4 IPs minimum, with stream separation between marketing and transactional. |
| 5M+ | Self-hosted MTA | 2-4 weeks | 1-3 months | Above this volume, self-hosted PowerMTA or KumoMTA on dedicated hardware competes seriously with managed providers on cost. |
The volume thresholds are not arbitrary. They reflect what mailbox providers expect to see for IP reputation to stabilise. A dedicated IP needs sustained, consistent volume to develop a reputation profile mailbox providers can trust. Below the floor, the IP looks intermittent — and intermittent looks suspicious.
What moves, what gets rebuilt
The single biggest source of migration disappointment is the gap between what teams expect to bring across versus what actually transfers. Data moves. Workflows do not. Templates partially move. Authentication settings have to be reconfigured at the new platform. The list below is calibrated against actual ESP migrations we've supported over the years — your specific platforms may shift the boundary slightly, but the categories hold.
Moves with export/import
- Contact lists (CSV export from any ESP)
- Suppression list (this is the one most often forgotten)
- Bounce history and complaint events
- Email templates as raw HTML
- Sending domain (DNS records reconfigured at new infrastructure)
- Subscriber metadata: tags, custom fields, signup timestamps
- Engagement history if exported in time (last open, last click)
Has to be rebuilt
- Automation flows and behavioural triggers
- Drag-and-drop visual templates (export only renders raw HTML)
- Vendor-specific segmentation logic
- Predictive analytics and AI-driven personalisation
- Integrations with third-party tools (CRM, analytics, ad platforms)
- Tracking pixels and click redirects pointing at the previous ESP
- API integrations using the old ESP's webhooks and event format
A practical checklist: before you cut over, run an export of your suppression list and verify it has rows. The number should be in the same order of magnitude as your active list, often larger if the programme is mature. A suppression list export that comes back with 200 rows from a programme that has sent millions of messages is not your real suppression list — it is the recently-added subset, and the rest is still locked inside the previous ESP.
The IP warming phase nobody warns you about
After the technical migration ends, the reputation phase begins. Your domain has a history. Your new IP does not. Mailbox providers read the combination as a partial trust signal: the domain looks legitimate, the IP looks suspicious, and inbox placement settles into a 4-6 week valley while the new IP earns its reputation through consistent sending behaviour.
Figure — Typical inbox placement during the post-migration warming phase
The valley is real. Plan for it. Communicate it to stakeholders before launch, not during week three when complaints start arriving. Senior marketing leaders who hear "deliverability dipped" during a migration they were told was straightforward lose confidence in the project — even when the dip is exactly what was forecast and recovery is on track.
The single largest determinant of valley depth is the order in which you send during weeks one to three. Start with your most engaged segment — recent openers, frequent clickers, last-90-days active. These contacts produce the positive engagement signals that earn the new IP its reputation faster. Sending to your full list on day one inverts this: the new IP sees the bottom-quartile engagement first, mailbox providers read low engagement as suspicious, and the valley deepens.
Migration guides by source platform
Each guide below covers the specifics of moving from that platform to dedicated PowerMTA + MailWizz infrastructure: what exports cleanly, what gets rebuilt, what the platform's specific gotchas are, and the warming protocol calibrated to typical sending patterns from that platform's customer base.
ESP → Managed Infrastructure: 2026 Playbook
The complete 4-phase methodology applicable to every ESP source. Pricing crossover analysis, what you give up, the 4–8 week overlap protocol, IP warming curve with abort conditions, risk matrix, and the cost model. Read this before the per-ESP guide below.
From Mailchimp
The most common source platform. Audience export is straightforward; automation rebuild is where most projects underestimate effort.
From SendGrid
API-first migration. Code changes are minimal if you keep transactional on SendGrid and move only marketing to dedicated.
From Klaviyo
The flow rebuild is the project. Klaviyo's flow logic does not export — plan for 2-4 weeks of reconstruction in the new system.
From Amazon SES
Already SMTP-based. The shift is from raw infrastructure with no support to managed infrastructure with active monitoring.
From Mailgun
SMTP-API compatibility means most application code keeps working. The migration is largely DNS and authentication.
From ActiveCampaign
Strong CRM coupling means careful planning around what stays in the CRM versus what moves to dedicated sending.
From HubSpot
Separate sending from CRM. The CRM stays, the sending infrastructure moves — preserves the customer record while improving deliverability.
From Constant Contact
Older ESP with good list portability. Migration is straightforward; the value-add is escaping shared IPs entirely.
From Salesforce MC
The enterprise migration. Plan 3-6 months for multi-business-unit moves; cost reduction is usually the primary driver.
From Campaign Monitor
Clean export model. The migration is technically simple; the editorial decision is often whether to consolidate brands.
Frequently asked questions
At what monthly volume does migrating to dedicated infrastructure make sense?
Does my domain reputation transfer to the new infrastructure?
How long does an ESP migration take?
What moves automatically and what has to be rebuilt?
What is the most common migration failure?
Should I migrate during peak season or avoid it?
Plan a migration with infrastructure that knows the route
We've supported migrations from every major ESP into dedicated PowerMTA + MailWizz environments at our Tallinn datacenter. Plan calibration, IP warming protocol, suppression-list verification, DNS authentication setup — handled by the team that operates the destination infrastructure, not a generalist consultant.
Schedule a migration assessment →