Move your newsletter without losing consent, context or control

1. Define what must move

List every asset before touching DNS: subscribers, unsubscribe and bounce status, tags, custom fields, signup source, content archive, media, forms, welcome sequences, automations, templates, custom domains, sending identities, payment products, paid tiers, coupons, referrals, integrations and analytics exports.

Mark each item must migrate, rebuild, archive or retire. Assign an owner and validation test. This prevents the familiar failure where addresses move successfully but the welcome sequence, preference center or paid access does not.

2. Export subscribers and consent evidence

Export the full audience and the suppression records the platform makes available. Useful fields include email, name, created date, signup source, consent timestamp or basis, subscribed status, bounce state, tags, custom fields, paid status, tier and Stripe customer ID. Save an untouched dated export before cleaning a working copy.

Reconcile counts by status, not only total rows. If 12,000 records become 10,700 after removing unsubscribed, bounced and duplicate contacts, document the reason. Do not “recover” the difference by marking everyone subscribed.

US commercial email must follow CAN-SPAM requirements, including accurate headers, a valid postal address and an effective opt-out. UK and European electronic marketing often depends on consent or a specific permitted exception. Get jurisdiction-specific advice for your audience and business.

3. Configure the sending identity

Set up the custom sending domain according to the new provider’s current instructions. Google requires SPF or DKIM for all senders to Gmail and SPF, DKIM and DMARC for senders above 5,000 messages per day to Gmail accounts. Bulk marketing and subscribed messages must support one-click unsubscribe and include a visible unsubscribe link.

Copy DNS records exactly. Avoid creating multiple SPF records; combine authorized senders according to your DNS and provider guidance. Start DMARC at an appropriate policy, monitor reports and verify alignment between the visible From domain and authenticated domains.

Send test messages to representative mailbox providers and inspect authentication results. “DNS verified” inside the platform is necessary, not sufficient; the received message headers are the real evidence.

4. Rebuild the minimum viable publication

Recreate the core template, footer, physical address, unsubscribe link, preference controls, signup confirmation, welcome email and one critical automation. Test plain-text fallback, dark mode, long URLs, reply-to behavior and accessibility on mobile.

Import a small content sample before moving the full archive. Check canonical URLs, internal links, dates, authors, images and redirects. If old web posts will move to new URLs, prepare a redirect map and keep it versioned.

Rebuild segments from written rules rather than trying to recreate mysterious labels. “Engaged” should have a definition such as “clicked in the last 90 days,” not a name whose original logic is lost.

5. Move paid members as a billing project

Paid subscribers are not ordinary rows. Document the processor account, customer IDs, subscription IDs, product and price IDs, billing interval, renewal dates, coupons, tax configuration, failed-payment state and access tier. Read the source and destination platform’s current migration instructions.

Some moves can retain the same Stripe account and customer relationships; others require coordinated transfers, new checkout or support assistance. Test with internal or consenting accounts before moving the full paid audience. Confirm that access, receipts, cancellations, refunds and renewals behave correctly.

6. Run a controlled pilot

Import a small cohort that represents free, paid, tagged, inactive and recently engaged readers. Send a real but low-risk issue. Verify delivery, formatting, links, tracking choices, replies, preference changes and unsubscribe propagation.

Compare accepted, rejected and suppressed counts. Investigate rather than overriding platform safeguards. A lower accepted count may reflect duplicates, invalid addresses or suppression state that should remain excluded.

Do not promise zero deliverability change. A sending-domain or infrastructure transition can alter mailbox treatment. Start with wanted mail, consistent identity and a cohort likely to engage; monitor complaints and bounces closely.

7. Cut over with a written runbook

1. Freeze configuration changes in the old platform.
2. Take a final dated export and reconcile the delta since the pilot.
3. Import with suppression and subscription status intact.
4. Activate forms, automations and the new archive.
5. Apply tested DNS and URL redirects.
6. Run smoke tests from signup through unsubscribe.
7. Send to a controlled segment before the full cadence.

Write the conditions that trigger rollback: authentication failure, missing paid access, broken unsubscribe, unexplained count variance or abnormal bounce/complaint rate. Decide who has authority to stop the launch.

8. Monitor the first 72 hours

Watch delivery errors, hard and soft bounces, complaints, replies, link failures, unsubscribes, automation enrollment, payment events and support requests. Compare metrics with a normal range, not an idealized benchmark.

Keep an issue log with owner, severity and resolution. Reconcile new signups and preference changes across any period when both systems were active. Only retire the old platform after exports, redirects, billing and reader access are verified.

Your local migration board

This checklist saves completion state only in this browser’s local storage. It has no account, form submission or network request. Clearing site storage resets it.