Moving a Newsletter List Without Losing Half of It

Every newsletter platform worth using will let you export your subscribers. That is table stakes, it is usually one button, and it is the part of a migration nobody has trouble with.

What goes wrong is everything attached to the list. The archive of past posts, which may or may not export in a form another platform can read. The paying subscribers, whose billing relationships live with a payment processor rather than the newsletter tool. The URLs your posts have accumulated links at, which will break silently the moment the old site goes dark. And the statuses attached to each address, which decide whether the imported list is a clean list or a compliance problem.

This is the order to do it in, and the traps at each stage.

Before anything: take an export you do not need

The best time to produce your first export is a year before you intend to move.

A subscriber CSV costs nothing to generate and nothing to store, and having one turns any future platform decision from an emergency into an inconvenience. It also protects against the scenario nobody plans for: losing access to the account. A platform dispute, a compromised login or a billing failure while you are travelling all end the same way if the only copy of your list is inside the account you cannot reach.

Export monthly, keep the last three, and check that the file actually contains addresses rather than a job-queued placeholder. That habit is worth more than any other paragraph on this page.

Step one: export the subscribers, with their statuses

A subscriber export should be a CSV, and it should carry more than email addresses. At minimum you want the subscription status, the date each person subscribed, and — if you have them — the tags or segments that make the list useful.

Statuses matter more than anything else in the file. Your export will typically contain people who are subscribed, people who unsubscribed, and addresses that have bounced or been cleaned. Those categories must survive the move, because emailing someone who unsubscribed from your old platform is still emailing someone who unsubscribed.

Filter before you import. Keep the subscribed rows. Drop the unsubscribed, bounced and cleaned ones, and keep the unfiltered original somewhere safe as your record that you honoured the opt-outs. Beyond the compliance point, importing dead addresses onto a metered platform means paying for them, which is the mechanism described in what the meter actually counts.

Step two: deal with the paying subscribers separately

This is the stage that surprises people, and it is worth understanding before you commit to a date.

A paid newsletter subscription is a recurring billing arrangement, and it generally lives with a payment processor — usually Stripe — rather than inside the newsletter platform itself. Moving your list does not move those arrangements, and there is no universal button that does.

What this means in practice varies enough that you must ask both platforms directly rather than following a generic guide. In some cases the processor account is yours and the subscriptions can be pointed at a new platform. In others the arrangement is held by the platform and the practical route is to cancel and ask subscribers to re-subscribe, which is exactly as costly as it sounds.

One documented trap is worth flagging specifically: subscriptions bought through a mobile app store are a different kind of object from subscriptions bought on the web, and they do not necessarily survive a publisher leaving the platform they were bought on. If a meaningful share of your paying readers signed up inside an app, establish what happens to them before you announce anything.

Plan for a migration of paying subscribers to lose some of them. Announce it early, explain it plainly, and make re-subscribing a single click. The revenue arithmetic that might be driving the move in the first place is in who takes a cut of your reader payments.

Step three: rescue the archive

Your posts are content, and content is the part platforms are least consistent about.

Some export a structured file that another platform can import directly. Some export HTML. Some give you a folder of files that will need converting. And some give you an archive that technically contains your writing but reconstructs into something that does not resemble the original layout.

Do the export before you need it and open the file. Actually open it. Check that images are either embedded or reachable, that formatting survived, and that the post dates came across. An archive export you have never inspected is not a backup; it is an assumption.

If the archive will not transfer cleanly, decide deliberately whether it needs to. For a news-style newsletter, five years of back issues may be worth less than the week it would take to move them. For a reference-style publication where old posts still earn traffic, the archive may be the most valuable thing you own.

Step four: do not orphan the URLs

Every post you have published has a URL, and some of those URLs have links pointing at them from other people's sites. Those links are the reason search engines know your publication exists.

When you move, the old URLs either redirect to the new ones or they die. If they die, every link pointing at them dies with them, and the traffic they carried does not come back.

How much control you have over this depends entirely on what you were using. If your newsletter lived on your own domain, you can generally arrange redirects from the old paths to the new ones. If it lived on a platform subdomain, your options are narrower and you may be limited to whatever forwarding the departing platform offers, if any.

The practical advice is upstream of the migration: put your newsletter on a domain you own from the beginning. It costs a few dollars a year and it converts the single most expensive migration problem into a DNS change.

Step five: send the first issue deliberately

The first send from a new platform is the one most likely to land badly, because your sending domain has no reputation at the new provider's infrastructure.

Set up your domain authentication properly before the first send rather than after — this is the part of deliverability that is genuinely within your control, and it is covered in what a platform can and cannot promise about deliverability.

Then tell your readers what is happening in the first issue, in the first paragraph, and ask them to reply if the email looks wrong. Replies are the strongest positive signal an ordinary publisher can generate, and a migration is one of the few moments when asking for them is natural.

The short version

Export your subscribers with their statuses and filter before importing. Handle paying subscribers as a separate project with its own timeline and its own announcement. Open your archive export before you rely on it. Own your domain so the URLs survive. And set up authentication before the first send, not after the first complaint.

Which platform to move to is a different question, and it is the one the best newsletter platforms rate card exists to answer.