Newsletter Platform Migration Checklist: Move Without Losing Your Audience

A newsletter migration is complete only when subscribers, signup forms, automations, payments, domain settings, and important links all work—not when the old account is closed.

Moving platforms can improve your workflow, but rushing the change can create bounced emails, lost tags, broken paid access, or a publication archive that disappears from search.

Use this checklist before moving between platforms such as beehiiv, Kit, Substack, Ghost, or a WordPress-based email stack.

1. Decide what is actually moving

Make an inventory before exporting anything:

  • Free subscribers
  • Paid subscribers
  • Unsubscribed and suppressed contacts
  • Tags and segments
  • Forms and landing pages
  • Welcome and nurture sequences
  • Broadcast archive
  • Custom-domain settings
  • Analytics and tracking parameters
  • Payment and billing relationships
  • Integrations and webhooks

Do not assume that an export from one platform contains the same fields another platform needs. Compare the source and destination schemas first.

2. Export the audience and keep a backup

Export your subscriber list in the platform’s supported format and keep an untouched backup. Record the export date, subscriber count, and the fields included.

You should know whether the export contains:

  • email address
  • name
  • subscription status
  • consent or opt-in metadata
  • tags
  • signup source
  • paid or free status
  • subscription tier

Never delete the old list until the new system has been checked against it.

3. Rebuild the signup path

List every place a person can join:

  • homepage form
  • article form
  • link-in-bio page
  • checkout page
  • social profile
  • embedded form
  • free download
  • partner referral

Replace each form and test it from a new email address. Confirm the success message, confirmation email, welcome email, tag, and source attribution.

One working homepage form is not enough if old articles still send visitors to a form that no longer exists.

4. Recreate automations deliberately

Do not copy an automation without reading it. Rebuild the logic and test each branch:

  1. What event starts the automation?
  2. What tag or segment is added?
  3. How long is the delay?
  4. What happens when a person clicks?
  5. What happens when a person buys?
  6. Can an existing subscriber enter the sequence accidentally?
  7. Is any message sent twice?

Send test emails to multiple addresses and inspect desktop, mobile, plain-text, and unsubscribe behavior.

5. Protect paid subscriptions

Paid memberships require extra care. Confirm whether the destination platform can import or recreate:

  • active subscribers
  • subscription tiers
  • monthly and annual plans
  • payment records
  • failed-payment status
  • cancellation and refund history
  • customer access permissions

Do not promise readers that billing will transfer automatically until the destination platform documents the process and you have tested it.

Ghost documents member exports and Stripe-based subscriptions. Substack documents exporting publication and subscriber data, but payment and billing details still require platform-specific checks. Treat content export and payment migration as separate tasks.

6. Move the domain and archive safely

Before changing DNS or redirects:

  • save the current DNS records
  • list every important public URL
  • confirm the destination domain configuration
  • prepare redirects for article and signup URLs
  • check canonical URLs and sitemap output
  • verify HTTPS and email authentication

Keep the old platform available during the verification window when the terms allow it. Do not close the old account while important links, payment pages, or exports remain untested.

7. Run launch QA

Test the complete journey as a new subscriber:

  1. Click an old article or social link.
  2. Open the new signup form.
  3. Subscribe with a test address.
  4. Confirm the confirmation and welcome emails.
  5. Check the subscriber record, tag, and source.
  6. Click links inside the email.
  7. Test unsubscribe and preference controls.
  8. If paid, test checkout, access, receipt, cancellation, and refund instructions.

Repeat the test on mobile. Email and checkout failures are often device- or client-specific.

8. Monitor after launch

For the first two weeks, record:

  • delivery and bounce rate
  • unsubscribe rate
  • signup count
  • form conversion rate
  • automation completion
  • paid conversion and failed payments
  • broken links
  • search impressions and clicks
  • support questions

Compare the first two weeks with the previous platform only after accounting for seasonality, send frequency, list cleaning, and changes to the signup offer.

Migration decision rule

Move when the current platform creates a measurable limitation: cost at your actual revenue, missing automation, inadequate ownership, poor deliverability, or a publication structure you cannot maintain.

Do not migrate only because a competitor has a more attractive feature page. A migration consumes attention that could otherwise go into publishing and audience growth.

Final checklist

  • Audience export saved
  • Paid and free subscriber counts reconciled
  • Forms replaced and tested
  • Welcome and nurture automations tested
  • Paid access and billing plan verified
  • DNS, email authentication, and custom domain checked
  • Redirects and canonical URLs checked
  • Mobile signup and unsubscribe tested
  • Old platform retained during the verification window
  • Post-launch metrics recorded

The safest migration is boring: every list, form, automation, payment, and URL has an owner and a test result.

FAQ

Should I delete the old newsletter platform immediately?

No. Retain it during the verification window while forms, automations, payments, redirects, and unsubscribe flows are tested.

What should I test after moving a newsletter?

Test signup, confirmation, welcome emails, subscriber tags, links, unsubscribe controls, mobile behavior, paid access, billing, and refunds when relevant.

When is a migration justified?

Move when the current platform creates a measurable limitation in cost, automation, ownership, deliverability, or the publication structure.

Official pages checked