Cold Email Platform Migration Checklist

A cold email platform migration moves more than prospects and copy. It changes which system may send, which mailboxes and domains it controls, how authentication is observed, where replies and bounces land, and whether suppression survives. Treat it as a governed sender-and-sequencer cutover, not a campaign clone.

Define what the platform migration owns

This page owns the operational move between cold-email senders or sequencers. It does not choose a tool—that job belongs to the cold email tools buyer guide. It does not design message copy or timing; use the cold email sequence framework. Named exits such as the Outreach migration checklist and Salesloft export checklist document vendor-specific paths. A CRM system-of-record move belongs in the CRM migration checklist.

Write a charter with source and destination workspaces, sending domains, regions, business units, CRM authority, privacy owner, security owner, mailbox administrator, DNS owner, cutover commander, rollback owner, freeze timestamp, observation window, contract dates, retention, legal holds, and objective acceptance gates. Gangly did not execute this migration or inspect a vendor tenant; public documentation is an input, not proof that your account exposes the same fields or controls.

Inventory infrastructure, identities, content, and evidence

Inventory four linked layers before deciding what is portable. Add source count, owner, stable ID, authority, extraction method, destination, sensitivity, history requirement, retention, test, and evidence URL to every row.

“Warmup state” is an observation to record, not a portable reputation score. Mailbox and domain reputation is assessed by receiving systems and cannot be guaranteed by copying a vendor dashboard. Preserve the old platform’s observations only as historical evidence.

Assign a documented portability path to every asset

Use five labels: file export, report export, API retrieval, manual recreation, or unavailable/archive-only. For each path, record the official documentation URL, subscription, role, permissions, filters, fields, relationships, pagination, rate limits, download expiry, history window, and verification date. “Visible in the UI” does not mean “bulk portable.”

Representative official documentation shows why this discipline matters. Instantly’s account export guide documents separate paths and different scopes for CRM leads, campaign analytics, sending activity, connected accounts, sequence content, blocklists, and replies. Its workspace campaign-copy guide says campaign details can copy while leads, analytics, and replies do not. These are examples for that vendor, not a promise about any other platform.

• Preserve raw exports unchanged with job/request ID, administrator, parameters, source watermark, timestamps in UTC, schema, file size, checksum, row count, error log, and exclusions.
• Export configuration before changing it, then take a full business-data snapshot and a final delta after sends settle.
• Request a current data dictionary and exact contract or support confirmation for every material undocumented artifact.
• Label derived metrics separately from raw events. A dashboard total may not be reproducible after migration if definitions or attribution differ.

Freeze active sends and capture the final state

Stop new enrollment before stopping the systems that reveal current state. Build an active-work register containing prospect ID, sequence and version, variant, current step, next due timestamp and time zone, mailbox, thread ID, reply status, bounce state, suppression, owner, CRM ID, pending task, and approved disposition.

1. Ban new campaigns, sequence edits, sender changes, domain changes, new integrations, and list imports at the configuration freeze.
2. Choose complete in source, cancel, or transfer for every active enrollment. Do not blindly restart at the “same” step when waits, threading, replies, or local schedules differ.
3. Allow approved in-flight provider events to settle, then record a final-send watermark and capture the delta.
4. Pause source automation and revoke send authority only after evidence and rollback access are secured.
5. Keep the destination in shadow mode until seed tests and reconciliation pass.

Import the strongest stop state first. An unsubscribe, complaint, hard bounce, blocklist entry, regulatory restriction, or manual do-not-contact flag must not be weakened by a stale CRM record, replay, duplicate list, or destination default.

Transition DNS, providers, mailboxes, and authentication

Campaign data and sending identity are separate migration tracks. Snapshot the DNS zone and map every system currently authorized by SPF, every DKIM selector and signing domain, DMARC policy and reporting address, tracking CNAME, return-path domain, MX record, forwarding rule, and provider credential. Decide which records remain, change, or retire; require a DNS owner and rollback value for each change.

Google’s current email sender guidelines document SPF or DKIM requirements for all senders to Gmail and additional SPF, DKIM, DMARC, alignment, and unsubscribe controls for bulk senders. Google also says email-provider use does not guarantee that mail passes its spam filters. Authentication checks prove configuration, not inbox placement.

Microsoft’s Exchange Online limits document recipient, message, and rate constraints and state that Exchange Online is not designed for bulk-mailing scenarios. Verify the current tenant and provider contract instead of copying a platform’s daily-limit setting.

DMARC links policy and reporting to DNS and evaluates alignment with SPF or DKIM identifiers; the older RFC 7489 description explains the mechanism but is now marked obsolete by newer RFCs, so use current provider guidance for implementation. Test actual headers at Gmail, Microsoft, and representative recipient domains. Record SPF result, DKIM signature and result, DMARC alignment/result, From, return path, Message-ID, List-Unsubscribe behavior where applicable, TLS observation, and received timestamp.

Reconcile records, fields, edges, suppression, and events

A platform migration passes only when governed business state reconciles. Join source and destination on stable source ID plus approved target ID. Report source-only, destination-only, equal, approved-transformed, mismatched, duplicate, quarantined, and excluded-with-reason.

Store denominators, exclusions, query/version, timestamp, owner, and evidence with every result. Reconcile suppression and pending-send state in full. Sample ordinary fields only under a frozen, stratified plan. Preserve raw reply bodies and personal data only when policy and lawful handling permit.

Stage a representative corpus and run seed tests

Test a stratified corpus with sends disabled before bulk import. Include different domains and providers, active and inactive mailboxes, aliases, custom fields, Unicode, empty values, duplicate prospects, multiple lists, different time zones, all sequence states, variants, replies, out-of-office, soft and hard bounces, unsubscribes, complaints, manual blocks, deleted owners, CRM conflicts, and webhook failures.

For seed messages, use controlled inboxes whose owners consent to the test. Test each mailbox-provider path and capture headers plus platform events. Confirm the right subject/body/variant, variable substitution, sender identity, thread behavior, reply routing, bounce capture, unsubscribe processing, CRM association, webhook retry, time zone, schedule, and suppression. A delivered seed is not evidence of broad deliverability.

Inject expired OAuth, revoked mailbox permission, DNS mismatch, duplicate webhook, delayed reply, CRM outage, partial import, provider throttle, and replay. The destination must expose failure, avoid duplicate sends, preserve suppression, and resume idempotently.

Dual-run without duplicate sends

Only one platform gets send authority for a person at a time. Use an immutable routing table keyed by prospect or mailbox plus campaign, with authoritative platform, start/end watermark, reason, owner, and override log. The shadow platform may import, calculate, and display tasks but cannot send.

Compare daily enrollments, scheduled touches, sends, replies, bounces, unsubscribes, complaints, meetings, owner changes, CRM writes, and suppressed identities. Test late events from the old platform after the nominal final-send time. They must update governed state without triggering a new destination touch.

Legal obligations depend on message type and jurisdiction. The FTC’s CAN-SPAM guide says its commercial-email rules include B2B email and require accurate headers and opt-out handling. The UK ICO’s electronic-mail marketing guidance defines direct marketing broadly and routes organizations to PECR rules. Qualified privacy or legal owners must define applicable consent, notice, suppression, retention, and transfer requirements; this checklist is not legal advice.

Cut over, roll back, and decommission safely

Use objective go/no-go gates and a timed rollback window. Cutover requires approved authentication observations, correct permissions, complete suppression, accepted data and event reconciliation, zero prohibited seed sends, working reply/bounce/unsubscribe paths, CRM idempotency, monitored errors, and named support coverage.

Roll back when identity or authentication is unexplained, suppression is incomplete, duplicates occur, replies route incorrectly, provider or CRM state diverges, critical history is missing, or the team cannot bound the risk before the approved outage ends. Rollback means disabling destination sends, exporting its delta, reconciling replies and stop events, restoring source authority, applying only approved changes, testing, and communicating—not merely clicking “resume.”

After the observation window, revoke old API tokens, webhooks, OAuth grants, mailbox permissions, users, SSO assignments, DNS authorization, tracking domains, provider routes, exports, and support access in dependency order. Archive raw files, schemas, maps, checksums, reconciliation, incidents, approvals, contract correspondence, retention decisions, and deletion evidence. Do not assume cancellation deletes every data copy.

Apply the worked example and calculate TCO

Worked example: a fictional migration has 8,000 eligible prospects, 650 suppressed identities, 21,000 required relationship edges, and 44,000 required events. The first destination load accepts 7,960 prospects, keeps all 650 suppressed, reconstructs 20,790 edges, and stores 43,560 events exactly once. These inputs are illustrative, not vendor or Gangly results.

• Record reconciliation = 7,960 ÷ 8,000 × 100 = 99.5%.
• Suppression preservation = 650 ÷ 650 × 100 = 100%.
• Edge reconciliation = 20,790 ÷ 21,000 × 100 = 99.0%.
• Event completeness = 43,560 ÷ 44,000 × 100 = 99.0%.

The 40 records, 210 edges, and 440 events enter an exception queue with source IDs, reasons, owners, and disposition. Whether the load passes depends on thresholds frozen before inspection. Calculate TCO as remaining source contract + destination licenses + mailbox/provider cost + migration labor + vendor support + DNS/security work + integration rebuild + archive/storage + training + exception remediation + contingency. Keep one-time and recurring totals separate.

Print the cold email platform migration checklist

Copy this into the control register and add owner, due date, evidence link, exception, approver, and approval date.

1. Charter: ☐ scope ☐ jurisdictions ☐ owners ☐ contracts ☐ retention ☐ legal holds ☐ gates ☐ rollback window
2. Infrastructure: ☐ domains ☐ DNS ☐ SPF ☐ DKIM ☐ DMARC ☐ tracking ☐ providers ☐ IPs ☐ mailboxes ☐ aliases ☐ forwarding
3. Data: ☐ users/roles ☐ lists/prospects ☐ custom fields ☐ CRM IDs ☐ consent ☐ suppression ☐ replies ☐ bounces ☐ events ☐ analytics
4. Orchestration: ☐ templates ☐ sequences ☐ steps ☐ schedules/time zones ☐ variants ☐ variables ☐ senders ☐ active state
5. Portability: ☐ file/report/API/recreate/archive label ☐ official URL ☐ permissions ☐ limits ☐ omissions ☐ verification date
6. Freeze: ☐ stop enrollment ☐ active-work register ☐ final send ☐ snapshot ☐ checksums ☐ delta ☐ strongest suppression imported first
7. Test: ☐ stratified corpus ☐ seed inboxes ☐ headers ☐ reply/bounce/unsubscribe ☐ CRM/webhooks ☐ retries ☐ no prohibited sends
8. Reconcile: ☐ counts ☐ fields ☐ edges ☐ suppression ☐ events ☐ duplicates ☐ exceptions ☐ reports
9. Cutover: ☐ one send authority ☐ shadow dual-run ☐ late events ☐ hard gates ☐ monitoring ☐ communication
10. Close: ☐ rollback rehearsal ☐ revoke access ☐ remove DNS authorization ☐ archive ☐ retention ☐ deletion request/evidence ☐ postmortem

Final gate: no in-scope identity may become sendable merely because the platform changed, and no person may receive a duplicate touch because both platforms believed they had authority.