ESP Migration Guide: Switching ESPs Without Losing Reputation

Migrating between email service providers is one of the highest-risk operational changes a commercial email programme can make. Done incorrectly, an ESP migration can cause weeks of degraded inbox placement — the reputation built over months of consistent sending does not automatically follow to the new provider. Done correctly, with proper DKIM domain continuity, a structured warmup plan, and careful parallel sending strategy, an ESP migration is completed with zero interruption to deliverability or commercial performance. This guide documents the migration process that preserves reputation through provider transitions.

The Reputation Risk of ESP Migration

ESP migration creates reputation risk from two sources: IP reputation loss and domain reputation loss. Understanding both is essential for planning a migration that avoids them.

IP reputation loss: Every ESP has its own IP pools. Moving to a new ESP means sending from new IPs that have no history with ISPs. Even if the new ESP's shared IPs have reasonable baseline reputation, they are not the same IPs whose reputation was built through months of consistent, high-quality sending from the previous ESP. For senders on dedicated IPs at the old ESP, the reputation loss is acute — the dedicated IPs cannot be transferred to the new ESP, and new dedicated IPs at the new provider start from zero reputation.

Domain reputation loss: If the previous ESP was signing with a shared ESP domain (d=oldespname.com) rather than the sender's own domain (d=brand.com), the domain reputation built during the previous ESP relationship belongs to the ESP's shared domain — not the sender's domain. Moving to a new provider means the sender's own domain starts with zero reputation history at Gmail Postmaster Tools, and the warmup must proceed from zero regardless of years of sending history on the old platform.

If the previous ESP was correctly signing with d=brand.com, the Gmail Postmaster Tools domain reputation for brand.com is portable — the reputation signals (engagement history, complaint history, reputation tier) are associated with the domain, not with the ESP's IP addresses. Moving to a new provider with d=brand.com signing means the new provider's IPs begin delivering with the benefit of the established domain reputation. This is why DKIM domain continuity is the most critical migration decision.

Pre-Migration Checklist

DKIM Domain Continuity: The Critical Step

DKIM domain continuity is the single most important decision in ESP migration planning. It determines whether months of Gmail domain reputation history carries forward to the new ESP or is lost at migration.

The continuity requirement: configure the new ESP to sign outbound email with d=brand.com — the same DKIM signing domain used on the old ESP. Both ESPs must use the sender's own domain for DKIM signing simultaneously during the parallel sending period. This requires publishing two DKIM public keys in DNS: one for the old ESP (selector "mail" at mail._domainkey.brand.com) and one for the new ESP (selector "mail2" at mail2._domainkey.brand.com). Both selectors are valid simultaneously — the old ESP signs with selector "mail," the new ESP signs with selector "mail2," and both produce dkim=pass with d=brand.com.

# During migration: two DKIM selectors active simultaneously
mail._domainkey.brand.com   TXT "v=DKIM1; k=rsa; p=OLD_ESP_PUBLIC_KEY"
mail2._domainkey.brand.com  TXT "v=DKIM1; k=rsa; p=NEW_ESP_PUBLIC_KEY"

# Both ESPs sign with their respective selectors, both produce:
# dkim=pass header.i=@brand.com
# Gmail Postmaster Tools tracks all sends under brand.com domain reputation

The scenario where DKIM domain continuity is not possible (the old ESP was signing with its shared domain and does not support custom DKIM, or the sender does not have the budget to upgrade to a tier that supports it): set up custom DKIM signing on the old ESP first, build domain reputation under brand.com for 60-90 days, then begin the new ESP migration. The extra 60-90 days is not wasted — it is the domain reputation building that makes the subsequent migration deliverability-neutral.

Parallel Sending Strategy

Parallel sending — maintaining both the old ESP and new ESP in active sending configuration simultaneously during the warmup period — is the structural choice that eliminates migration deliverability risk. The parallel strategy works as follows:

Weeks 1-4 (early warmup): New ESP sends to the top 10-15% highest-engagement contacts (warmup volume: 5-15% of total programme volume). Old ESP continues to send all remaining campaigns to 85-90% of the list at full volume. Deliverability continues uninterrupted on the old ESP while the new ESP warms up.

Weeks 5-7 (mid warmup): New ESP expands to 30-50% of total programme volume, sending to engaged contacts from the past 60 days. Old ESP handles remaining 50-70%. Monitor Postmaster Tools for the new ESP's performance at increasing volume.

Weeks 8-10 (late warmup): New ESP handles 70-90% of volume. Old ESP handles remaining 10-30%. If Postmaster Tools shows High domain reputation sustained for 14+ days at the new ESP, proceed to cutover.

The financial question of running two ESPs simultaneously: For the 8-10 week warmup period, the programme is paying for two ESPs. This dual cost is a migration insurance premium — it is significantly cheaper than the revenue lost to degraded inbox placement during an abrupt full-volume cutover. Calculate the cost of 8 weeks of dual ESP fees versus the potential revenue impact of 30-50% inbox placement degradation during a rushed migration to understand the economics clearly.

List Migration: Data, Suppressions, and Preferences

List migration from the old to the new ESP must be complete before any sending begins on the new platform. The migration includes the active subscriber list, the suppression list, subscriber preferences, and engagement history.

Suppression list first: The global suppression list (all hard bounces, all unsubscribes, all FBL complaints) from the old ESP must be loaded into the new ESP before importing the active subscriber list. This prevents the scenario where a contact who unsubscribed from the programme two years ago on the old ESP receives a welcome email from the new ESP because their address exists in the active list export but the suppression data was not migrated first.

Engagement history for warmup segmentation: Import engagement history (last open date, last click date) for all active subscribers. This data is used to segment the warmup audience — the highest-engagement contacts are sent first during warmup, not a random sample. If the old ESP does not export per-contact engagement history, rebuild it from campaign-level performance data: contacts who opened the most recent 3 campaigns are in the top-engagement tier.

List-unsubscribe and preference data: If the old ESP supports frequency preferences, topic preferences, or list membership data, export and import this data alongside the contact records. Subscribers who set frequency preferences on the old ESP expect those preferences to be honoured on any platform — not respecting preferences after migration generates complaint spikes from subscribers who feel their preferences were ignored.

Warming Up New Infrastructure

The warmup schedule for new ESP infrastructure follows the same principles as warming any new sending configuration — start with the highest-engagement audience, increase volume gradually as Postmaster Tools confirms domain reputation is building correctly. The ESP migration warmup has one advantage over a cold-start warmup: if DKIM domain continuity is maintained (d=brand.com on both ESPs), the Gmail Postmaster Tools domain reputation established on the old ESP provides a baseline that makes warmup faster than starting from zero.

Typical warmup acceleration with DKIM domain continuity: a cold-start warmup (no prior domain reputation) takes 8-10 weeks to reach High Gmail reputation at 50,000+ daily messages. A migration warmup with established brand.com reputation may reach High reputation at comparable volumes in 4-6 weeks — the domain reputation history provides a head start that cold-start IPs cannot access.

The warmup metrics to monitor daily during migration: Gmail Postmaster Tools spam rate for brand.com (should remain below 0.03% throughout the warmup), Gmail domain reputation tier (should start at the current tier and maintain or improve), per-ISP deferral rate on the new infrastructure (should stay below 10% at each major ISP), and hard bounce rate per warmup campaign (should stay below 0.4% given the high-engagement audience selection).

Cutover Timing and Go-Live Strategy

The cutover from old to new ESP should occur only after all warmup completion criteria are met (see email warmup strategy guide for the full completion checklist). Never schedule the cutover for a business-critical period — avoid Q4, end-of-quarter campaign deadlines, or major product launches that depend on email performance. The ideal cutover timing: a week with below-average planned campaign volume, during a period when the infrastructure team has capacity to monitor closely for 72 hours post-cutover.

The cutover sequence: (1) Complete final campaign on old ESP. (2) Export updated suppression list from old ESP and update new ESP suppression database. (3) Switch all campaign scheduling to new ESP. (4) Send first full-volume campaign from new ESP to the highest-engagement segment only (not the full list) — this provides a full-volume test before the complete list transition. (5) If the first full-volume campaign completes successfully with acceptable metrics, expand to full list on subsequent campaigns. (6) Maintain old ESP account in read-only/inactive status for 30 days post-cutover to allow access to historical campaign data and suppression history.

The old ESP account should not be immediately cancelled at cutover. Keep it active in read-only mode for 30 days post-migration. This provides: a historical campaign data archive, access to the old ESP's suppression list export if any suppressed contacts are missing from the new platform, and a fallback sending option if an unexpected critical problem emerges on the new ESP within the first 30 days.

Post-Migration Monitoring

Post-migration monitoring intensity should be elevated for 30 days following full cutover. Compare every key deliverability metric against the pre-migration baseline recorded in step 2 of the pre-migration checklist:

Any metric that shows sustained degradation relative to the pre-migration baseline requires investigation. A click rate decline that exactly coincides with the ESP migration may indicate inbox placement degradation not yet visible in Postmaster Tools spam rate — seed testing can confirm whether inbox placement has changed at specific ISPs. Act on post-migration metric degradation immediately; the first 30 days are the window when migration-related deliverability problems can be addressed with minimal cumulative damage to the domain reputation built before migration.

ESP migration executed with DKIM domain continuity, parallel sending, and the monitoring discipline documented above consistently produces migrations with zero detectable inbox placement degradation. The investment in the 8-10 week migration timeline and the dual ESP cost during warmup is repaid in the commercial continuity of a programme that never experiences the reputation recovery cycle that rushed migrations require. Plan the migration thoroughly; execute it patiently; and the new ESP infrastructure will be operational at full performance from cutover day.