How to Migrate ESPs Without Torching Your Sender Reputation

Sender reputation does not transfer when you change ESPs. That's the part nobody tells you before they cut over a 50,000-contact list to a new platform on a Monday and watch their inbox placement collapse by Wednesday. Reputation lives at the intersection of your sending IPs, your domains, and the behavioral history mailbox providers have built up over months. Change the platform abruptly and you've handed Gmail and Outlook a brand-new sending pattern from infrastructure they've never seen at that volume — which reads, to a spam filter, exactly like a compromised account or a spammer who just bought a list.

The good news: a migration done with a plan is almost invisible to recipients and to the filters. The bad news is that almost nobody does it with a plan. They treat ESP migration like swapping a SaaS subscription instead of what it actually is — a reputation event. Below is the sequence we use when moving Growtoro clients between platforms, whether that's a cold outbound stack or a newsletter on its way to a new sender.

What Actually Carries Reputation (and What Doesn't)

Before you move anything, get clear on which assets carry your standing with mailbox providers:

• Your sending domain and its subdomains. This is the single most portable reputation asset. If you keep the same from-domain, you keep most of your domain reputation — provided your authentication moves with it.
• Your dedicated IPs. On shared-IP platforms, your IP reputation is partly inherited from every other sender on that pool. Move to a new shared pool and you inherit a new (unknown) reputation. Move to a fresh dedicated IP and you start from neutral, which means a warm-up.
• Engagement history. The opens, replies, and lack of complaints associated with your domain. This is sticky to the domain, not the platform.

The thing that does not carry: the implicit trust a provider extended to your old IP range. That's why the dangerous move is changing IPs and volume at the same time. Keep one variable fixed and you give the filters a thread to follow.

The 30-Day Migration Timeline

Treat the cutover as a phased ramp, not a switch. Here's the structure that works.

Days 1–7: Stand up parallel infrastructure

Provision the new ESP, configure authentication, and do nothing else with it yet. SPF, DKIM, and DMARC all need to be valid on the new platform before a single production email goes out — a misaligned DKIM signature on day one is the fastest way to get filtered. If you're unsure your records are correct, this is the moment to re-verify them against the SPF, DKIM, and DMARC setup guide rather than assume the new platform handled it for you. Keep your old ESP running at full volume during this week.

Days 8–21: Warm the new path with your most engaged segment

Begin routing a small slice of volume — 5% to 15% — through the new ESP, and choose that slice deliberately. Send your most engaged contacts first: recent openers, recent repliers, people who will not complain. Mailbox providers judge a new sending path by the engagement of its earliest traffic, so feeding it your best audience builds positive signal fast. This is the same logic behind any domain or IP warm-up: prove good behavior at low volume before asking for trust at high volume.

Critically, your list has to be clean before any of it touches the new platform. A migration is the worst possible time to discover dead addresses, because bounces on a fresh sending path are weighted heavily. Run the full list through verification first — the process in the email verification and bounce-rate cleanup guide will catch the spam traps and stale addresses that would otherwise spike your bounce rate during the most sensitive week of the move.

Days 22–30: Ramp volume and shift the balance

If placement holds, increase the new ESP's share by roughly 10–15 percentage points every two to three days: 25%, then 40%, then 60%, then 100%. Watch your metrics at each step. If anything degrades, hold the ratio — don't push further until it recovers. By the end of the window you've moved your entire volume across without ever presenting the filters with a sudden spike.

The Metrics That Tell You to Slow Down

You cannot run a migration blind. During the ramp, three numbers matter more than anything in the new platform's dashboard:

• Inbox placement, measured independently. Your ESP will tell you mail was "delivered." Delivered to spam is still delivered. You need real placement data, which means a seed panel. The methodology in the seed testing guide is what keeps the new path honest — run a seed test at every volume step and compare placement against your old ESP's baseline.
• Bounce rate. Anything above 2% on the new path means list quality, not platform, and you stop and re-verify.
• Complaint rate. Above 0.1% and you've sent to the wrong segment too early. Pull back to your most-engaged contacts.

Set a hard rule before you start: if placement on the new ESP drops more than a few points below the old baseline at any volume step, you freeze the ratio and diagnose before proceeding. The migrations that go wrong are almost always the ones where someone kept ramping through a warning sign because the calendar said it was week three.

The Mistakes That Actually Torch Reputation

Five patterns cause the overwhelming majority of failed migrations:

1. Big-bang cutover. Moving 100% of volume on day one. The single most common and most damaging mistake.
2. Changing the from-domain during the move. Now you've reset both platform and domain reputation simultaneously. Keep the domain fixed; migrate one variable at a time.
3. Skipping warm-up on new dedicated IPs. A fresh IP at full volume looks like a spam cannon. Even a strong domain reputation won't fully rescue an unwarmed IP sending 50K a day out of the gate.
4. Migrating a dirty list. Carrying bounces and traps onto a sensitive new path.
5. Trusting the ESP's "delivered" number. It's not placement. Measure independently.

There's also a subtler one: not aligning your DMARC policy with the new sending source. If you're at p=reject and the new ESP isn't included in your SPF or signing with an aligned DKIM key, your own mail will fail DMARC and get rejected by your own policy. Re-check alignment before you ramp, not after the first failure report.

Should You Even Migrate?

Worth asking honestly. Migration is justified when the new platform gives you materially better deliverability controls, dedicated IPs you actually need, or automation your current stack can't do. It is not justified to save $40 a month, because a botched migration can cost you weeks of suppressed placement — worth far more than the savings. If the goal is simply better outbound results rather than a different invoice, the lever is usually targeting, infrastructure, and sequencing, not the logo on your ESP login. That's the whole premise behind how we structure a campaign build: the platform is the least interesting variable in the system.

The Bottom Line

An ESP migration is a reputation event, not a subscription change. Keep your domain fixed, warm the new path with your best contacts, verify the list before it moves, ramp volume in steps over 30 days, and measure real inbox placement at every step instead of trusting the platform's delivered count. Do that and your recipients will never notice the move. Skip it and you'll spend the next two months rebuilding the reputation you spent a year earning.