How to Migrate Cold Email Infrastructure

Migrating cold email infrastructure is not like migrating a CRM. If a CRM migration goes badly you lose a weekend. If an infrastructure migration goes badly you lose sender reputation — and reputation is the one asset in your outbound stack that takes weeks to rebuild and cannot be bought back.

That risk is why so many teams stay on a provider they have outgrown. But the risk is manageable, and it is almost entirely a function of sequencing. Migrations that fail tend to fail for the same reasons every time: everything moved at once, volume resumed immediately, DNS changed without verification, and the old setup was torn down before the new one had proven itself.

This guide covers the whole decision and the whole operation: when migrating is genuinely worth it, exactly what carries over versus what has to be rebuilt from scratch, what happens to your DNS and your warmup, a phased cutover plan that avoids a deliverability cliff, a rollback plan for when a cohort goes wrong, and a realistic timeline you can put in front of a stakeholder.

When Migrating Is Actually Worth It

Migration has a real cost: setup effort, a period of reduced volume, and a window of elevated risk. It is worth paying when the problem you are solving is structural rather than cosmetic. These are the triggers that justify it:

• You have hit a capacity or architecture ceiling. Your provider cannot support the mailbox count, domain count or workspace separation you now need, and the workaround is more expensive than moving.
• Manual work scales with your fleet. If adding mailboxes means proportionally more human hours on DNS, provisioning and health checks, you are paying an ops tax that automation would remove.
• You lack visibility you need. No per-domain health monitoring, no placement history, no early warning before reply rates collapse — you are flying blind at a scale where blind is expensive.
• Unit economics have stopped improving. Your per-mailbox cost is flat or rising as you grow. See our breakdown of cold email cost per mailbox at scale for how to test this properly before assuming a competitor is cheaper.
• Consolidation. You are paying three vendors for domains, mailboxes and monitoring and the seams between them are where problems hide.

Equally, some reasons are not good enough on their own. A single bad deliverability week is not a migration trigger — run an infrastructure audit first, because the cause is far more often a DNS or list problem that travels with you than a platform problem that you can leave behind. Migrating away from a problem you have not diagnosed simply reproduces it on new infrastructure at additional cost. Likewise, a marginally lower headline price rarely survives contact with the switching cost and the ramp-down period. If you are still choosing between platforms rather than committed to moving, our platform selection framework is the better starting point.

What Carries Over and What Must Be Rebuilt

This is the single most important thing to get straight before you plan anything, because it determines whether your migration takes two weeks or two months. The rule underneath the table: reputation is attached to identity, and identity means the domain and the mailbox — not the platform that manages them.

The practical implication is a fork in the road. A migration that keeps your domains and mailboxes and changes only the management layer is fast and low-risk, because the assets that carry reputation never change. A migration that rebuilds domains or mailboxes is not really a migration at all — it is a fresh build running in parallel, with a full warmup cycle attached. Both are legitimate. They are just very different projects, and confusing them is how timelines slip by a month.

Domain and DNS Implications

DNS is where migrations break silently. Nothing errors, nothing alerts, and mail simply starts failing authentication on arrival while your dashboard reports successful sends. Work through this carefully.

Registrar transfer versus nameserver repoint

You do not always need to transfer registrations. Repointing nameservers to the new provider's DNS gives them record management without a registrar transfer, and it is reversible in minutes. A full registrar transfer consolidates billing and renewal but is slower and subject to transfer locks and the standard 60-day post-registration restriction. For a first migration, repoint rather than transfer — you can consolidate registrars later, once the migration has proven itself.

Lower your TTLs before you touch anything

Drop the TTL on the records you intend to change at least 24 to 48 hours before the change window. Long TTLs mean a mistake stays cached — and stays live — for hours after you have fixed it, which turns a five-minute error into a full day of failed authentication. Raise TTLs back to normal once the migration has stabilised.

SPF, DKIM, DMARC and MX

If the sending path changes, SPF must authorise the new path before any mail flows through it, and it must do so without breaking the ten-lookup limit — a common failure when a new include is added and the old one is not removed. DKIM needs the new selector published and verified; keep the old selector live during the overlap so mail signed either way validates. DMARC should stay exactly as it is during the migration — this is not the moment to tighten a policy — and the reporting address must remain monitored, because aggregate reports are your fastest signal that a cohort is failing alignment. MX records matter because replies are the point; if MX is wrong, your campaigns look like they are working while the responses vanish.

Verify every record after propagation and before increasing volume, on every domain, not a sample. Our complete SPF, DKIM and DMARC guide covers the correct record shapes and the failure modes to check for.

"A migration does not usually fail loudly. It fails as a DKIM selector nobody published and a reply rate nobody could explain three weeks later."

Does Warmup Reset When You Migrate?

The honest answer is: it depends on what you actually changed, and the distinction is worth being precise about because it is the difference between a two-week project and a six-week one.

Reputation is preserved when the same domain and the same mailbox continue sending along the same path, and only the management layer changes. Mailbox providers have no concept of which dashboard you provision from; they see a sending identity with a history, and that history is intact.

Reputation resets when you introduce new domains or newly created mailboxes. There is no shortcut here — a new identity starts at zero regardless of how established your other identities are, and it needs a full warmup cycle before it carries campaign volume.

Reputation is at risk — but not reset — in the middle case: same identity, different sending path or different sending behaviour. Here your history counts, but the change itself is a signal. Providers notice when an established sender's pattern shifts abruptly, and the mitigation is behavioural rather than technical: drop volume on cutover, ramp back deliberately, and keep everything else about the send constant while you do it. Our guide to email warmup best practices has the ramp schedules that apply equally to a post-migration ramp.

Whichever case you are in, keep warmup activity running continuously through the migration. Pausing warmup during a cutover window is a common and avoidable own goal: it removes positive engagement signal at exactly the moment providers are re-evaluating you.

The Phased Migration Plan

Every principle above reduces to one operational rule: never move more than you can diagnose. Cohorts give you attribution, and attribution is what turns a scary migration into a routine one.

Phase 1: Audit and baseline

Inventory every domain, mailbox, DNS record, integration and suppression list. Then capture a baseline: current inbox placement per domain, bounce rate, complaint rate, reply rate and authentication pass rates. Without a baseline you cannot tell whether post-migration numbers are a problem or just Tuesday. Export the suppression lists now, not later. Run inbox placement tests across every domain so the comparison after cutover is like for like.

Phase 2: Parallel setup

Build the new environment fully while the old one keeps running. Configure workspaces, connect the new platform, prepare DNS changes without applying them, rebuild sequences and integrations, and lower TTLs. Nothing has moved yet and nothing is at risk. Running both in parallel costs a month of overlapping subscription and is the cheapest insurance in the entire project.

Phase 3: Pilot cohort

Move a small, low-stakes cohort first — a handful of mailboxes on one or two domains, ideally not your best performers. Apply DNS changes, verify authentication on every mailbox, and send at sharply reduced volume for several days. Compare placement, bounces and complaints against the baseline. This cohort exists to find the problems you did not anticipate, at a scale where finding them is cheap.

Phase 4: Staged cutover

Move remaining mailboxes in cohorts, each one gated on the previous cohort holding steady for several days. Two rules make this work. Never move a cohort while the previous one is still ramping — overlapping ramps destroy attribution. And keep cohorts aligned to domains, so a domain is never half-migrated; split domains create two authentication paths for one identity and are a reliable source of confusing failures.

Phase 5: Ramp and decommission

Restore full volume gradually across all migrated cohorts, then hold. Only after the entire fleet has run at full volume with stable metrics for a week or two should you cancel the old subscription, release the old configuration and raise TTLs back to normal. Decommissioning is the last step, never a concurrent one.

Your Rollback Plan

A rollback plan is not pessimism, it is what makes the migration safe to attempt. Write it before Phase 3, not during Phase 4.

• Define the trigger in advance. Agree the thresholds that mean stop — for example a placement drop beyond an agreed tolerance versus baseline, authentication failures on a migrated cohort, a bounce or complaint rate breach, or a new blacklist appearance. Deciding this while metrics are falling produces bad decisions.
• Keep the old environment intact until the end. Do not cancel, do not delete configuration, do not release domains. The overlap subscription is the price of the rollback option.
• Snapshot DNS before every change. Save the full record set per domain so you can restore exactly rather than reconstructing from memory. Low TTLs make the restore fast.
• Roll back one cohort, not the project. Because you migrated in cohorts, you can revert only the affected cohort while the rest continue. This is the entire payoff of the phased approach.
• Pause volume first, then investigate. On any trigger, cut sending on the affected cohort immediately. Reputation damage compounds with every additional send into a filter.
• Diagnose before you re-attempt. A rollback with no root cause is a rollback you will repeat. Most causes are DNS or ramp-related and are fixable within a day.

A Realistic Timeline

For a migration that keeps existing domains and mailboxes, four to six weeks is a realistic plan for a fleet of meaningful size. Adjust the cohort phase up or down with mailbox count; the audit and stabilisation phases stay roughly constant.

If the migration requires new domains or newly created mailboxes, add two to four weeks of warmup before those identities carry campaign volume — and run that warmup in parallel with the earlier phases rather than appending it to the end.

Mistakes That Cause a Deliverability Cliff

• Big-bang cutover. Everything moves in one night, something degrades, and there is no way to tell which change caused it.
• Resuming full volume immediately. The most common cause of a post-migration drop even when nothing technical is wrong.
• Changing DNS and content in the same window. Two variables, one outcome, zero attribution. Freeze copy, targeting and volume during the migration.
• Tightening DMARC mid-migration. Moving to a stricter policy while authentication paths are in flux turns a misconfiguration into rejected mail.
• Half-migrated domains. Mailboxes on the same domain sending through two different paths is a reliable way to produce alignment failures.
• Decommissioning early. Cancelling the old stack the day after cutover saves one month of subscription and costs you the rollback.
• No baseline. Without pre-migration numbers, every post-migration metric is unfalsifiable — you will argue about whether there is a problem instead of fixing one.
• Forgetting suppression lists. Contacting people who previously opted out generates complaints, which is the fastest possible way to damage a reputation you just spent weeks protecting.

Migrating to InboxOne

If InboxOne is the destination, the migration falls into the low-risk category described above: you keep your domains and your mailboxes, and what changes is the layer that provisions, configures and monitors them.

Connect existing domains rather than rebuilding them. Bring your registered domains in and let DNS be configured and verified automatically, so SPF, DKIM, DMARC and MX are correct from the first send rather than hand-copied under time pressure — which is where most migration errors originate.

Baseline and monitor from day one. InboxOne Protect provides continuous DNS and blacklist monitoring per domain, which is precisely the instrumentation a migration needs: it turns the pilot cohort into a measured experiment instead of a hopeful one, and it catches record drift during the cutover window rather than weeks later.

Migrate in cohorts using workspaces. Separate workspaces let you run migrated and un-migrated cohorts side by side with clean attribution, which is what makes staged cutover and per-cohort rollback practical rather than theoretical.

Keep your outreach platform. Because InboxOne exports mailboxes to the major sending platforms, migrating your infrastructure layer does not force you to migrate your sequences at the same time — which removes an entire category of variable from the change window. That alone often shortens a migration by weeks.

Key Takeaways

• Migrate for structural reasons — capacity ceilings, ops burden, missing visibility, broken unit economics — not for one bad week or a marginally lower price.
• Reputation follows identity, not platform. Keep the same domains and mailboxes and your reputation travels with you.
• Campaigns, health history, integrations and suppression lists do not carry over. Export what you can before you leave.
• DNS is the silent failure mode. Lower TTLs first, keep DMARC unchanged, verify every record on every domain after propagation.
• Warmup only resets for new identities — but any abrupt change in sending behaviour is still a risk signal, so ramp deliberately.
• Migrate in cohorts, one at a time, gated on the previous cohort holding steady. Never move more than you can diagnose.
• Write the rollback plan and its triggers before the first cutover, and keep the old environment alive until the new one has held at full volume.
• Budget four to six weeks for a same-identity migration; add two to four more if new domains or mailboxes are involved.

Frequently Asked Questions