How to migrate from Kit, in one line: the export is easy, the visual automation graph does not travel, and the rebuild on the other side is the actual migration.
Kit (the tool formerly called ConvertKit, renamed in October 2024) is structurally different from Substack and from Beehiiv. Substack takes a percentage of paid revenue, so the case for leaving is arithmetic. Beehiiv's hard step is the Stripe handoff. Kit's hard step is that its core value is the automation graph, and no receiving platform can import that graph natively. Here is the order to do it in, and the trap at each step.
Run the math before you touch export
Kit does not take a cut of paid subscription revenue. The cost is a flat monthly tier that steps up by subscriber count, per Kit's pricing page. The free Newsletter plan runs up to 10,000 subscribers with a single automation. Creator starts at $39/month for 1,000 subscribers, $59/month at 3,000, $89/month at 5,000, and $199/month at 25,000. Creator Pro is $79/month at 1,000, $139 at 5,000, and $279 at 25,000, adding advanced reporting and subscriber scoring.
That flat number is what you are deciding to keep paying or stop paying. The move pays for itself when the receiving platform charges less at your list size and bundles in something Kit does not: a blog treated as an equal surface, a sending domain reputation that is actually yours, a subscriber record that travels. If the delta is a rounding error against the Creator Network you rely on, do not migrate yet. Kit's Creator Network reliably adds subscribers to publishers who participate; at scale it can add hundreds per month with no ad spend. That is a real number to weigh, per Kit's own Creator Network documentation.
What exports cleanly, and how
The subscriber export from Kit is straightforward. In the app, open Grow, then Subscribers. Select all, then Bulk Actions and Export. Kit emails a download link to your account address. The link expires after five days, so download it the same day, per Kit's export documentation.
The CSV includes email, tags, custom fields, and subscriber location (city, state, country) in additional columns. Before you upload it anywhere, open the file. Clean the comma-in-name rows, the empty emails, and the subscribers who signed up twice under different capitalization. The receiving platform will not do this cleanup, and every duplicate you leave in becomes a duplicate broadcast on the other side.
For broadcasts (Kit's term for one-off sends), most receiving platforms will not import them at all. Ghost's Kit importer pulls the subscriber list; Buttondown's does the same. If you want the archive to travel, copy your published broadcasts into a Google Doc first. The rich formatting will not survive the paste into a new editor either way, so treat the archive as source material, not as finished pages.
What does not export: the visual automation graph
This is the step that separates a Kit migration from a Substack or Beehiiv one, and it is where the switching cost actually lives.
Kit's visual automations are the orchestration layer of the product. A visual automation is a branching flow: an entry point (someone signs up, clicks a link, buys a product), then a sequence of actions, tags applied, conditional routing, and delays. Sequences are the content containers holding the actual emails; the visual automation is what fires them, per Kit's automations documentation. The two systems are wired together tightly on purpose.
No receiving platform has a native importer for that graph. The entry-point events do not map one-to-one across tools. Conditional branches use tag logic that is Kit-specific. The sequences the graph fires are stored in a different data model than most alternatives use. Even Ghost and Buttondown, which have Kit importers, pull subscribers and tags, not automations.
The practical consequence: if you leave Kit, the flows do not come with you. You will rebuild them on the new platform, or you will lose them.
The rebuild is the migration
This is where most Kit users overestimate the pain and where the honest answer is smaller than it looks. Most publishers who look at their own visual automation dashboard find three flows doing the actual work: a welcome sequence for new subscribers, a post-download sequence for lead magnets, and a re-engagement sequence for subscribers who have gone quiet. The rest of the graph is variants, old campaigns, and one-off automations that stopped running months ago and nobody removed.
A publisher migrating from Kit does not need a fifty-node canvas on the other side. They need those three flows, wired to the pages that tag subscribers at signup. We wrote the full case for that shape in three sequences from day one, and it is the same shape a working Kit account already runs, just without the debris around it.
Rebuild in order: welcome first, because it fires on every new signup and is the highest-impact flow to get live. Post-download second, one per lead magnet page that is still active. Re-engagement last, on a 60- or 90-day inactivity trigger. Copy the email bodies from Kit sequence by sequence, spot-check the merge tags on the new platform (Kit uses {{ subscriber.first_name }}, most others use a different token), and send a live test to yourself before flipping the trigger on.
Stripe, Commerce, and paid subscribers
Kit's paid-subscription surface is Kit Commerce plus a Stripe integration. Commerce runs on Stripe Express under the hood, and that connection was designed for Kit to receive purchase webhooks, not for the customer relationships to travel out cleanly. If your paid subs are on Kit Commerce, expect a Stripe-to-Stripe subscription migration to be the honest path, filed as a support ticket per Stripe's account data migration documentation. The alternative, asking every paid subscriber to re-enter card details on the new platform, produces the double-digit paid churn rate that other migration write-ups quietly bury in a footnote.
If you sell one-off products through Commerce (a workshop, an ebook), those are simpler. Migrate the paid subscriptions first, and keep Commerce active on Kit for one billing cycle after the switch so no in-flight one-off payment falls off a cliff. Then close it.
The first 30 days on the new sender
Announce four to six weeks before the cutover. Tell subscribers what is moving, when, and why. The biggest migration mistake is silence: readers who get an email from an unfamiliar sender after a quiet Kit feed mark it as spam, and the new sending reputation never recovers from the first impression.
If you were sending from a shared Kit subdomain rather than a custom sending domain, the sender reputation does not travel. The new platform starts from zero and warms a new domain over the first few sends. Plan for a slightly lower inbox placement rate on the first edition. If you were on a custom sending domain, the reputation follows the domain, not the platform, which is the whole reason a custom sending domain is worth the fifteen-minute DNS setup. We wrote more about that in our piece on the custom sending domain.
On cutover day, leave a goodbye post live on Kit pointing readers at the new home. If your custom domain points at Kit, repoint it to the receiving platform on day one. Send the first edition from the new sender within seven days; long gaps after a sender change train inboxes to forget you.
The point of the move
A subscriber converts roughly 10× better than a follower. That is the point of running a list at all, and it is the point of moving the list when the platform stops earning its place. The full math is in our piece on subscribers versus followers.
Nashra is the publishing OS underneath the writing: one editor, the subscriber list as the spine, the same draft becoming an inbox send and a blog post in one motion, on your own domain. Automations are a small, named set of flows that cover the work a publisher actually does, not a fifty-node canvas borrowed from e-commerce. Import and export stay free in both directions, and the next month is something we earn every month.
