The standard ESP migration disaster looks like this: company signs with new provider Monday, exports the full list Tuesday, imports Wednesday, sends a campaign Thursday, watches deliverability collapse Friday. The Mailflow Authority playbook documents this exact failure mode as the most common migration failure pattern. The mechanism is structural: domain reputation transfers with your domain because it is tied to the domain, but IP reputation does not transfer because it is tied to the IPs. New IPs sending to an established recipient base look unfamiliar to mailbox providers and get filtered aggressively until those IPs have history.
Newsletter Migration Pack engineers around the failure mode. The 6-week phased plan runs both ESPs in parallel during weeks 1 through 6, migrates traffic in engagement-ordered batches (most engaged first, long tail last), maintains both ESPs in SPF and DKIM during overlap so authentication never breaks, and ramps IP volume from 200 messages per day in week 1 to 50,000 messages per day per IP by week 4. The pack handles the operational details that customers usually forget: suppression list migration (unsubscribes, hard bounces, complaints), template HTML conversion across ESP merge tag systems, automation rebuilds for welcome series and drip sequences, and daily delivery reporting through the entire 6-week window so you see exactly what is happening at every stage. One-time engagement EUR 1,999; no recurring monthly fee.
Adjust the inputs below to model your migration scope. The calculator runs the same heuristics we use during customer onboarding: list size, engagement profile, current ESP migration complexity, and infrastructure ambition determine realistic timeline and risk tier. The output is operational guidance, not marketing claims.
The phased timeline is not arbitrary. Each week targets a specific recipient engagement tier, a specific daily IP volume, and a specific operational milestone. Click a week below to see the activity, metrics tracked, and rollback criteria.
The managed ESP market in 2026 charges per contact and per send. Mailchimp, Klaviyo, ActiveCampaign, ConvertKit, and HubSpot pricing curves all bend upward as list size grows. A list of 250,000 active contacts on Klaviyo costs approximately EUR 1,500 per month at the standard tier. The same list on Mailchimp runs EUR 1,700-2,300 depending on send volume and features. HubSpot Marketing Hub Professional starts around EUR 800 and rises with contact tiers; the Enterprise tier required for serious operations runs EUR 3,200 or more. ActiveCampaign Plus and Enterprise tiers scale similarly. Above 500,000 contacts the annual cost on these platforms regularly exceeds EUR 50,000 with no upper ceiling.
Self-hosted PowerMTA plus MailWizz on dedicated infrastructure has a fixed cost structure. The PowerMTA license is a one-time or annual fee depending on commercial terms with Bird (the vendor). MailWizz is a one-time purchase. The hardware (Iron-E5 or Iron-EPYC class server) runs EUR 200-400 per month per node. Bandwidth and IP allocations scale linearly with sending volume but at commodity prices rather than ESP markup. Above approximately 250,000 contacts or 5 million sends per month, the self-hosted total cost of ownership becomes dramatically lower than managed ESP equivalents. Above 1 million contacts the differential becomes decisive: customers regularly report 70-85% cost reductions on equivalent send volumes after migration completes.
Cost is the most common driver but not the only one. Operational control is the second motivator. Managed ESPs share IP pools across their customer base; one bad-actor customer who sends spam can damage the shared IP reputation and affect every other sender on that pool. Self-hosted infrastructure puts you on dedicated IPs with no shared reputation surface; your reputation is exactly what you make it. The third motivator is jurisdictional positioning. Managed ESPs operate from specific cloud regions with specific subprocessor obligations under GDPR Article 28. Self-hosted lets you choose the datacenter jurisdiction (EU, EU candidate, non-EU non-US) that fits your compliance posture. The fourth motivator is feature ownership. Custom segmentation logic, custom merge tag systems, integration with internal data pipelines, multi-brand or whitelabel sending all become straightforward on self-hosted infrastructure.
The migration risk is real and structural. ESP migration done wrong destroys deliverability for weeks or months. The Mailflow Authority playbook, updated March 2026, describes the most common migration failure pattern: company signs Monday, migrates Tuesday, sends Wednesday, deliverability crashes Thursday. The mechanism is structural. IP reputation does not transfer because it is tied to the IPs, not the domain. Domain reputation transfers (it is tied to the sending domain) but the IP reputation starts fresh on the new infrastructure. ISPs that were familiar with your old IP pattern see unfamiliar new IPs and filter aggressively until those IPs have history. Without phased warmup, the new IPs never get the chance to build that history because early sends get filtered, engagement drops, the algorithm sees low engagement, and the spiral continues downward.
The 6-week phased migration is designed specifically around this failure mode. The mechanism: keep both ESPs operational during the overlap period, send to the most engaged segment through the new infrastructure first because engaged recipients generate strong positive signals (opens, clicks, low spam complaints) that train the ISP reputation algorithm favourably, expand to less engaged segments only after the strong signals are established, and retire the old ESP only after the new infrastructure has demonstrated independent reputation. Daily delivery reports throughout the 6 weeks make the progression visible rather than waiting until the end to discover problems. Rollback to old ESP is possible at any point during weeks 1-5 if metrics deteriorate; this gives the migration a safety net that single-day cutovers lack.
What we are explicit about: migration is not a reputation reset. Customers occasionally hope that moving ESPs will fix a deliverability problem. It will not. Your domain reputation comes with you. If you had problems on Mailchimp, you will have those problems on self-hosted infrastructure too. We are honest about this during onboarding. For operations arriving with damaged reputation, we recommend Reputation Recovery as a precursor (a separate structured rehabilitation program addressing the root causes) before attempting migration. Migrating with known reputation problems leads to predictable outcomes; we would rather decline a migration engagement than deliver a predictable failure.
Phased plan customised to your list size, segment composition, current ESP, and target infrastructure. Delivered as a written runbook with day-by-day actions, rollback criteria, and explicit success metrics for each phase. Updated weekly with actual measured progress versus plan.
Export from current ESP via API or native export tools depending on source. Deduplication against existing lists, custom field preservation, segment membership preservation, normalisation of email addresses and timestamps. Import into MailWizz with field mappings verified by sampling and visual review.
Unsubscribes, hard bounces, and complainants extracted from old ESP. Imported as suppression entries in MailWizz before any sending begins. Unsubscribe timestamps preserved for compliance documentation. Verification that suppression mechanism prevents sending to those addresses.
Both old and new ESPs active in SPF record during overlap weeks (watching the 10-lookup limit; if tight, we use subdomain routing). DKIM records for both ESPs configured simultaneously. DMARC policy review to ensure overlap traffic passes. Old ESP records retired only after week 6 cutover.
PowerMTA virtual-mta configuration ramping each sending IP from 200 messages per day in week 1 to 50,000 messages per day by week 4. Per-domain throttling tuned for Gmail, Yahoo, Microsoft, Apple, and major regional providers. Daily review with adjustment if bounce or complaint rates exceed thresholds.
Merge tag syntax conversion (Mailchimp asterisk-pipe, Klaviyo Jinja2, HubSpot personalization tokens, etc) to MailWizz syntax. Visual rendering preserved. Cross-client rendering tests on Gmail web, Outlook desktop, Apple Mail, Yahoo Mail, mobile Gmail, mobile Apple Mail. Conversion report flagging any visual deviation.
Welcome series, drip sequences, abandoned cart flows, segment-based triggers, re-engagement campaigns rebuilt in MailWizz preserving the semantic logic. Custom workflows depending on ESP-specific deep integrations (Klaviyo Shopify, HubSpot CRM) reviewed case-by-case for direct translation or redesign.
Days 1-42 of the engagement: daily report covering volume sent through new infrastructure, volume still on old ESP, bounce rates per ISP, complaint rates per ISP, opens and clicks per segment, IP reputation evolution, and any anomaly flags. PDF delivered daily plus running spreadsheet with trend data.
Migration mechanics are identical regardless of source ESP; the operational details vary. We have tested extraction pipelines for the 12 platforms below. Other ESPs can be supported with 1-2 additional days of discovery; we will quote that separately if needed.
| Source ESP | Extraction method | Custom field support | Automation complexity |
|---|---|---|---|
| Mailchimp | Native export + Marketing API | Full | Standard (Customer Journeys translate cleanly) |
| Klaviyo | Klaviyo API (segments + flows) | Full | High (deep Shopify integration may need redesign) |
| HubSpot | HubSpot API + Contacts export | Full (CRM-shaped, needs restructuring) | High (CRM triggers map to MailWizz segments differently) |
| ActiveCampaign | ActiveCampaign API (lists + automations) | Full | Standard (most automations translate) |
| ConvertKit | ConvertKit API (subscribers + tags + sequences) | Full | Low (tag-based model maps cleanly to MailWizz segments) |
| Brevo (Sendinblue) | Brevo API (contacts + automations) | Full | Standard |
| MailerLite | MailerLite API + CSV export | Full | Low to standard |
| SendGrid Marketing | SendGrid Marketing API | Full | Low (most SendGrid users are transactional, marketing is simpler) |
| Constant Contact | Constant Contact API + native export | Full | Standard |
| Omnisend | Omnisend API (contacts + automations) | Full | Standard to high (ecommerce automations may need rebuild) |
| Drip | Drip API (subscribers + workflows) | Full | High (Drip workflow model is unique, requires careful mapping) |
| AWeber | AWeber API + native export | Full | Low to standard |
Source ESPs not listed: Marketo, Pardot, Eloqua, Salesforce Marketing Cloud, Adobe Campaign, Iterable, Customer.io, and other enterprise-focused platforms can be migrated. The discovery phase runs longer because automation logic is typically more complex on these platforms; we will quote the additional discovery hours separately from the EUR 1,999 standard pack price.
Operations sending 5M+ messages per month or holding 250K+ contacts on managed ESPs hit cost curves that grow faster than business value. Self-hosted infrastructure breaks even quickly at this volume; payback period is typically under 12 months including the migration engagement fee.
Operations sending on behalf of multiple brands, running whitelabel ESP for clients, or managing multiple sending domains within one organisation. Managed ESPs charge per brand or per domain; self-hosted scales horizontally with infrastructure cost not per-brand markup.
Operations needing infrastructure in specific jurisdictions for compliance or strategic reasons (EU GDPR, EU candidate cost optimisation, non-EU non-US digital sovereignty). Managed ESPs operate from fixed cloud regions; self-hosted lets you choose the datacenter that fits your posture.
Operations watching deliverability degrade through no fault of their own because another sender on the same shared IP pool is causing reputation damage. Dedicated infrastructure isolates your reputation from other senders entirely. Common scenario for customers leaving Mailchimp shared pools.
Operations whose segmentation logic exceeds the built-in capabilities of managed ESPs: deep CRM integration, real-time data feeds, custom event triggers, complex multi-condition segments. Self-hosted MailWizz extended with custom code handles arbitrary logic.
Operations building products on top of email infrastructure (SaaS platforms with email features, ESPs reselling to their own customers, marketing agencies needing operational control). Managed ESP roadmap does not match your roadmap; self-hosted puts the roadmap in your hands.
Eight components delivered across a 6-week phased migration. First: phased migration plan tailored to your list size, segment composition, and current ESP. Second: subscriber list export from your current ESP (we have working extraction patterns for Mailchimp, Klaviyo, ActiveCampaign, HubSpot, ConvertKit, Constant Contact, Brevo, MailerLite, Sendinblue, Drip, Omnisend, AWeber), deduplication against existing lists, import into MailWizz with custom fields preserved. Third: suppression list migration capturing unsubscribes, hard bounces, and complaint records (forgetting this is the most common migration disaster). Fourth: dual-ESP DNS configuration during overlap weeks with both ESPs active in SPF and DKIM. Fifth: IP warmup schedule ramping from 200 messages per day to 50,000 messages per day per IP across 30 days. Sixth: template HTML conversion and rendering tests across mainstream mail clients. Seventh: automation rebuild covering welcome series, drip sequences, segment-based triggers, abandoned cart, and re-engagement flows. Eighth: daily delivery report during migration weeks 1-6 with bounce, complaint, and open rate tracking. One-time engagement EUR 1,999.
Three mechanisms. First, IP reputation does not transfer. Your domain reputation on Gmail Postmaster Tools is tied to your sending domain and follows the domain. Your IP reputation is tied to the IP address and stays with the previous ESP. When you switch to a new ESP (or self-hosted infrastructure) you start with zero IP reputation. ISPs see unfamiliar IPs sending to your established recipients and filter aggressively until those IPs have history. Second, sending pattern differs. Managed ESPs send from large shared pools with established traffic shapes; self-hosted PowerMTA sends from dedicated IPs with specific per-domain throttling. The shape of your sending changes and ISPs notice. Third, the operational temptation is to migrate everything on day one and send a campaign. The Mailflow Authority playbook describes this pattern: company signs Monday, migrates Tuesday, sends Wednesday, deliverability crashes Thursday. Our migration pack is designed specifically to avoid this through phased rollout, dual-ESP overlap, engaged-segment-first sending, and structured IP warmup.
Six weeks of active engagement is the standard. Week 1 is preparation: list export, deduplication, suppression list capture, DNS configuration (both ESPs in SPF and DKIM), template HTML conversion, automation mapping. Week 2 starts sending: most-engaged segment (opened in the last 30 days, typically 15-25% of total list) migrates to the new infrastructure at low daily volume. Week 3 expands volume on the engaged segment and adds the next engagement tier (opened 30-90 days ago). Week 4 covers the bulk of moderately engaged recipients. Week 5 brings the long tail (opened 90-180 days ago, often weighted toward re-engagement campaigns). Week 6 completes the cutover, retires the old ESP, and confirms the new infrastructure operates standalone. Lists above 500,000 subscribers may extend to 8 weeks. Lists with significant unengaged tail (haven't opened in 180+ days) require pre-migration list hygiene that adds 1-2 weeks but reduces deliverability risk substantially.
Migrating suppression lists is the single most often forgotten element of ESP migration. Your old ESP holds three categories of suppressed recipients: explicit unsubscribes (people who clicked the unsubscribe link), hard bounces (recipients that returned permanent delivery failures), and complainants (people who marked your mail as spam). Sending to any of these on the new ESP destroys deliverability immediately and may violate GDPR or CAN-SPAM depending on jurisdiction. Our migration pack extracts all three categories from the old ESP, imports them as suppression entries in the new MailWizz instance before any sending begins, and verifies the suppression mechanism prevents sending to those addresses. We also extract and preserve unsubscribe timestamps where the old ESP provides them, supporting the documentation trail for compliance reviews.
Operationally yes, strategically no. The 6-week phased migration is structurally identical regardless of source ESP because the deliverability mechanics (IP warmup, dual-ESP overlap, segment-first sending) do not depend on the previous ESP. The operational details vary: Mailchimp exports natively support custom field preservation, Klaviyo requires the API for full segment information, HubSpot exports are CRM-shaped rather than email-list-shaped and need restructuring, ConvertKit tags map to MailWizz segments differently than Mailchimp groups. We have working extraction patterns for all major ESPs and adjust the operational details accordingly. The deliverability strategy is the constant; the ETL pipeline is the variable.
Templates need HTML conversion because each ESP has its own merge tag syntax, custom field syntax, and HTML preprocessing rules. Mailchimp uses asterisk-pipe syntax for first name, MailWizz uses bracket syntax, Klaviyo uses Jinja2 templating, and so on. Our template conversion converts the syntax, preserves the visual rendering, tests across mainstream mail clients (Gmail web, Outlook desktop, Apple Mail, Yahoo Mail, mobile Gmail, mobile Apple), and produces a rendering report. Automations require rebuilding because the trigger and action model differs between platforms. We rebuild welcome series, drip sequences, abandoned cart flows, re-engagement campaigns, and segment-based triggers in MailWizz preserving the semantic logic. Custom workflows that depend on ESP-specific integrations (Klaviyo Shopify deep integration, HubSpot CRM triggers) require case-by-case discussion; some workflows do not directly translate and need redesign for the self-hosted environment.
Migration alone will not fix reputation problems. If your domain is already on RBLs, your engagement rates are below 10%, or your bounce rates are above 5%, the new infrastructure will inherit your domain reputation and the underlying problems will reappear. For these scenarios we recommend the Reputation Recovery pack as a precursor to migration. Reputation Recovery focuses on identifying root causes (list quality issues, content problems, authentication misconfiguration, content-based filtering), running a structured rehabilitation program, and getting domain reputation into healthy territory before any migration. After recovery completes, migration follows the standard 6-week phased pattern with high probability of clean transition. Customers occasionally request migration of damaged operations directly; we are honest that the migration outcome will reflect the input reputation. Fix the inputs first.
Four common drivers. First, cost at volume. Managed ESPs price per contact or per send; self-hosted PowerMTA plus MailWizz on dedicated infrastructure has a fixed cost structure that becomes dramatically cheaper above approximately 250,000 contacts or 5 million sends per month. Second, operational control. Managed ESPs share IP pools across their customer base; one bad-actor customer can damage shared IP reputation and affect all senders on that pool. Self-hosted infrastructure puts you on dedicated IPs with no shared reputation surface. Third, jurisdictional positioning. Managed ESPs operate from specific cloud regions with specific subprocessor obligations. Self-hosted lets you choose the datacenter jurisdiction (EU, EU candidate, non-EU non-US) that fits your compliance posture. Fourth, feature ownership. Custom segmentation logic, custom merge tag systems, integration with internal data pipelines, multi-brand or whitelabel sending all become straightforward on self-hosted infrastructure that you control. Customers migrating do so for specific reasons; we discuss the trade-offs honestly during onboarding so the migration target matches the customer requirement.
Telegram conversation establishes current ESP, list size, engagement profile, automation complexity, and target infrastructure region. Migration plan delivered within 5 business days of order confirmation. Active engagement spans 6 weeks starting week 1 with preparation, weeks 2-5 with phased rollout, week 6 with cutover. Daily reports throughout. One-time EUR 1,999.
# Median Telegram response: 12 minutes during operating hours