Migrations Are Where Deliverability Goes to Die
Switching cold email infrastructure is high-risk. Every migration touches DNS, authentication, mailbox configuration, and sending patterns — all of which affect deliverability. Done wrong, you come out the other side with a week of degraded inbox placement and hundreds of lost replies.
This checklist is the structured process to migrate without those problems. It covers the pre-migration audit, the parallel-run strategy, the cutover, and the post-migration monitoring.
Use this for any migration: Google Workspace to ColdRelay, Microsoft 365 to Mailforge, one sequencer to another, or consolidating multiple vendors into one. The principles are the same.
Phase 1: Pre-Migration Audit
Document current state. Before changing anything, inventory what you have:
- Every sending domain and its current authentication records (SPF, DKIM, DMARC).
- Every mailbox, its sending pattern, its recipient lists.
- Every sequencer and tool in the stack.
- Current deliverability metrics (bounce rate, complaint rate, inbox placement) as baseline.
Identify reputation assets. Which domains have strong reputation? Those are harder to replicate — preserve them. Which have weak reputation? Consider retiring them as part of migration.
Check current DMARC status. If you're at p=reject or p=quarantine, migration requires careful DNS coordination. Going back to p=none during migration defeats months of reputation building.
Inventory sending volume by mailbox. Mailboxes sending high volume need to maintain that pattern post-migration. Mailboxes at low volume can be retired.
Document the failure modes. What's currently broken? Migration is the chance to fix it — don't carry forward problems to the new infrastructure.
Phase 2: New Infrastructure Setup
Set up the new infrastructure in parallel. Don't touch existing infrastructure yet.
On ColdRelay (or similar purpose-built).
- Add each domain via the dashboard. DNS records are provided; you publish them as additional records (not replacements) alongside existing SPF/DKIM.
- Provision new mailboxes. Each mailbox is new — no carry-over of existing reputation.
- Connect to your sequencer of choice via SMTP credentials.
On Google Workspace → ColdRelay specifically.
- ColdRelay domains can run parallel to Google Workspace on the same root domain. SPF can include both: v=spf1 include:_spf.google.com include:_spf.coldrelay.com ~all.
- DKIM uses different selectors (Google uses google._domainkey, ColdRelay uses its own selector) — both can coexist.
- DMARC policy remains unchanged during parallel run.
Verify authentication before sending. Send test emails from new infrastructure to yourself. Check headers for SPF=pass, DKIM=pass, DMARC=pass. Fix any failures before routing real traffic.
Phase 3: Warmup on New Infrastructure
Every new mailbox needs warmup. Even if the domain is already warm from old infrastructure, the new mailbox on new infrastructure is starting from zero.
Compressed warmup for migrated domains. If the domain has established reputation:
- Week 1: 10 sends/day per mailbox, 100% warmup.
- Week 2: 20 sends/day per mailbox, 70% warmup, 30% real.
- Week 3: 30 sends/day per mailbox, 50% warmup, 50% real.
Full 4-week warmup for new domains. Follow the standard warmup schedule.
Monitor during warmup. Google Postmaster Tools will show the domain's reputation across old and new infrastructure combined. Watch for unexpected drops.
Don't cut over existing traffic yet. Warmup is for the new mailboxes only. Existing mailboxes continue sending real traffic on old infrastructure during this phase.
Phase 4: Gradual Cutover
Start with 10% of campaigns. Move one campaign or one sequence to the new infrastructure. Monitor metrics for 1 week.
Compare metrics between old and new. Reply rates, bounce rates, complaint rates. If the new infrastructure is outperforming old by 10%+, proceed. If it's underperforming, pause and diagnose.
Ramp cutover weekly. Week 1: 10%. Week 2: 25%. Week 3: 50%. Week 4: 75%. Week 5: 100%.
Handle reply routing carefully. Replies from ongoing sequences need to route to mailboxes where the sequence is being tracked. If you cut over mid-sequence, replies can get lost. Finish sequences on the old infrastructure before migrating mailbox activities.
Update the sequencer. Whatever sequencer you use (Instantly, Smartlead, Lemlist) needs to route sends through the new SMTP credentials. Update connections as you cut over campaigns, not all at once.
Phase 5: Retire Old Infrastructure
After 4+ weeks of stable operation on new infrastructure.
Stop sending from old mailboxes. But don't delete them immediately — replies can still come in for 2–4 weeks after last send.
Update DMARC and SPF. Remove old-infrastructure includes from SPF. Remove old selectors from DKIM if they've been unused for 30+ days.
Cancel old-provider subscriptions. Only after you've verified no replies are still coming to old mailboxes, and you have reply history exported.
Retain domain ownership. Don't let domains lapse even after migrating sending. Domain reputation is tied to the domain, not the infrastructure — dropping domains loses that value.
Archive reply history. Export everything from old infrastructure before cancellation. Old replies have lead value (re-engagement campaigns) and operational value (audit trail).
Document the migration. Record what worked, what didn't, and timing. The next migration (there's always a next one) benefits from documented lessons.
Phase 6: Post-Migration Monitoring
Week 1–4 after full cutover.
Daily monitoring. Reply rates, bounce rates, complaint rates, reputation dashboards. Any drift from pre-migration baseline should be investigated.
Weekly seed tests. Mail-tester or Glock Apps to verify inbox placement remains 95%+.
Blacklist monitoring active. New infrastructure means new IPs — watch for listings carefully during the first month.
User reports. Sales team reports of lower reply rates or strange behavior should trigger immediate investigation. Migrations can have subtle issues (header rendering, unsubscribe link routing, tracking pixel failures).
Report back to stakeholders. Document what changed post-migration. Cost savings, deliverability improvements, operational simplifications. Makes the case for future infrastructure investments.
Running the Migration
Plan for 6–8 weeks end-to-end. Phase 1 (1 week audit), Phase 2 (1 week setup), Phase 3 (2–4 weeks warmup), Phase 4 (4–5 weeks cutover), Phase 5 (1 week retirement), Phase 6 (ongoing monitoring).
Don't migrate during peak season. Q4 campaigns, product launches, or high-stakes outreach are bad migration windows. Plan migrations during slower periods.
Assign a single owner. Migrations fail when responsibility is split. One person owns the migration plan, the schedule, and the rollback authority.
Have a rollback plan. If deliverability crashes during cutover, what's your 24-hour recovery path? Typically: route all traffic back to old infrastructure, debug root cause, then retry migration with fixes.
Communicate to the team. Sales team, marketing team, and any recipients of forwarded emails need to know about the migration timing. Confusion about email routing causes unnecessary support tickets and lost leads.
Consider professional help. For migrations over 500 mailboxes, consider hiring a deliverability consultant or using your new provider's migration services. The cost is usually 10% of what a botched migration costs in lost deliverability.
Frequently Asked Questions
How long should I run parallel infrastructure?
2–4 weeks minimum. One week of parallel is warmup; the remainder is gradual cutover with metrics monitoring. Faster migrations are possible for small setups (<50 mailboxes), but the risk of compressed cutover is losing the ability to diagnose issues before they affect deliverability.
Can I preserve domain reputation during migration?
Yes — as long as DNS remains stable and authentication continues passing. Reputation is attached to the domain, not the infrastructure. SPF and DMARC can include multiple senders during parallel run without degrading reputation.
What's the biggest migration mistake?
Hard cutover instead of gradual. Changing DNS to point only to new infrastructure at the start of migration means every mistake is live immediately. Parallel run lets you fail safely and fix issues before real traffic is affected.
Does ColdRelay help with migrations?
Yes. ColdRelay's onboarding includes migration planning for teams moving from Google Workspace, Microsoft 365, Mailforge, Inframail, or other providers. Standard migrations follow this checklist; large migrations (>1,000 mailboxes) get dedicated migration engineering support.