0 automatically excluded
All tools
INVENTORY / PROVE / RAMP / CUT OVER / RETIREMove the system.
Move the system.
Keep the evidence.
Turn an email-provider migration into owned controls, dependency-aware gates, dated evidence, a rehearsed rollback, and an exportable cutover record.
- 38 controls
- Applicability rules
- Rollback gates
CUTOVER EVIDENCE STATE / NOT A DELIVERABILITY SCORE
The migration is not yet cutover-ready.
Current provider → Target provider · cutover Oct 15, 2026 · evidence as of Jul 29, 2026.
22open blockers0 overdue · 0 proofs missing
A checklist cannot make an unsafe migration safe by itself.
Verify the delivered message, real provider behavior, recipient state, production throughput, receiver feedback, rollback authority, and post-cutover reconciliation.
0 verified states lack proof or owner
As of 2026-07-29
4 currently in progress
CUTOVER GATES
Readiness is only as strong as the weakest dependency.
01
Identity and DNS0 of 6 applicable blocker controls have verified evidence.
6 open02
Audience and suppression1 of 5 applicable blocker controls have verified evidence.
4 open03
Messages and integrations0 of 5 applicable blocker controls have verified evidence.
5 open04
Ramp and rollback0 of 5 applicable blocker controls have verified evidence.
5 openPHASE PROGRESS
Completion and risk across the migration path.
Inventory4/6 verified
67%1 blockers · 0 overdue
Foundation0/12 verified
0%10 blockers · 0 overdue
Parallel validation0/8 verified
0%4 blockers · 0 overdue
Ramp & cutover0/6 verified
0%5 blockers · 0 overdue
Stabilize & retire0/6 verified
0%2 blockers · 0 overdue
CONTROL LEDGER
Assign the work and attach reproducible proof.
01
Inventory every sending stream, owner, and business purpose
List production and non-production senders, applications, vendors, IP pools, volumes, message classes, recipients, and accountable owners.
EVIDENCEVersioned stream inventory reconciled against application code, provider accounts, DNS, billing, and vendor contracts.
NEXT ACTIONStop scope expansion until each route and owner is known.
Verified
02
Map From, envelope, DKIM, tracking, and link identities
Record visible From domains, return paths, HELO names, DKIM domains and selectors, tracking hosts, branded links, reply handling, and current alignment.
EVIDENCEIdentity matrix plus representative raw headers from every production stream.
NEXT ACTIONCapture the current state before changing DNS or provider configuration.
Verified
03
Baseline volume and receiver-level quality metrics
Record daily and peak volume by stream, domain, region, and major mailbox provider together with bounce, complaint, deferral, click, and conversion baselines.
EVIDENCEAt least four representative weeks with metric definitions, denominators, and known seasonality.
NEXT ACTIONCreate a comparable before/after baseline and preserve raw exports.
Verified
04
Reconcile audience, consent, and suppression sources
Identify the authoritative source for contacts, consent, subscription scope, complaints, permanent failures, manual blocks, legal holds, and deletion requests.
EVIDENCEData lineage, counts by state, field definitions, source timestamps, and sample records.
NEXT ACTIONResolve conflicts before any export or import.
Verified
05
Inventory templates, journeys, triggers, and dependencies
List templates, localizations, partials, assets, personalization, flows, schedules, triggers, suppression rules, and downstream actions.
EVIDENCEOwned catalog with active, dormant, test, and retirement classifications.
NEXT ACTIONRemove dead scope and assign migration acceptance criteria to active assets.
In progress
06
Inventory APIs, SMTP credentials, webhooks, exports, and secrets
Find every producer and consumer, authentication method, retry path, network restriction, secret location, webhook signature, and data export.
EVIDENCEIntegration diagram, credential owner, rotation plan, endpoint list, and replay expectations.
NEXT ACTIONTreat undocumented integrations as cutover blockers.
In progress
07
Configure target account ownership, least privilege, and recovery
Establish production ownership, MFA or SSO, roles, service accounts, recovery, support contacts, environment separation, and audit retention.
EVIDENCEAccess review signed by system and security owners.
NEXT ACTIONRemove shared human credentials and document emergency access.
In progress
08
Approve the post-migration identity and stream separation strategy
Decide which domains, subdomains, From addresses, return paths, DKIM domains, IP pools, and tracking hosts remain stable or change.
EVIDENCEApproved future-state identity diagram with transactional and subscription traffic boundaries.
NEXT ACTIONKeep familiar visible identity stable unless a documented reason requires change.
In progress
09
Prepare DNS ownership, TTL, coexistence, and rollback changes
Document every record change, authoritative owner, current and target values, TTL reduction timing, validation method, propagation window, and exact rollback.
EVIDENCEPeer-reviewed DNS change set and timestamped pre-change resolution evidence.
NEXT ACTIONNever replace authorization blindly; design a coexistence window.
Not started
10
Authorize old and new envelope paths without invalid SPF
Model the final SPF record, include both active routes during coexistence, stay within evaluation limits, and identify provider-managed return paths.
EVIDENCERecursive trace, lookup accounting, test messages, and retirement edit.
NEXT ACTIONAdd only the required authorization and schedule removal after residual old traffic reaches zero.
Open dependencies: Prepare DNS ownership, TTL, coexistence, and rollback changes · Approve the post-migration identity and stream separation strategy
Not started
11
Publish and validate target-provider DKIM signing
Create distinct selectors, publish target keys or aliases, enable signing, verify key strength and DNS, and retain old selectors during coexistence.
EVIDENCELive DNS evidence and delivered headers showing a valid aligned target signature.
NEXT ACTIONDo not remove old selectors while delayed, retried, or residual messages may still verify.
Open dependencies: Prepare DNS ownership, TTL, coexistence, and rollback changes · Approve the post-migration identity and stream separation strategy
Not started
12
Preserve DMARC alignment, policy, and aggregate reporting
Validate author-domain policy, target DKIM or SPF alignment, aggregate report destinations, external authorization, and enforcement impact before ramping.
EVIDENCECurrent record, report receipt, source inventory, and target-route DMARC pass headers.
NEXT ACTIONUse reporting to find missed legitimate routes; do not weaken enforcement as a substitute for correct alignment.
Open dependencies: Authorize old and new envelope paths without invalid SPF · Publish and validate target-provider DKIM signing
Not started
13
Configure branded return paths, tracking, links, and reply handling
Validate custom bounce domains, click/open hosts, HTTPS certificates, redirect behavior, reply mailboxes, and organizational-domain alignment.
EVIDENCELive DNS, certificate, redirect, alignment, and reply tests.
NEXT ACTIONAvoid an identity change that silently breaks links, replies, or alignment.
Open dependencies: Approve the post-migration identity and stream separation strategy · Prepare DNS ownership, TTL, coexistence, and rollback changes
Not started
14
Validate dedicated IP assignment, rDNS, TLS, and ramp capacity
Confirm ownership, forward and reverse DNS, HELO identity, TLS, pool separation, provider limits, and a volume plan appropriate to the new reputation surface.
EVIDENCEProvider configuration, DNS evidence, TLS headers, capacity limits, and approved warmup plan.
NEXT ACTIONDo not route full volume to an unproven dedicated pool.
Not started
15
Implement visible and RFC 8058 one-click unsubscribe
Preserve the body unsubscribe experience and validate List-Unsubscribe, List-Unsubscribe-Post, DKIM coverage, HTTPS POST behavior, list scope, and suppression propagation.
EVIDENCEDelivered raw headers, receiver-style POST test, suppression event, and subsequent no-send proof.
NEXT ACTIONTest the complete unsubscribe transaction, not header text alone.
Open dependencies: Publish and validate target-provider DKIM signing
Not started
16
Define contact, consent, field, list, and segment mappings
Map source types and semantics to target fields, resolve defaults and nulls, preserve timestamps and provenance, and define deterministic segment reconstruction.
EVIDENCEApproved mapping specification, counts, transformation tests, and rejected-row policy.
NEXT ACTIONDo not coerce ambiguous consent or date fields silently.
Not started
17
Import and protect the complete suppression state before contacts
Move unsubscribes, complaints, permanent failures, manual blocks, and required scoped preferences with timestamps and reasons before any target send is possible.
EVIDENCESource/target counts, hash or sample reconciliation, scope validation, and blocked-send tests.
NEXT ACTIONFail closed when suppression state is missing or ambiguous.
Not started
18
Define normalized event schema, signatures, retries, and idempotency
Map accepted, delivered, deferred, bounce, complaint, unsubscribe, click, and conversion events with stable identifiers, signature verification, retry, ordering, and deduplication rules.
EVIDENCEVersioned event contract, golden payloads, signature tests, retry matrix, and idempotency proof.
NEXT ACTIONKeep provider-specific payloads behind a normalized internal contract.
Open dependencies: Inventory APIs, SMTP credentials, webhooks, exports, and secrets
Not started
19
Build a representative seed and mailbox-client test matrix
Cover major mailbox providers, web/desktop/mobile clients, dark mode, text alternatives, images blocked, forwarded messages, and representative regional domains.
EVIDENCEOwned test matrix with received-message captures and raw sources.
NEXT ACTIONUse delivered messages, not only provider previews.
Not started
20
Verify authentication and routing in delivered target messages
Inspect Received, Authentication-Results, DKIM-Signature, return path, Message-ID, List headers, and tracking transformations from every target route.
EVIDENCERaw headers showing SPF, DKIM, DMARC alignment, expected routing, TLS evidence, and no unexpected identity.
NEXT ACTIONResolve the actual failing hop or identity before volume ramp.
Open dependencies: Authorize old and new envelope paths without invalid SPF · Publish and validate target-provider DKIM signing · Preserve DMARC alignment, policy, and aggregate reporting
Not started
21
Pass content, personalization, accessibility, and link acceptance
Compare source and target rendering, encoding, localization, fallbacks, conditional content, images, alt decisions, links, footers, and message size.
EVIDENCETemplate-by-template acceptance record with screenshots, raw HTML/text, and resolved defects.
NEXT ACTIONBlock active templates that have not passed representative delivered testing.
Open dependencies: Inventory templates, journeys, triggers, and dependencies · Build a representative seed and mailbox-client test matrix
Not started
22
Prove unsubscribe, complaint, and bounce suppression end to end
Create each terminal state through the target route, observe ingestion and propagation, then attempt sends through every connected application and re-import path.
EVIDENCETimestamped event chain, target/source state, queue cancellation, and verified no-send result.
NEXT ACTIONTreat any route that bypasses authoritative suppression as a cutover blocker.
Open dependencies: Import and protect the complete suppression state before contacts · Define normalized event schema, signatures, retries, and idempotency
Not started
23
Replay webhooks and test outage, retry, ordering, and duplicates
Exercise valid and invalid signatures, endpoint outage, repeated payloads, out-of-order events, delayed delivery, poison messages, and dead-letter recovery.
EVIDENCEReplay test results, deduplication evidence, alert capture, and recovery runbook.
NEXT ACTIONProve consumer behavior before switching production event authority.
Open dependencies: Define normalized event schema, signatures, retries, and idempotency
Not started
24
Prove transactional idempotency, latency, and failover behavior
Test application retries, provider timeouts, duplicate requests, stable message keys, priority separation, latency objectives, and explicit failover policy.
EVIDENCEFailure-injection results showing no unintended duplicates or silent loss.
NEXT ACTIONDo not dual-send transactionally without a deduplication design.
Open dependencies: Inventory APIs, SMTP credentials, webhooks, exports, and secrets · Verify authentication and routing in delivered target messages
Not started
25
Reconcile metric definitions, attribution, bots, and historical continuity
Map event denominators, unique logic, time zones, bot filtering, privacy effects, attribution windows, revenue joins, and dashboard ownership.
EVIDENCESide-by-side test-send reconciliation and documented expected differences.
NEXT ACTIONAvoid declaring migration harm from a metric-definition change.
Not started
26
Confirm provider limits, escalation path, and emergency contacts
Validate rate limits, daily caps, payload size, recipients/request, concurrency, retention, webhook behavior, support tier, and incident escalation.
EVIDENCEProvider confirmations, tested errors, monitoring thresholds, and named escalation contacts.
NEXT ACTIONSize the ramp to proven limits rather than advertised maximums.
Not started
27
Start with a low-risk, permissioned production cohort
Route a small representative cohort through the target while preserving source rollback and stable content, identity, consent, and measurement.
EVIDENCEApproved cohort definition, exact volume, received messages, metrics, and rollback observation.
NEXT ACTIONStop the ramp when authentication, quality, or event guardrails fail.
Open dependencies: Verify authentication and routing in delivered target messages · Prove unsubscribe, complaint, and bounce suppression end to end · Confirm provider limits, escalation path, and emergency contacts
Not started
28
Increase volume by stream and receiver under explicit guardrails
Stage volume by sending identity, mailbox provider, message class, engagement, and frequency while monitoring deferrals, bounces, complaints, and conversions.
EVIDENCEDaily ramp ledger with planned/actual volume, receiver metrics, decision, and approver.
NEXT ACTIONHold, reduce, or roll back when guardrails breach; do not average away one receiver's problem.
Open dependencies: Start with a low-risk, permissioned production cohort
Not started
29
Freeze unrelated changes and approve the go/no-go evidence pack
Freeze templates, audience logic, DNS, authentication, integrations, and unrelated releases that would obscure migration attribution.
EVIDENCEChange window, exception owner, final evidence index, open-risk acceptance, and signed go/no-go decision.
NEXT ACTIONMove the cutover when a blocker lacks evidence.
Open dependencies: Increase volume by stream and receiver under explicit guardrails
Not started
30
Rehearse rollback with thresholds, authority, and data reconciliation
Define who can roll back, which traffic moves, how DNS or application routing changes, how duplicates are prevented, how events reconcile, and how long recovery takes.
EVIDENCETimed rehearsal, exact commands or configuration, decision thresholds, communications, and recovered state.
NEXT ACTIONA rollback document that has never been exercised is not verified.
Open dependencies: Start with a low-risk, permissioned production cohort · Define normalized event schema, signatures, retries, and idempotency
Not started
31
Execute cutover from an owned runbook and record every change
Confirm final eligibility and suppression sync, pause unsafe queues, apply routing changes, validate target traffic, communicate state, and timestamp decisions.
EVIDENCECommand log, configuration diffs, DNS evidence, queue counts, target delivery proof, and incident channel record.
NEXT ACTIONUse one migration commander and explicit stop/go checkpoints.
Open dependencies: Freeze unrelated changes and approve the go/no-go evidence pack · Rehearse rollback with thresholds, authority, and data reconciliation
Not started
32
Staff live monitoring for delivery, events, queues, and business outcomes
Watch acceptance, deferrals, bounces, complaints, suppression, webhook lag, API errors, queue age, transaction latency, clicks, conversions, and support contacts.
EVIDENCEDashboards, alerts tested before cutover, staffed roster, thresholds, and incident timeline.
NEXT ACTIONMonitor by stream and receiver, not only global averages.
Open dependencies: Execute cutover from an owned runbook and record every change
Not started
33
Reconcile messages, events, suppression, and analytics across the boundary
Account for queued, accepted, delivered, deferred, bounced, complained, unsubscribed, clicked, and converted records during overlap and cutover.
EVIDENCESource/target ledger with duplicates, gaps, late events, repair action, and final disposition.
NEXT ACTIONKeep old event intake available until the late-event window closes.
Not started
34
Hold a stabilization window against baseline and receiver guardrails
Compare target volume, latency, deliverability, complaints, unsubscribes, conversions, support impact, and costs with the pre-migration baseline.
EVIDENCEDaily stabilization review with explanations for metric-definition and audience differences.
NEXT ACTIONDo not retire the source while material unexplained degradation remains.
Open dependencies: Staff live monitoring for delivery, events, queues, and business outcomes · Reconcile messages, events, suppression, and analytics across the boundary
Not started
35
Prove residual source traffic and late events are zero
Query provider logs, application configuration, DNS, retries, scheduled campaigns, background jobs, vendor routes, and inbound events for residual source activity.
EVIDENCEDefined observation window with zero-send and late-event evidence by route.
NEXT ACTIONDo not delete selectors, SPF authorization, credentials, or data while residual traffic exists.
Not started
36
Remove obsolete DNS authorization and source credentials safely
Remove old SPF mechanisms, DKIM selectors after verification windows, tracking records, API/SMTP secrets, webhook endpoints, and unused access.
EVIDENCEApproved removal diff, propagation proof, secret revocation, and target regression send.
NEXT ACTIONSequence retirement so rollback and delayed verification are no longer required.
Open dependencies: Prove residual source traffic and late events are zero
Not started
37
Export required data and close the source-provider contract
Export required logs, suppression, consent, campaign, template, invoice, and audit data; validate retention and deletion; then adjust or close the contract.
EVIDENCEArchive manifest, integrity checks, retention owner, deletion confirmation, and billing closure.
NEXT ACTIONExport before access or retention windows disappear.
Open dependencies: Prove residual source traffic and late events are zero
Not started
38
Complete post-migration review, documentation, and steady-state ownership
Record outcomes, incidents, assumptions, decisions, costs, metric discontinuities, technical debt, owners, and follow-up dates.
EVIDENCEPublished review, updated runbooks, system diagrams, data contracts, alert ownership, and accepted backlog.
NEXT ACTIONTurn migration evidence into the new operating baseline.
Open dependencies: Hold a stabilization window against baseline and receiver guardrails
Not started
ROLLBACK CONTRACT
One named migration commander can stop or reverse traffic without waiting for a committee.
Authentication, deferral, complaint, event lag, queue age, transaction latency, and business guardrails are explicit.
Routing and idempotency prevent the source and target from sending the same transactional message.
Suppression, late events, queued work, and accepted messages have an owned recovery procedure.
Rollback rehearsal is not yet evidenced as ready.
MIGRATION HANDOFF
Export scope, task states, due dates, dependencies, evidence, gates, and next actions.
THE REAL SYSTEM
An ESP migration moves identities, recipient state, event contracts, and operational authority.
Templates and contacts are only part of the system. Inventory every producer, consumer, credential, suppression path, DNS identity, webhook, metric definition, owner, and retirement dependency before designing cutover.
COEXISTENCE
Authorize both active routes, prove alignment, then retire the old path.
SPF, DKIM, DMARC, return paths, tracking hosts, reverse DNS, and visible identity need a planned overlap. Removing the old route too early can break retries and residual traffic; leaving it forever expands authorization.
FAIL CLOSED
Suppression moves before sendable contacts.
Unsubscribes, complaints, permanent failures, scoped preferences, and manual blocks must remain authoritative during export, import, dual operation, and replay. Test every application route after migration.
OBSERVED TRAFFIC
A configuration test is not a reputation or capacity test.
Begin with a small permissioned cohort, compare against a documented baseline, and increase by stream and receiver under explicit guardrails. Hold or reverse volume when evidence changes.
ZERO BEFORE DELETE
Retirement begins only after residual traffic and late events reach zero.
Keep the source available through the retry and late-event window. Export required records before access or retention disappears, then remove obsolete authorization, secrets, webhooks, and billing deliberately.
COMMON QUESTIONS
How long should an email migration take?+
Scope, identity changes, volume, dedicated infrastructure, data quality, integrations, and required validation determine the timeline. The target date should follow evidence, not replace it.
Should SPF be replaced on cutover day?+
Usually not. Authorize the active old and new paths during a controlled coexistence window, verify the final policy, then remove obsolete authorization after residual traffic reaches zero.
What data should move first?+
Authoritative suppression and consent state must be protected before the target can send to imported contacts.
Can we send from both providers during migration?+
Yes when identity, suppression, volume, measurement, and transactional idempotency are designed for coexistence. Uncontrolled dual sending can create duplicates and reputation spikes.
When can the old provider be closed?+
After queues, retries, scheduled sends, application routes, and late events are demonstrably quiet; required data is archived; rollback is no longer needed; and old authorization and secrets can be removed safely.