Quick Answer

If you are thinking about switching newsletter platforms, do not migrate on emotion. Before you commit, verify five things in order: (1) what your current platform will actually export, (2) whether your automations can be rebuilt on the new platform or only partially recreated, (3) what happens to paid subscribers and revenue during the move, (4) how authentication and deliverability settings translate, and (5) how much downtime your audience will see. Treat the migration like a small publishing project — with a checklist, a buffer week, and a rollback plan.

Why a checklist matters

Switching newsletter tools is one of the highest-stakes operational changes an independent creator can make. Your subscriber list is the asset. Your automations are the engine. Your deliverability reputation is the unspoken contract with every inbox provider. A rushed move can quietly undo months of growth.

The good news: most modern newsletter platforms treat subscriber data as exportable by default. The less good news: the format of that export, and what it does not include, varies widely. A checklist helps you spot the gaps before you commit.

1. Subscriber export: what is actually in the CSV

Most platforms export subscribers as a CSV file you can open in Google Sheets, Excel, Numbers or any text editor. That part is fairly standard. The columns inside the CSV are where the differences appear.

Typical fields you should expect to see:

  • Email address
  • Subscription status (active, paused, cancelled, etc.)
  • Date the subscriber joined
  • Source of the signup (form, manual import, referral, etc.)

Some platforms include more. Substack’s subscriber export, for example, can include free vs paid status, payment amount, currency, last payment date, engagement signals such as posts read and comments made, and a coarse location derived from IP. That extra context is genuinely useful for segmentation — but only if your destination platform can accept those fields on import.

Practical step: before you export, open the CSV in a spreadsheet and confirm three things:

  • Email column is intact and not mangled by encoding.
  • Status values are spelled the way your new platform expects (some tools need “subscribed” while others accept “active”).
  • Date format parses correctly — a common cause of silent import failures.

2. Automations: portable in concept, rarely in detail

Automation workflows — welcome sequences, tagging rules, re-engagement drips, event-based emails — are usually the second-biggest reason a creator switches platforms. They are also the area where portability claims get stretched.

Ask each platform directly:

  • Can you export automation flows as a file, or only rebuild them by hand?
  • Which triggers carry over (new subscriber, tag added, link clicked)?
  • Which actions carry over (send email, add tag, notify webhook)?
  • What about conditional splits and delays — are they supported with the same semantics?

Realistic expectation: most platforms will require you to rebuild automations manually on the destination side, even if the triggers and actions look similar on paper. Budget half a day per active workflow. If you have more than five automations running, treat automation rebuilding as its own mini-project with its own checklist.

3. Paid tier: subscribers, revenue, and tax setup

If you run a paid newsletter, this is the riskiest section of the migration. Subscriber status is one thing; an active paid relationship with a real revenue stream is another.

Questions to answer before switching:

  • Can the new platform handle paid subscriptions natively, or do you need a separate billing tool (Stripe, Paddle, etc.)?
  • Who handles VAT, sales tax and refund disputes?
  • Can existing paid subscribers be migrated without forcing them to re-enter payment details?
  • What happens to active annual subscribers mid-cycle if you move mid-term?
  • Will your historical revenue and reporting come with you, or start fresh on day one?

A common safe pattern: finish one full billing cycle on the old platform, then move. Do not migrate on the same week a renewal is due — the bookkeeping headache is not worth it.

4. Deliverability settings: SPF, DKIM, DMARC and sending domain

Deliverability is what gets your email into the inbox instead of the spam folder. It is also where many self-migrating creators accidentally take a reputation hit.

At minimum, document on the old platform before you leave:

  • Your sending domain and any subdomains used.
  • SPF record contents.
  • DKIM selector and key.
  • DMARC policy (none, quarantine, reject).
  • Dedicated sending IP, if applicable.

On the new platform, confirm it supports custom domain authentication for all three. If you send from a shared IP pool, ask about warm-up plans — moving a list of engaged readers onto a fresh IP with no warm-up history can temporarily hurt inbox placement, even if every subscriber was opted in.

Also worth checking: suppression lists. Most platforms maintain an internal list of addresses that have bounced or complained, and they will not re-import those even if your CSV includes them. That is a feature, not a bug — re-sending to known complainers is how sender reputation gets damaged.

5. Migration downtime: how visible is the move to readers?

Your audience does not need to witness the migration. Plan it so they do not.

Two patterns work well:

  • Parallel run: keep publishing on the old platform for one more cycle, import subscribers into the new platform, send a test issue to your own addresses first, then switch the canonical subscribe link to the new platform. Old platform stays live as a fallback for a week.
  • Clean cutover: schedule the move on a low-traffic day, freeze signups on the old platform the night before, run the import, send a verification issue, then flip the subscribe URL.

Either way, update every place a reader might sign up: website forms, landing pages, social bio links, podcast show notes, YouTube descriptions. A silent sign-up form pointing at the old platform is the most common cause of “lost” subscribers during a migration.

Decision criteria: stay or switch?

You do not need to switch just because a competitor raised prices or shipped a flashy new feature. Switch only when at least two of these are true:

  • Your current platform cannot do something your workflow genuinely requires.
  • The total cost of staying (time, money, workarounds) clearly exceeds the cost of migrating.
  • You have a quiet two-to-four-week window where a small stumble will not hurt a launch.
  • You have tested the export, the import, and a real send on the new platform with a small slice of your list.

If only one applies, the move is probably not worth it yet.

A 7-day pre-migration checklist

  1. Export your full subscriber list as CSV and store a backup copy offline.
  2. Screenshot or download every active automation.
  3. Document current paid-subscriber count, MRR and renewal dates.
  4. Copy your SPF, DKIM and DMARC records into a single text file.
  5. List every public link that points to your subscribe form.
  6. Identify 50–100 test subscribers willing to receive a test send on the new platform.
  7. Decide your cutover day — ideally midweek, mid-cycle, mid-month.

A 1-day cutover checklist

  1. Freeze new signups on the old platform.
  2. Import the cleaned CSV into the new platform.
  3. Send a test issue to your test group and confirm inbox placement.
  4. Rebuild critical automations (welcome sequence at minimum).
  5. Flip the canonical subscribe link to the new platform.
  6. Update social bios, podcast notes and website forms.
  7. Keep the old platform live as a read-only archive for 7 days.

FAQ

Can I import a Substack subscriber CSV into another platform? In most cases yes — CSVs are a near-universal interchange format. The destination platform may not accept every column Substack exports (engagement, IP-based location, etc.), but the core email, status and signup-date fields are portable.

Will automations carry over automatically? Rarely. Expect to rebuild most flows on the new platform. Triggers and actions often look similar in marketing copy, but the underlying logic differs.

How long should I budget for a migration? For a list under 5,000 subscribers with a handful of automations, one to two weeks is realistic. For larger lists or paid tiers, plan a full month including a parallel run.

Do I need to re-confirm subscribers when switching? Most platforms do not require it for opted-in contacts you are bringing over, but a short “we have moved — please update your contacts” message to your most engaged readers helps keep deliverability healthy.

What if a subscriber does not show up after the import? Check status first — many platforms silently skip unsubscribed, bounced or complained addresses as a safety measure. Then verify date formatting and email encoding in the source CSV.

Sources