Leaving Substack: a migration guide

01

Choose WordPress or a custom build

Start with how you publish. List the jobs your next site must do: editing, multiple authors, newsletters, search, comments, free sign-ups, paid access, podcasts and subscriber support. Mark which are essential on launch day.

WordPress is a practical starting point when you want an established editor, a large archive, several authors and room to add features. Choose a maintained theme, membership system and email service that work together. WordPress core alone is not a complete replacement for Substack’s newsletter and billing workflow.

A custom build makes sense when the publication needs a distinctive reading experience, unusual editorial workflow or integrations that an existing system handles poorly. Agree who maintains the code, how editors publish, how data is exported and how another developer could take over. Building custom software brings a continuing maintenance obligation.

Use a domain registered in your name or your organisation’s name. Keep administrative ownership of hosting, email delivery and payment accounts wherever the provider permits it. Ask for documentation and an exit process as part of the project.

Price the whole publication

Budget separately for the initial build and migration, ongoing hosting and maintenance, email delivery at your list size, membership licences, payment processing, and any agreed response cover. A low-cost website plan is not a realistic allowance for moving a paid publication.

Our WordPress services and website builds describe the wider options. A Substack migration needs its own scope based on the archive, subscribers, billing and launch work.

02

Inventory and export what you have

Create a migration worksheet with five headings: content, readers, billing, domains and integrations. Record totals before moving anything, so you can explain differences afterwards.

From Substack’s publication settings, request a content export and download it when ready. Open a copy and confirm that the expected posts and data are present. Separately, export the subscriber records from the Subscribers dashboard; clear any filters when you want the complete list. Substack’s export instructions describe the current controls.

Keep an untouched, dated copy in restricted, encrypted storage. Subscriber exports contain personal data. Do not upload them to an online converter or send them through a general support chat.

Record these separately:

• Content: published posts, drafts, authors, dates, sections, tags, paywall boundaries, images, audio, video and attachments.
• Readers: free, paid, complimentary, trial and cancelled subscribers; newsletter preferences; unsubscribed, bounced and suppressed addresses.
• Billing: the payment account, customer and subscription identifiers where available, prices, currencies, renewal dates, discounts and access already paid for.
• Links: the current domain, post URLs, popular pages, RSS feeds, podcast feeds and external links you can update.
• Other features: automations, comments, community activity, forms and analytics.

Do not assume Notes followers, recommendations, chat history, comments or app-specific features will be recreated by a content import. Check what your export actually contains and agree which parts will be archived, rebuilt or left behind. Record anything that needs a separate export or provider support.

03

Rehearse the content import privately

Set up a private staging site before touching the public domain. Password-protect it, keep it out of search, disable outgoing newsletters and welcome messages, and use test payment credentials. Use dummy reader accounts until you have an access-controlled environment for real subscriber data.

For WordPress

Agree the importer or conversion route for the actual installation. WordPress.com has a Substack import workflow, but its hosted-service features are not automatically available on an independently hosted WordPress site. Do not assume a raw Substack ZIP can be uploaded to any WordPress importer.

For a site hosted elsewhere, your developer should select a supported importer or convert the export into a format the chosen tools accept. Map the fields explicitly: title, body, original date, author, slug, categories and access level. Import images into the destination’s media storage where possible; an image that still loads from Substack is still a dependency.

For a custom site

Define the content model first, then map the export into it. Keep a stable source identifier or old URL for each record. The import must be repeatable without duplicating posts or overwriting subsequent edits. Keep a report of skipped records and missing assets.

Check representative posts before the whole archive

Try a short article, a long article, a paid post, a multi-author post and anything with audio, embeds or unusual formatting. Compare titles, dates, links, captions, images and paywall boundaries. Test as a logged-out visitor as well as an editor.

After the full rehearsal, reconcile the totals against the worksheet and investigate every discrepancy. Agree how new posts published during the project will be included in the final transfer.

04

Move newsletter readers and preferences

Choose one system to hold the authoritative newsletter subscription status. A WordPress user account, a newsletter opt-in and a paid membership are different records, even when they share an email address.

Map each export field into the destination. Preserve subscription state and the original consent information you have. Import suppressed, unsubscribed and bounced addresses as exclusions where the destination supports it; do not quietly turn them into active subscribers. Keep suppression records for reconciliation.

Deduplicate carefully. Do not merge two people simply because their names match, or remove a paid reader because they stopped receiving email. Compare counts by status rather than expecting one headline number to match.

Use existing permissions only for the publication and purposes readers agreed to. A move is not permission to add unrelated marketing. Review your privacy notice, processors and data locations; where a purpose or organisation changes, get advice on the appropriate permission and notification requirements.

Test the reader journey

With test accounts, try free sign-up, any confirmation step, delivery, preference changes and unsubscribe. Check that unsubscribing from a newsletter does not accidentally cancel a paid membership, and that cancelling payment does not silently resubscribe someone to email.

Keep welcome automations paused during bulk import. If the tools cannot import existing preferences accurately, resolve that before the first send. Ask the provider what records it needs to approve an imported list and what happens to rejected rows.

05

Plan paid memberships and billing

Treat this as a separate migration with its own acceptance checks. Do not cancel existing subscriptions, disconnect a payment account or ask everyone to subscribe again as a first step. That can create gaps in paid access, duplicate charges or unnecessary churn.

Choose the WordPress membership system or custom billing integration before promising a transfer. Ask its maintainer or implementer to confirm whether it can attach to your existing subscriptions and keep access in sync when a payment succeeds, fails, renews or is cancelled.

Establish which route is possible

1. Existing subscriptions can be recognised: confirm the payment-account connection, customer mapping, price mapping and event handling. Test access and the next billing action. Connecting the same Stripe account alone does not establish all of this.
2. Billing must be migrated: agree a provider-supported plan for customers, payment methods, subscriptions, dates and cancellations. Stripe’s migration overview explains why payment data and subscription mapping are separate pieces of work. Keep raw card details out of exports and spreadsheets.
3. Readers must take action: prepare an explicit re-subscription or payment-update process, preserve access they have already paid for, and explain timing and prices. Never describe this as an automatic transfer.

Separate monthly, annual, founding, gifted, complimentary, discounted, trial, past-due and cancelled-but-still-entitled readers. Identify app-store purchases or payment routes that the new system cannot manage; agree a specific path for those readers.

Check money and access independently

For each representative case, record the existing renewal date, amount, currency and paid-through date. Confirm the intended result in the new system. Test sign-in, access to paid articles, cancellation, payment failure and renewal using the provider’s supported test tools.

Agree exactly when the old system stops creating new subscriptions and which system owns future changes. If subscriptions must be recreated, coordinate the old and new schedules so only one charges the reader. Check platform fees and connected-app arrangements separately; a new website does not automatically remove fees from existing billing agreements.

Do not switch until you have an explained outcome for every paid-reader category. If the billing route remains unresolved, keep it running on the old system while you finish that work.

06

Set up and test email delivery

Website hosting and newsletter delivery are separate services. Confirm who sends newsletters, who sends login and receipt emails, and what each costs at your current and expected volumes.

Use a recognisable sender name and a reply address someone monitors. Have the provider supply the correct DNS records for SPF, DKIM and DMARC. Avoid adding a second SPF record at the same hostname; the configuration must cover all legitimate senders.

Send test messages to accounts at several major mailbox providers. Inspect authentication results, links, images, mobile layout, replies and unsubscribe behaviour. Test password-reset or login emails as well as the newsletter itself.

Google’s sender guidelines distinguish general and bulk-sender requirements, including authentication and one-click unsubscribe. Your provider should meet the applicable requirements before launch.

A new sending setup does not inherit a guaranteed inbox placement. Start at a volume agreed with the delivery provider and watch bounces, complaints and deferrals. Do not repeatedly resend to rejected addresses. Use clicks, replies and delivery errors alongside open rates, which can be affected by privacy features.

Before the first real campaign, confirm that only one platform is scheduled to send it and that the final suppression list has been applied.

07

Map URLs and protect search traffic

Make a list of old URLs and their new destinations. Preserve useful slugs where possible. For example, an old article at example.com/p/council-budget might move to example.com/council-budget/. It needs an article-to-article redirect, not a redirect to the homepage.

If you already use your own domain

Keep that domain and change its website destination at launch. Configure permanent redirects for paths that change, then test them along with images, feeds and subscription pages. Back up DNS first and change only the records required for the website. Keep mailbox and email-authentication records intact.

If you use a substack.com address

You do not control Substack’s domain or its server redirects. Confirm the options available to your publication with Substack; do not promise that redirects configured on your new site will affect the old address. Publish a move notice with links, update profiles and ask important referring sites to update their links.

On the new site, check canonical URLs, titles, descriptions and a working sitemap. Remove staging access restrictions and noindex settings only when the site is ready to launch. Verify the domain in Search Console and submit the sitemap; use a Change of Address only where the move is eligible and you can verify the required properties.

Google warns that search visibility can fluctuate during a move and recommends retaining redirects for at least a year where you control them. See Google’s site-move guidance. No migration can guarantee unchanged rankings.

Test your most-visited old links, not just a random new article. Keep a report of missing pages to work through after launch.

08

Tell readers what will change

Send a clear notice through your existing publication before the move. State the date, new web address, sender address, what changes for free and paid readers, and where to get help. Explain that a Substack login will not necessarily sign them into the new site.

Use the same publication name and recognisable sender identity during the transition. Put a matching notice on the old publication and the new website so readers can check an unexpected email.

Here is a starting point to adapt:

We’re moving [publication name] to [new domain] on [date]. You’ll still receive [newsletter name], now from [sender address]. Free readers: [explain any action]. Paid readers: [state the confirmed billing and access arrangements, including any action required]. You can check this announcement at [old publication link]. For help, contact [support address].

Replace every bracketed field with confirmed details. Only say that billing and prices remain unchanged if that has been verified for the reader’s category. Send separate instructions where some subscribers need to re-subscribe or update payment details.

Explain how to log in to paid content and how to unsubscribe. Give readers time to ask questions before any billing change. Do not bury an action that affects access inside a general announcement.

09

Run the launch checklist

Agree a quiet launch window and one person who can decide to pause. Keep the old publication and exports available. A rehearsal is complete only when the checks below have passed.

1. Reconcile the final data. Briefly freeze edits where needed, take fresh exports and apply new posts, sign-ups, unsubscribes and billing changes since rehearsal. Use a delta process that avoids duplicate records.
2. Check public and paid content. Test old URLs, archive search, images, author pages, mobile reading and paywall boundaries. A private article must remain private when logged out.
3. Check reader accounts. Test sign-in or reset links, free registration, preferences, paid access and cancellation. Verify that imported passwords have not been assumed to work.
4. Check billing ownership. Confirm renewal dates, access entitlements and the single system responsible for charges. Resolve exceptional subscriber categories before making promises to them.
5. Check email. Confirm authentication, delivery, reply handling, suppression lists and unsubscribe. Ensure old automations cannot send a duplicate campaign.
6. Take a recoverable backup. Include the destination database, media and configuration. Record the old DNS settings and how to restore them.
7. Switch and inspect. Change the agreed website records, verify HTTPS and redirects, remove launch-only restrictions, and check the live site as a reader.
8. Send the agreed announcement. Start normal publishing only after the public and subscriber checks pass.

Know what a rollback can and cannot undo

Pause the launch for missing paid access, unexplained billing differences, exposed private content or failed delivery. Returning DNS to the old website does not undo new payments, emails or reader changes. Keep a change log and reconcile both systems before trying again. Never restore an old database blindly over payments or sign-ups received after launch.

10

Monitor, then retire the old setup

For the first few days, check missing-page reports, support requests, email delivery and paid access daily. Review the first newsletter and actual renewal outcomes, including annual and exceptional subscriptions as their dates arrive.

Compare results with your pre-migration worksheet: archive totals, active email recipients, paying readers and billing records. Investigate differences rather than assuming a successful import message proves the move is complete.

Keep the old account, exports and relevant logs until the agreed checks and retention period are complete. Disable old publishing and billing paths only according to the confirmed migration plan. Do not delete the old publication simply because the new homepage works.

Update profile links, directories, RSS and podcast distribution settings where applicable. Leave a clear notice wherever you cannot redirect, and keep redirects working for readers following old links.

At handover, make sure you have:

• Ownership and recovery details for the domain, site, newsletter and payment accounts.
• A record of the import, exceptions, redirect map and billing arrangements.
• A tested backup and restoration process.
• An agreed maintenance plan, response hours and third-party costs.
• Instructions for publishing, supporting readers and exporting your data again.

The move is finished when you can publish, reach readers, manage memberships and recover the site without depending on an undocumented workaround.