A successful migration from a SaaS ESP (Mailchimp, SendGrid, Klaviyo, Brevo, etc.) to managed dedicated infrastructure takes 4 to 8 weeks of overlap — not a flip-the-switch cutover. The non-negotiables: build full authentication (SPF, DKIM, DMARC) at the new infrastructure before sending a single message, run both ESPs in parallel during the warming period, start with your most engaged segment at low volume, gradually shift traffic over weeks (never days), and only decommission the old ESP after the new one shows stable reputation. The piece that kills most migrations isn't infrastructure failure — it's impatience with the warming curve.
Why senders migrate away from SaaS ESPs in 2026
The decision to leave Mailchimp, SendGrid, Klaviyo, Brevo, or ActiveCampaign for dedicated infrastructure is rarely about features. It is almost always about one of four structural realities of SaaS ESP pricing and operational models.
1. Pricing curves that bite at scale
The pricing crossover where dedicated infrastructure becomes economical varies by ESP but follows a predictable shape. SaaS ESPs price on contacts or volume; dedicated infrastructure prices on capacity. Past a certain point, the gap is not small.
| List size / volume | Mailchimp (Standard) | Klaviyo | SendGrid (Pro) | Dedicated managed infra |
|---|---|---|---|---|
| 10K contacts / 100K msg/mo | ~$57/mo | ~$150/mo | ~$90/mo | ~$200–$400/mo |
| 50K contacts / 500K msg/mo | ~$270/mo | ~$500/mo | ~$249/mo | ~$400–$800/mo |
| 100K contacts / 1M msg/mo | ~$500/mo | ~$1,100/mo | ~$449/mo | ~$600–$1,200/mo |
| 500K contacts / 5M msg/mo | ~$2,200/mo | ~$3,800/mo | ~$1,499/mo | ~$1,200–$2,500/mo |
| 1M+ contacts / 10M+ msg/mo | $4,000+/mo | $7,000+/mo | $3,000+/mo | ~$2,000–$5,000/mo |
The crossover where dedicated infrastructure becomes cheaper than SaaS ESPs tends to land around 100K–200K contacts for marketing platforms and around 500K–1M messages per month for transactional sending. Below that, the operational overhead of self-hosting usually outweighs the savings; above it, the math flips quickly.
2. Deliverability ceiling on shared infrastructure
SaaS ESPs run shared IP pools by default. Your reputation is co-mingled with every other sender on the same pool, which means a single bad sender on the pool can degrade your delivery even when your own sending is impeccable. Dedicated IPs are available as paid add-ons on most platforms but rarely as part of the base plan.
Beyond shared IPs, SaaS ESPs apply uniform sending policies across customers — the same retry behaviour, the same warm-up curve, the same per-ISP throttling defaults — that are tuned for an average customer rather than for any specific sender. For senders whose audience or content pattern is non-average, the SaaS defaults produce worse results than dedicated tuning would.
3. Compliance and data residency requirements
EU senders moving to dedicated infrastructure usually do so because their SaaS ESP cannot guarantee EU-only data residency or because the contractual data-processing terms expose customer data to US-based processors. GDPR Article 28 and the Schrems II case law have made this a board-level concern at many EU companies; the dedicated-infrastructure answer is "we control the data, end-to-end".
4. API rate limits and product-feature ceilings
SaaS ESPs throttle their APIs, charge per webhook event, and restrict what custom logic you can apply to outbound mail. For product teams that need to send millions of transactional messages with custom routing logic, the SaaS ESP becomes a bottleneck rather than an enabler. Dedicated infrastructure exposes the full MTA capability set: per-message routing decisions, custom headers, per-recipient throttling, sub-account isolation that doesn't require enterprise-tier contracts.
What you lose by migrating — an honest list
Before the migration mechanics, the trade-offs you accept by leaving a SaaS ESP. Pretending these don't exist is the source of most migrations that go badly.
| What SaaS ESPs provide | What you give up | How to replace it |
|---|---|---|
| Drag-and-drop campaign builder UI | The marketing team's ability to send without engineering involvement | Self-hosted app (MailWizz, Mautic, Listmonk) or build a custom UI on top of the MTA |
| Pre-built automation flows (welcome series, cart abandonment, post-purchase) | The library of templated automations | Application-layer logic via Mautic, custom code, or migration to a marketing automation platform that pairs with your MTA |
| Aggregated deliverability reporting | Single-dashboard view of open/click/bounce metrics | Self-hosted analytics (Postal's dashboard, custom Grafana, or commercial analytics tools) |
| Spam compliance assistance (List-Unsubscribe, CAN-SPAM footer) | The "set it and forget it" compliance layer | Configure compliance manually; the rules are documented and the headers are standard |
| Suppression list management | Automatic add to suppression on bounces, complaints, unsubscribes | Build the suppression pipeline yourself or use an MTA (PowerMTA, Postal) with built-in suppression |
| Vendor support during incidents | The "call SendGrid support" escape hatch | Managed-infrastructure vendor provides this; self-hosted means you are the support |
| Built-in deliverability monitoring | Real-time reputation alerting | Wire SNDS, JMRP, Google Postmaster Tools, Spamhaus monitoring yourself |
The four-phase migration playbook
The migration sequence we run for clients moving from SaaS ESPs to managed infrastructure. Four phases, 4–8 weeks total, with explicit gates between phases.
Preparation — before any traffic moves
The phase that determines whether the migration succeeds or fails. Done right, it takes one to two weeks. Skipped, the migration burns weeks of recovery work later.
Checklist
- Inventory the current ESP fully. Lists, segments, automations, templates, suppression list, custom domains, dedicated IPs (if any), API integrations, webhook subscribers, historical reports, transactional templates. Export everything that can be exported.
- Document the current authentication setup. Run
dig TXT yourdomain.comand capture SPF;dig TXT default._domainkey.yourdomain.com(or the selector your ESP uses) for DKIM;dig TXT _dmarc.yourdomain.comfor DMARC. - Clean the list. Remove hard bounces, unsubscribes, and contacts who have not engaged in 90+ days. Run remaining addresses through email verification to catch spam traps and invalid syntax. This is the single most consequential pre-migration step — warming up a new IP with a dirty list guarantees deliverability problems.
- Plan the DNS changes but do not apply them yet. New ESP's SPF include, new DKIM keys, DMARC policy review.
- Inventory the suppression list. Export it from the current ESP. This is the legally consequential data — subscribers who unsubscribed must remain suppressed after migration.
- Map automations to the new platform. Each welcome series, cart abandonment, post-purchase flow needs an equivalent on the new infrastructure. List them; assign priorities.
New infrastructure setup — authentication and infrastructure ready
The new sending infrastructure goes live but no production traffic flows through it yet.
Checklist
- Provision the new infrastructure. Dedicated IPs assigned, MTA configured (PowerMTA, Postfix, Postal — see our MTA comparison for selection), DKIM keys generated, reverse DNS set, HELO/EHLO configured.
- Add the new ESP's SPF include to your domain — ALONGSIDE the old one, not replacing it.
v=spf1 include:old-esp.com include:new-infra.com ~all. Both must remain authoritative during overlap. - Add the new DKIM record at a different selector than the current one. Old ESP uses selector
esp1._domainkey; new infrastructure usesmta2026._domainkey(or similar). Both keys live in DNS simultaneously. - Review DMARC policy. If you are at
p=reject, make sure both SPF and DKIM align to the new infrastructure before any send. Misalignment at p=reject means the message is rejected, not quarantined. - Configure the suppression list on the new infrastructure using the export from Phase 1. Every previously-unsubscribed address must be loaded before the first send.
- Wire up monitoring. SNDS for Microsoft, Google Postmaster Tools, JMRP feed routing, complaint rate alerting, bounce classification dashboard. Read our SNDS, JMRP, and FBL entries for the configurations.
- Send internal test messages from the new infrastructure to test accounts at Gmail, Outlook.com, Yahoo, iCloud. Verify SPF passes, DKIM passes, DMARC aligns. Use mail-tester.com or equivalent for a 10/10 score before proceeding.
IP warming and parallel sending
The new infrastructure starts sending production traffic, but at low volume and to your most engaged segment first. The old ESP continues serving the rest of the list during this period.
The warming curve
| Day | Volume (new IP) | Audience segment | Watch for |
|---|---|---|---|
| Day 1–3 | ~50–100 msg/day | Internal team, seed list, opens-in-7-days | Authentication pass, no bounces, no complaints |
| Day 4–7 | ~500–1,000 msg/day | Opens-in-30-days | Inbox placement at all four major providers |
| Day 8–14 | ~2,000–5,000 msg/day, doubling each 2 days | Opens-in-90-days | Complaint rate <0.1%, bounce rate <2% |
| Day 15–21 | ~10,000–50,000 msg/day | Active engagers (clicks last 90 days) | Reputation green at SNDS, Gmail Postmaster Tools |
| Day 22–28 | ~100,000+/day | Broader engaged list | Stable reputation across all monitoring |
| Day 28+ | Full production volume | Full list (still excluding 90-day inactives) | Sustained delivery; cutover decision |
The abort conditions
Three explicit thresholds at which the warming pauses and goes back a step:
- Complaint rate above 0.10% at any single send. Pause; investigate which segment is the source via JMRP. Resume only at the previous volume tier.
- SNDS turns Yellow. Pause new sends; let the data age out 48–72 hours; resume at the previous tier.
- Hard bounce rate above 5%. Stop. Hard bounces at this rate indicate list quality failure, not infrastructure failure. Reclean the list before resuming.
Cutover and decommission
The new infrastructure handles all production traffic; the old ESP is decommissioned.
Checklist
- Verify all automations have been replicated and tested on the new infrastructure. The welcome series fires; the cart abandonment trigger fires; the post-purchase flow fires.
- Run side-by-side for one additional week with new traffic on new infrastructure and any historical drips on old. This catches anything that was missed in Phase 3.
- Verify suppression list parity. Anyone who unsubscribed during Phase 3 should be suppressed on both the old and new platforms. Run an export-compare to verify.
- Update SPF to remove the old ESP's include. Once the old ESP is no longer sending, the SPF include is a security risk — leaving authorisation for a service you no longer use is an attack surface.
- Keep DKIM keys in DNS for 30 days after decommission. Messages already in transit, or stored by receiving servers for later display, may need to verify against the old key. Pulling DKIM the day you cut over breaks those verifications.
- Export historical reports from the old ESP before cancelling the account. Open rates, click rates, complaint history, suppression list final state, campaign performance — this data is irretrievable after the account closes.
- Document the new infrastructure for the team that will operate it ongoing. Runbook for incidents, monitoring dashboards, escalation contacts.
Per-ESP migration notes — specifics for each origin
The general playbook applies regardless of source ESP, but each major SaaS ESP has specific export quirks, API differences, and gotchas worth knowing in advance.
From Mailchimp
- Export format: CSV from Audience → Manage contacts → Export. Contact tags export as columns; segments do not export directly — recreate them at the new platform from the contact attributes.
- Suppression list: Export from Audience → Unsubscribes. Includes hard bounces, unsubscribes, and complaints.
- Automation export: Mailchimp does not export Customer Journeys natively — document them manually before cancelling.
- Specific landing page: Migrate from Mailchimp guide.
From SendGrid
- Export format: CSV via Marketing → Contacts → Export. API access for programmatic export is more flexible than the UI.
- Suppression list: Export via Suppressions → Bounces / Blocks / Spam Reports / Unsubscribes. SendGrid splits suppression into four categories; all must be migrated.
- Transactional templates: Dynamic templates export as JSON. Custom domain-authenticated subdomains used for tracking links need to be reconfigured on the new infrastructure.
- Specific landing page: Migrate from SendGrid guide.
From Klaviyo
- Export format: CSV from Lists & Segments. Klaviyo's profile data is rich (predictive analytics, CLV, event history) and most of it does not translate cleanly to a non-Klaviyo platform.
- Suppression list: Available via Profiles → Filter by status. Klaviyo distinguishes between unsubscribed, suppressed, and bounced — all three classes must be brought across.
- Flows: Klaviyo flows are arguably the platform's strongest feature and the hardest thing to leave behind. Document each flow with its triggers, conditions, send timings, and content before migrating. Recreating flows on Mautic or similar takes 2–4 weeks of additional effort.
- Specific landing page: Migrate from Klaviyo guide.
From Brevo (formerly Sendinblue)
- Export format: CSV from Contacts. Brevo's segmentation is simpler than Klaviyo's and exports cleanly.
- Suppression list: Statistics → Suppressed contacts.
- Transactional + marketing split: Brevo unifies both in one platform; on dedicated infrastructure you typically separate them onto different IP pools. Plan the split during Phase 1.
From ActiveCampaign
- Export format: CSV from Contacts. Tags export as a column.
- Automations: ActiveCampaign's automations are visual workflows; export the JSON for each automation as a record before cancelling.
- Specific landing page: Migrate from ActiveCampaign guide.
From Amazon SES
- Different shape entirely. SES is closer to an SMTP relay than a marketing ESP; migration usually means switching the SMTP credentials and DNS records.
- No campaign data to export. SES has no UI for marketing campaigns; whatever marketing tooling was used on top of SES is what holds the data.
- Specific landing page: Migrate from Amazon SES guide.
Risk matrix — what can go wrong and how to prevent it
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| IP reputation never builds | Medium | Severe (delivery degraded for months) | 4-week warming with engaged segments; never compress timeline |
| Suppression list incomplete | Medium | Severe (legal + reputation; previously unsubscribed users receive mail) | Export every suppression category; verify count matches; reload before first send |
| Authentication misconfiguration | High | Severe (immediate deliverability failure) | Test send to all four major providers; verify SPF/DKIM/DMARC pass before scale |
| Automation gap (welcome series broken) | High | Moderate (lost revenue from broken flows) | Replicate and test every automation before cutover; keep old ESP active until verified |
| Historical data lost | Medium | Moderate (no baseline for comparison) | Export all reports before cancelling account; archive for at least 12 months |
| DNS propagation delay | Low | Moderate (delivery interruption during cutover) | Lower TTL to 300s a week before changes; restore to 3600s after |
| Webhook integrations break | Medium | Moderate (downstream systems miss events) | Inventory all webhook consumers; reconfigure pointing to new infrastructure |
| Old ESP cancelled before parity verified | Low | Severe (no rollback option) | Keep old ESP active for 30 days after cutover; pay the prorated cost as insurance |
Cost model — what migration actually costs
The cost of migration itself, separate from the ongoing infrastructure cost.
For senders moving to managed dedicated infrastructure
| Cost component | Range | Notes |
|---|---|---|
| Discovery and planning | $2,000–$5,000 | List audit, automation inventory, authentication review |
| Infrastructure provisioning | $1,000–$3,000 | Dedicated IPs, MTA setup, DKIM configuration, monitoring |
| 4-week warming period | $1,500–$4,000 | Engineering supervision, monitoring, abort/resume decisions |
| Automation rebuild | $2,000–$10,000+ | Depends on platform complexity; Klaviyo flows are the most expensive |
| Cutover and verification | $1,000–$2,500 | DNS changes, parity verification, decommission |
| Total typical migration | $7,500–$25,000 | One-time; recovered through reduced ongoing ESP cost within 3–12 months for senders above the crossover threshold |
For senders attempting self-hosted
Multiply the above by 1.5–2x to account for the additional engineering work building the monitoring, suppression, and compliance layers that managed providers bring out of the box. The crossover where self-hosted is cheaper than managed dedicated is typically around 10M+ messages per month with a dedicated infrastructure engineer on staff.
When NOT to migrate
The honest list of situations where staying on a SaaS ESP is the right call:
- Sending volume below 100K messages per month. The math does not work; SaaS ESP cost is lower than dedicated infrastructure cost at this volume.
- No dedicated infrastructure engineer. Even managed infrastructure assumes some level of operational engagement from the client side; without anyone owning the account, the migration produces worse outcomes than staying put.
- Heavy use of ESP-native features. If your team's workflows depend on Klaviyo's predictive analytics, Mailchimp's journey builder, or HubSpot's CRM integration, migrating away costs the value those features provide. Self-hosted alternatives exist (Mautic, Listmonk) but the feature parity is partial.
- Imminent deliverability crisis. Migrating during a reputation problem makes everything worse; fix the deliverability issue first, then evaluate whether the SaaS ESP's constraints contributed to it. Often they did not.
- No 4–8 weeks of runway. A migration compressed into 2 weeks fails predictably. If the business cannot afford the runway, the migration is not yet feasible.
CSE perspective — how we run migrations
Cloud Server for Email's managed migration practice has run several hundred ESP migrations across Mailchimp, SendGrid, Klaviyo, Brevo, ActiveCampaign, HubSpot, Amazon SES, Constant Contact, Campaign Monitor, Mailgun, and Salesforce Marketing Cloud as sources. The pattern we follow is the four-phase playbook above, executed with these client-side handoffs:
- We own the technical work: infrastructure provisioning, MTA configuration, DNS guidance, IP warming, authentication, monitoring setup, the cutover.
- The client owns: the list export, the automation inventory, the historical-report export, the marketing-side decisions about segmentation and messaging during warming, and the cancellation of the old ESP.
- Joint responsibility: the warming schedule (we propose, client approves volume jumps at each tier), the abort decisions (we surface threshold breaches; client decides whether to pause or rollback), the suppression list verification (we provide the tooling; client verifies the data).
The typical migration takes 5–6 weeks with this division of labour. Migrations under 4 weeks are technically possible but require an unusually clean list, simple automation structure, and engaged audience — not the norm. Migrations over 8 weeks usually indicate scope expansion (combining migration with a list-cleanup or rebrand project, which we recommend separating).
Related concepts and resources
- PowerMTA vs Postfix vs Postal — the MTA selection decision for the new infrastructure
- 2026 email marketing benchmarks — the deliverability thresholds the warming process needs to keep you within
- Microsoft Outlook policy rejects 2026 — the post-May-2025 enforcement that affects every migration
- SNDS, JMRP, Feedback Loop — the monitoring and complaint-handling you must wire up before the first send
- IP Warming — the underlying concept and the warming-curve specifics
- MPP — why open-rate-based metrics for warming success are unreliable in 2026
- Email deliverability audit — what we run before recommending migration to anyone
- Migration index — the per-ESP landing pages with specific export instructions