Email migration is the operation most likely to silently destroy a sender’s reputation if done wrong, and most likely to be done wrong because the visible parts (DNS update, app config change) are deceptively simple. The invisible parts — IP warming, authentication transition, bounce handling continuity, list hygiene preservation — are where migrations succeed or fail.
We have led 50+ migrations in the past two years across SendGrid, Mailgun, Postmark, Mandrill (final wave), AWS SES, and a few legacy on-prem MTAs to European destinations. The patterns below are observed reality, not theoretical advice. If you are planning a migration in 2026, this is the playbook.
What “losing reputation” actually means
Before the playbook, the failure modes. Reputation loss during migration shows up in three distinct ways.
Type 1: IP reputation loss. New IPs from the new provider have no reputation. If you cutover at full volume, receivers see a sudden burst from an unknown IP and treat it as suspicious. Inbox placement drops 20-40% in the first 7 days. Recovery is possible through warming but takes 4-8 weeks.
Type 2: Domain reputation loss. Receivers track reputation per (domain × IP) combination. When your domain starts sending from new IPs, the receiver reputation system needs to re-establish trust. This is faster than pure IP warming (the domain has history) but still takes 1-2 weeks of careful operation.
Type 3: Engagement signal loss. This is the one most people miss. The old provider had bounce categorization tuned to receive feedback that informed your suppression logic, retry policy, and complaint handling. The new provider has different categorization. If your suppression logic was tuned to old-provider categories, you may suddenly start sending to addresses you should have suppressed, complaint rate spikes, reputation tanks fast.
A good migration prevents all three. A bad migration prevents one and gets surprised by the others.
The fundamental decision: bridge or burn?
Two migration patterns work; everything else is risk.
Pattern A: Bridge migration (recommended for most senders)
Run old and new providers in parallel for 4-6 weeks. New provider takes 10% → 25% → 50% → 75% → 100% over the period. Old provider winds down inversely. At any point during the migration, you can roll back if signals go bad.
This is more expensive in the short term (you pay both providers) but the risk profile is dramatically better. We use this pattern for 90% of client migrations.
Pattern B: Burn migration (only for forced cutovers)
Hard cutover at a planned moment. New provider takes 100% on day 1, old provider stops. Used only when:
- The old provider is shutting down (Mandrill 2016 was the canonical case)
- Cost of parallel run is genuinely prohibitive
- The new provider has IP warming completed before cutover
- The team has accepted that 1-3 weeks of degraded placement is acceptable
This is faster but riskier. We do it occasionally; we always document the risk acceptance in writing first.
The 6-week bridge migration playbook
This is the schedule we use for a typical mid-market migration: SendGrid (US) to OS Domains (Austria), 1M monthly volume, single sending channel.
Week 0: assessment and preparation
Audit current state at old provider:
- Sending domains and DKIM selectors
- Dedicated IPs (if any) and warming history
- Suppression list (download via API, cleaned)
- Bounce/complaint reporting integration
- Webhook integrations and event consumers
Set up new provider:
- Account provisioning, sub-processor agreement signed
- New DKIM selector(s) configured with appropriate alignment
- New IP block warmed and ready (separate engagement; usually overlapping with weeks 1-4)
- Webhook endpoints tested
DNS preparation:
- Add new DKIM record without removing old
- Update SPF to include new provider’s IPs (alongside old)
- DMARC policy reviewed; relaxed alignment for both providers during transition
Week 1: parallel start at 10%
Application-side change: route 10% of outgoing traffic to new provider, 90% continues to old.
The 10% is selected by receiver, not by random sampling. Start with the receivers most tolerant of new senders (typically Microsoft 365 corporate domains, Yandex, ProtonMail). Gmail and Yahoo come in week 2 or 3.
Monitor:
- Bounce rate on new provider (target: similar to old)
- Complaint rate on new provider (target: similar to old)
- Inbox placement via seed testing
- Application-level errors (the integration may surface bugs not seen in testing)
If anything looks unusual, pause and investigate before increasing.
Week 2: 25%
Increase to 25%. By now Gmail and Yahoo are receiving meaningful volume from your new IPs. The receiver reputation systems have 7+ days of clean signals to work with.
Watch for divergence between old and new provider performance. If they show similar patterns, you are on track. If new provider lags significantly, dig into per-receiver placement to identify which is the laggard.
Week 3: 50%
Halfway point. New provider is now handling enough volume that receiver reputation systems have established (provisional) reputation for the new IPs. Old provider is carrying the other half.
This is the week where unexpected issues most often surface. The application is exercised against both providers in roughly equal measure, which means any bug in the new provider integration will appear if it hasn’t already. Suppression list mismatches are visible. Unique-id collision issues (if your application uses provider-specific message IDs anywhere) become apparent.
Week 4: 75%
Pull more volume to the new provider. Old provider is now in wind-down mode.
Important: do not rush. The receivers are watching for sudden volume changes, both up at the new provider and down at the old. A gradual transition is observed as “normal” sending pattern variation; a sudden change looks like compromise.
Week 5-6: 100% then stabilization
By end of week 5, route 100% of new outbound to the new provider. Old provider is completely passive (still configured for rollback, no new sending).
Week 6 is stabilization at full volume. Any remaining issues surface here. By end of week 6 you should be running cleanly at full capacity on the new provider with reputation that matches or exceeds the old setup.
Week 8-10: old provider decommission
Wait 30 days from end of cutover before turning off the old provider account. The buffer covers:
- Bounces from late-delivered messages (especially monthly transactional sequences)
- Customer service requests referencing old-provider message IDs
- Compliance investigation needs (rare but expensive if you can’t access old logs)
After 30 days, archive old provider data, terminate the account, enjoy the cost savings.
Per-source migration patterns
Different source providers have different gotchas.
| Source | Specific gotcha | Recommended approach |
|---|---|---|
| SendGrid | Suppression list categorization is non-standard; export via API not UI | Use bridge pattern, validate suppression import explicitly |
| Mailgun | EU and US accounts are separate; data does not transfer between them | Confirm which region you are migrating from; export via API per region |
| Postmark | Strong opinions about transactional vs marketing separation; preserve in new setup | Maintain stream separation in new provider config |
| AWS SES | Bounce categorization minimal; new provider may have richer categories that change suppression | Establish baseline at new provider before shifting volume |
| Mandrill (final users) | Account closure deadline forces burn migration in some cases | Pre-warm new provider IPs as long as possible before deadline |
| On-prem Postfix | No published suppression list; you have been suppressing in application | Audit application suppression rules; map to provider equivalent |
Each source has additional quirks beyond these. Pre-migration audit time pays itself back during cutover.
What kills migrations
Across our 50+ migrations, the failure causes are mostly avoidable:
Cause 1: skipping IP warming for the new provider Most common. Team thinks “we’ll start sending and it’ll warm naturally.” Receivers see a new IP at full volume on day 1, throttle aggressively, placement drops. Recovery takes 4-8 weeks.
Cause 2: SPF lookup limit Adding the new provider’s SPF includes pushes total lookups over 10. SPF starts failing silently, DMARC alignment breaks, reputation drops. Mitigation: SPF flattening or migration to DKIM-only authentication during the transition.
Cause 3: webhook integration race conditions The application is now receiving bounce/complaint webhooks from two providers. If the suppression logic has any race conditions or doesn’t deduplicate correctly, you may end up sending to a suppressed address (because the new provider didn’t get the suppression yet) and complaint rate spikes.
Cause 4: DNS TTL mismatch DNS records updated for the migration but TTLs are 24h+. Some receivers cache the old DNS, some see new. Inconsistent authentication during the transition. Mitigation: lower TTLs to 300 a week before migration.
Cause 5: not validating actual placement Team monitors bounce rate (looks fine) and complaint rate (looks fine) and assumes things are working. Actual inbox placement has degraded but they don’t see it because they don’t have seed testing in place. By week 3 the campaign engagement metrics tank and they realize too late.
When you need professional migration help
Self-managed migration works if:
- You have one sending channel
- Volume is below 500K monthly
- Team has prior migration experience
- You have flexibility on timeline if issues surface
Outsourced migration makes sense if:
- Multi-channel (transactional + marketing + cold email separately)
- Volume above 500K monthly
- Hard cutover deadline (compliance, contract end, vendor shutdown)
- Cost of failure is high relative to migration service cost
Our migration service handles the operational execution: pre-migration audit, parallel-run setup, week-by-week metric review, contractual placement guarantee. For mid-market and enterprise clients with hard timelines, the predictability is worth the cost.
The DMARC trap that bites migrations in 2026
Since the enforcement escalation of late 2025, a new sending source that is not aligned under your DMARC policy no longer soft-fails into spam — Gmail, Yahoo, and Microsoft reject it outright. That reshapes the migration risk profile. The classic 2026 failure runs like this: the team cuts over to the new provider, points the application at it, and forgets that the new provider’s DKIM signature and return-path were never brought into alignment with the DMARC policy your domain publishes. Mail that sailed through on the old provider now bounces, and because the send API still reports acceptance from the new provider, nobody notices until reply volume drops or a customer calls to ask where their receipt went.
The bridge pattern catches this by design. At the 10% parallel stage you are reading authentication results per provider, and a DKIM alignment failure on the new source surfaces before it touches the bulk of your volume. Before any production traffic moves, the new provider’s signing domain and return-path belong in your published records and validated against the DMARC aggregate reports, not assumed to work because the dashboard shows a green checkmark.
Frequently asked questions
How long does an email migration take?
Plan four to six weeks for a clean bridge migration at production volume. The dedicated-IP warming is the pacing constraint, not the configuration, because you cannot push new IPs to full volume on day one without the receivers throttling them. A single-channel sender below a few hundred thousand messages a month can sometimes compress it to three weeks, but the receivers set the floor, not your deadline.
Can I skip the parallel run and switch in one move?
You can, and it is the most common cause of a failed migration. A hard cutover sends full volume from unwarmed IPs into receivers that ramp trust over days, which produces deferrals and spam placement during the exact window you can least afford it. The parallel run is cheap insurance against a quarter of lost placement.
Can I move my dedicated IP reputation to the new provider?
No. Reputation is tied to the IP, and a new provider means new IPs that have to be warmed from zero. What carries over is the domain reputation, which is why keeping the sending domain stable across the migration matters more than anything about the IP addresses underneath it.
Should I migrate all sending channels at once?
No. Move one channel at a time — typically a lower-risk stream first to validate the bridge, then transactional, then marketing — so a problem on one channel never threatens the others in the middle of a cutover. Migrating everything in a single window multiplies the blast radius for no benefit.
Bottom line
Email migration is a discipline, not a task. The technical pieces are well-documented. The discipline to follow the bridge pattern, monitor at the receiver level, and resist pressure to cutover faster than the receivers will accept — that is the differentiator between successful migrations and the ones that cost the company three months of placement.
If you are migrating in 2026, plan 4-6 weeks for clean execution. The “we’ll just switch the DNS” approach has not worked for years and works less now than it did before the bulk sender mandate. Plan the bridge, do the warming, validate at the receiver level, and treat the parallel-run cost as cheap insurance.