Definition
Email service provider (ESP) migration is the process of transferring an organisation's email programme from one sending platform to another, encompassing subscriber data, segmentation logic, template code, automation workflows, and historical analytics. A migration is one of the most technically complex and risk-laden operations in email marketing, requiring meticulous planning across data, technology, deliverability, and operational dimensions. The migration timeline typically spans two to six months from initiation to full cutover, with the deliverability preservation phase alone requiring four to eight weeks of controlled IP warmup and reputation transfer. Poorly executed migrations have caused catastrophic deliverability failure, subscriber data loss, automation programme disruption, and revenue decline measured in millions of pounds.
The migration process divides into five major phases: pre-migration audit (comprehensive inventory of current ESP capabilities, data structures, template inventory, automation workflows, and integration points), data export and import (subscriber tables with all custom fields, segments and suppression lists, template HTML with dynamic content components, automation workflow definitions, and historical send and engagement data), template migration (rebuilding templates in the new platform's framework versus converting existing HTML, with each approach carrying distinct quality and timeline trade-offs), deliverability transfer (IP warmup, domain reputation management, authentication record updates, feedback loop registration, and mailbox provider relationship establishment), and cutover execution (DNS change sequencing, parallel send validation, subdomain migration strategy, rollback trigger conditions, and post-migration monitoring). Each phase requires documented sign-off before the next can proceed, with clear rollback criteria defined before any irreversible step is taken.
Best Practices
Conduct a thorough pre-migration audit at least eight weeks before the planned migration start date. Inventory every active template, automation workflow, segment definition, integration API call, and custom reporting configuration. Identify the data fields in use, their data types, validation rules, and whether they are populated through automation or manual entry. Document all technical debt and workarounds in the current platform that could be resolved during migration rather than carried forward.
Develop a detailed migration project plan with phase gates, responsibility assignments, and rollback criteria for each phase. The plan should include: parallel run period (typically two to four weeks where both ESPs operate simultaneously to validate data and process integrity), testing milestones (individual phase testing, integrated testing, user acceptance testing, load testing), DNS change sequencing with TTL minimums observed, and a business decision hierarchy specifying who has authority to abort the migration at each phase.
Choose a template migration strategy based on template complexity and volume. The rebuild approach — creating new templates in the target platform's native builder — is recommended when template volume is manageable and the target platform offers significantly different capabilities. The convert approach — adapting existing HTML to the new platform's framework — is faster but may carry forward bad practices and platform-specific code. A hybrid approach, where high-volume templates are converted and restructured, while low-volume or complex templates are rebuilt from scratch, often provides the best balance of speed and quality.
Execute a structured deliverability preservation plan starting four to eight weeks before cutover. Create a new sending IP or IP range, warm it gradually following a pre-planned volume escalation schedule, authenticate all sending domains with SPF, DKIM, and DMARC before any mail is sent, register with all major feedback loops, and send a low volume of engagement-qualified traffic to establish positive reputation before higher volume sending begins. Monitor mailbox placement rates daily during the warmup period and pause volume increases if negative trends emerge.
Implement DNS changes with staggered timing to minimise disruption risk. Update MX records for inbound email if applicable, then update SPF and DKIM records for the new ESP, then adjust DMARC policy if needed to accommodate the new sending infrastructure. Respect DNS TTL values — lower TTLs to five minutes at least 48 hours before planned changes, then raise them back after cutover is confirmed successful. Schedule changes during lowest send volume periods to limit affected subscriber reach in case of misconfiguration.
Related Glossary Terms
Bounce Classification
Bounce classification uses SMTP codes (550, 551, 552, 553, 554, 450, 451, 452) and enhanced status codes to categorise permanent and transient delivery failures.
DMARC Alignment
DMARC identifier alignment determines whether the domain in the From header matches the domains used in SPF and DKIM authentication. Strict or relaxed.
Email Active Subscriber
An active email subscriber has opened or clicked an email within a defined recency period, typically 30-90 days by industry. Active subscriber rate of 40-60% is typical for healthy email lists.
Email Authentication Failure
Email authentication failures occur when SPF, DKIM, or DMARC checks fail, causing messages to be rejected, spammed, or quarantined by receiving mailbox providers.
Email Blacklist
An email blacklist (DNSBL) is a real-time database of IP addresses or domains known for sending spam or unwanted email.
Email Bounce Handling Automation
Email bounce handling automation uses automated workflows to classify, score, and suppress bounced addresses, protecting sender reputation through progressive suppression rules and real-time monitoring.
Frequently Asked Questions
The audit should inventory: all subscriber tables and custom field definitions, all active segments and dynamic content rules, all email templates with their component variations, all automation workflows including trigger conditions, delay nodes, decision branches, and action steps, all API integrations and webhook configurations, all reporting dashboards and KPI definitions, all suppression lists and data retention policies, and current ESP platform contract terms and data extraction capabilities.
Evaluate the trade-off between rebuild and convert approaches. Rebuild all templates in the new platform if the template count is manageable (under 50 templates), if the current templates have significant technical debt, or if the new platform uses a fundamentally different template architecture. Convert existing HTML if you have a large template library (over 100 templates) with tight timelines. Use a hybrid approach for mid-sized programmes.
Begin IP warmup four to eight weeks before cutover on the new ESP infrastructure, following a gradual volume escalation schedule. Warm the sending domain and IP simultaneously by sending to your most engaged subscriber segments first. Authenticate all sending domains on the new infrastructure before any mail is sent. Register with all feedback loops. Monitor inbox placement rates daily and adjust warmup pace based on mailbox provider feedback.
Lower TTLs on all relevant DNS records 48 hours before changes. Sequence: update SPF record to include new ESP IP ranges, update DKIM record with new public key, verify SPF and DKIM authentication on test sends, add DMARC reporting addresses if not already configured, validate all records post-change, then raise TTLs to standard values after 72 hours of stable authenticated sending.
Define specific trigger conditions that would activate a rollback: sustained inbox placement rate drop below 95%, spam complaint rate exceeding 0.1% for two consecutive days, critical automation workflow failure, or subscriber data integrity issues. Each rollback trigger should have a clearly assigned decision-maker with authority to execute. The rollback plan must specify exactly which DNS record changes to reverse, in what order, and how to switch sending back to the original platform without data loss.