The Migration Playbook: Moving Off Platforms You Do Not Own

Migration is the act of moving from rented land to owned land. It is, by definition, uncomfortable. You are leaving a place that handled the plumbing, the lawn, and the roof repairs in exchange for a place where all of that is your responsibility. The discomfort is real, and it is also temporary. What is not temporary is the structural change in your position: after migration, you own the platform your work lives on, your audience relationship is direct, and no algorithm stands between you and the people who chose to read what you write. This article is the practical playbook for making that move — from Medium, Substack, or WordPress.com to a self-hosted platform you control.

Why This Matters for Sovereignty

We have made the philosophical case throughout this series. Your content on a rented platform is a crop on someone else’s land. The platform controls the terms, the distribution, the monetization, and the data. You control the labor. The arrangement is not inherently adversarial — many platforms provide genuine value — but it is structurally asymmetric. The platform can change the terms at any time. You cannot.

Migration corrects this asymmetry. It is the point where the sovereign builder stops talking about platform ownership and starts doing it. The reason many builders delay is not ignorance of the principle. It is fear of the transition itself — the fear that their audience will not follow, that their search rankings will collapse, that the technical complexity will overwhelm them. These fears are understandable. They are also, with proper planning, manageable. The purpose of this playbook is to make them manageable for you.

The emotional hurdle deserves honest acknowledgment. Leaving a platform with built-in distribution — Substack’s recommendation engine, Medium’s home page, WordPress.com’s reader network — feels like giving up an advantage. And in the very short term, it is. But the advantage was never yours. It was a feature of the platform, extended to you under terms the platform controls, and retractable at the platform’s discretion. The audience that follows you to your own platform is yours in a way that no platform audience ever was. That distinction is worth the temporary discomfort of the move.

How It Works

The migration process varies by origin platform, but the structure is consistent: export your content, export your subscribers, set up your destination, import everything, preserve your search rankings, and communicate with your audience throughout.

From Substack to Ghost. This is the cleanest migration path currently available. Substack’s export function (Settings > Export Data) produces a zip file containing your posts and your subscriber list. Ghost has a native Substack importer that handles the content migration with minimal manual cleanup. Publication dates are preserved, formatting transfers reasonably well, and subscriber emails import directly into Ghost’s membership system. The main area requiring attention is images — verify that all images transferred correctly, as some may need re-uploading. If you have paid subscribers on Substack, you will need to set up Stripe on your Ghost site and communicate with those subscribers about the payment transition. Stripe’s customer portal makes this manageable, but plan for a few subscribers who will not complete the switch. Budget for a small attrition rate — typically 5-15% — and treat it as the cost of sovereignty.

From Medium to Ghost or WordPress. Medium’s export (Settings > Download your data) produces HTML files of your posts. Both Ghost and WordPress can import these, though the formatting may require more cleanup than a Substack migration. The critical step is preserving publication dates — both Ghost and WordPress allow you to set the original publication date on imported posts, and you should do this for every article. Search engines use publication date as a ranking signal, and losing date information can hurt your search visibility. Medium does not export your follower list in a usable format, which means your Medium followers are effectively lost. This is precisely why we argue that social platform followers are not an asset you own. If you have been driving Medium readers to an email list — as we recommended — those subscribers transfer with you. If you have not, this migration is a lesson in why the email list matters.

From WordPress.com to self-hosted WordPress. This is the most straightforward migration path in terms of content compatibility, since both sides use the same system. WordPress.com’s export tool (Settings > Export) produces an XML file that self-hosted WordPress imports natively. Themes and plugins may not transfer — if you were using a WordPress.com-specific theme, you will need to select or recreate your design on the self-hosted side. The subscriber situation depends on whether you were using WordPress.com’s built-in subscriber feature (which is platform-locked) or a third-party email service (which is portable). If the former, export what you can and treat it as motivation to use a portable email tool going forward.

The Proportional Response

The most important technical step in any migration is SEO preservation through 301 redirects. Every URL on your old platform — every article, every page, every tag page — should redirect permanently to its equivalent on your new site. A 301 redirect tells search engines that the content has moved, and that the search authority accumulated by the old URL should transfer to the new one. Without this step, you lose search rankings that may have taken months or years to build. Most platforms allow custom domain redirects or provide redirect functionality for a period after migration. Substack, Medium, and WordPress.com all handle this differently — research the specific options for your origin platform before you begin .

The timeline for a careful migration is two to four weeks. Rushing leads to broken links, lost content, and confused subscribers. The recommended approach is a parallel run: build and test your new site while your old site remains live. Publish a few new posts on the new site to verify that everything works — email delivery, membership signups, payment processing, analytics. Only after the new site is fully functional do you activate redirects from the old site and announce the move.

Audience communication is the human side of migration, and it matters as much as the technical side. Notify your audience before, during, and after the move. Explain why you are migrating — frame it in terms of ownership and direct relationship, not in terms of dissatisfaction with the old platform. Many readers will understand and respect the decision. Some will not make the transition, and that is acceptable. The subscribers who follow you to a platform you own are the ones who are actually invested in your work, and they form the foundation of a more durable audience relationship.

The communication sequence looks like this: two weeks before migration, send an email explaining the move and what to expect. On migration day, send an email from both the old and new platforms with the new URL and a simple instruction to update bookmarks. One week after migration, send a follow-up from the new platform confirming that everything is working and inviting anyone who missed the transition to re-subscribe. This sequence is not complicated, but it requires planning, and skipping it costs you subscribers you did not need to lose.

What to Watch For

The first risk is link rot. Every internal link in your imported content — links between your own articles — needs to point to the new URL structure. If your old URLs were medium.com/@username/article-title and your new URLs are yourdomain.com/article-title, every internal link needs updating. Most import tools do not handle this automatically. Spend the time to fix them. Broken internal links frustrate readers and signal to search engines that your site is poorly maintained.

The second risk is email deliverability. If you are switching email providers as part of the migration — from Substack’s built-in email to Ghost’s, for example — your new sending domain has no reputation yet. Email providers like Gmail and Outlook evaluate sender reputation when deciding whether to deliver your email to inboxes or send it to spam. Set up SPF, DKIM, and DMARC authentication for your domain before sending your first email from the new platform. Send to a small segment of your most engaged subscribers first and monitor delivery rates. Ramp up gradually over one to two weeks.

The third risk is the temptation to perfect everything before launching. The new site does not need to be flawless on day one. It needs to work: content loads, emails send, payments process, analytics track. Design refinements, additional features, and optimizations come after the migration is complete and stable. Perfectionism disguised as thoroughness is the most common cause of indefinite migration delays. Set a launch date, meet it, and iterate afterward.

Migration is not a one-time event that you endure and then forget. It is the moment where you cross from theory to practice, from understanding platform ownership to implementing it. The discomfort is real. The technical details require attention. The audience communication requires honesty and patience. But when it is done, you stand on your own ground. The content is yours, the audience relationship is direct, and no platform change can take either one from you. That is what the discomfort buys, and it is worth the price.

This article is part of the Build Your Own Platform series at SovereignCML.

Related reading: Digital Sharecropping: Why You Don’t Own What You Think You Own, Email: The Last Decentralized Channel, The Sovereign Creator Stack: A Complete Setup Guide