A lot of people say they trust a publishing tool because they host it themselves.
It is a comforting sentence. The server is yours. The database is yours. The files are yours. If things go bad, surely you can just leave.
Then the tool starts fighting you.
Maybe the writing interface has turned into a chore. Maybe the plugin pile got weird. Maybe the publication outgrew the setup. Maybe you just want a system that asks less of you. So you look at the way out and discover the ugly part: the server may be portable while the work is not.
The posts can come out, in some sense. But the publication has shape. It has URLs people already know, descriptions that frame the archive, internal links that connect the body of work, media paths that still have to resolve, drafts that are not ready yet, taxonomy that means something, and a working routine built around how this tool expects publishing to happen. Suddenly the question is not whether your content exists in a backup somewhere. It is whether leaving will preserve the thing you actually built.
That is where a lot of freedom talk around publishing tools falls apart.
Hosting control matters. Export buttons matter. Open formats matter. But none of those things, on their own, answer the trust question cleanly. A tool becomes easier to trust when leaving it is realistic enough to believe in. Not painless, not magical, not one-click perfect. Just survivable.
Why exit cost belongs inside trust
The point is not that you should always be planning to leave.
Most people do not choose a publishing tool because they are eager to migrate next quarter. They choose one because they want to get their work out, run the site without constant friction, and maybe stop thinking about infrastructure for a while. That is sensible. Staying is normal.
But believable departure changes the relationship while you stay.
If leaving would destroy your URLs, flatten the structure of your archive, break half your internal references, or force you to rebuild the whole editorial routine from scratch, the tool is already asking for more trust than it has earned. It is not just asking you to like its features. It is asking you to accept captivity as part of convenience.
Publishing tools deserve a sharper standard because the thing at risk is not only data. It is a public body of work and the working system around it. When a publisher moves, they are not migrating a blob of text. They are trying to carry over the archive, the framing, the routes people use to find things, and enough of the working method that publishing still feels possible on the other side.
That is why exit cost belongs inside trust instead of sitting off to the side as a weird technical concern for nervous people. A credible exit keeps a tool in its proper place. Useful. Chosen. Replaceable. If departure feels catastrophic, then staying is not fully voluntary, no matter how pleasant the dashboard looks on a good day.
The first shape of the problem
Exit cost usually shows up in publishing in a few predictable ways.
The first is false ownership. This is the self-hosting comfort story. You control the box the tool runs on, so you assume you control the future of the work. But self-hosting can still leave the publication tangled in plugin behavior, shortcode residue, custom fields, admin habits, and URL assumptions that only make sense inside one stack. You own the machine. The tool still owns the shape.
The second is export without structure. The text comes out, technically. Then the repair work starts. Categories change meaning. Metadata gets thinner. Access rules do not survive. Draft state gets weird. Embeds and references need triage. This is where a cheerful export button turns into a cleanup invoice.
The third is migration tax. A move can be completely possible and still cost far more than the feature list admitted. Redirects need mapping. Media paths want checking. Internal links need repair. Old formatting quirks surface all at once. The move is real, but it is expensive in the most annoying currency possible: focused publishing time.
The fourth is workflow collapse. This is the part a lot of tool comparisons underrate. Maybe the content imports well enough, but the actual way you publish does not survive. Scheduling habits depended on a plugin. Membership handling lived in platform-specific plumbing. Your homepage, archive assumptions, or editorial notes were built around one admin model. The archive moved, but the working method did not. You are not just migrating content anymore. You are rebuilding operations.
That is the practical reason a tool you can leave is easier to trust. The important question is not whether a platform offers some abstract right to export. It is whether leaving preserves enough of the publication that the move feels like a migration instead of a partial demolition.
WordPress is a good case precisely because it is not the villain people expect
This is why WordPress is such a useful grounding case. It exposes the mistake without needing a cartoon villain.
A WordPress site can be self-hosted, backed up properly, and still grow seams that are hard to carry elsewhere. That is what makes it a better example than a simplistic lock-in horror story.
The WordPress to Ghost path makes the boundary visible. Core posts and pages can move, and some common shortcode patterns can come across, so this is not a fake migration path. But the same path shows the more important limit. Custom post types do not come across in the standard flow. Most uncommon shortcodes do not survive cleanly. Plugin-driven access rules do not survive. Categories change meaning on the way over. Redirects still need work after the move.
That is not a scandal. It is a reminder. A tool can be open enough, exportable enough, even self-hosted enough, and still make the shape of the publication expensive to recover somewhere else. The honest reading is not that WordPress is a trap and everyone should flee. The honest reading is that hosting control solves one layer of dependence, while portability of the work depends on deeper things.
What a survivable exit actually has to preserve
A clean exit does not have to preserve every comfort. It does have to preserve the parts of the publication that make the work still feel owned on the other side.
The baseline is obvious. The published body of work has to survive as actual posts and pages, not as a folder of scraps you promise yourself you will reconstruct later. But that is only the floor.
A real publication also has routes. Readers know certain URLs. Other sites link to them. Search results remember them. If a move breaks that public map with no sane redirect path, the damage is not cosmetic. The archive has become harder to find and easier to lose.
It also has framing. A publication teaches readers how to move through it. Descriptions, excerpts, tags, categories, author information, series structure, homepage placement, archive logic, all of that helps the work arrive as more than a stack of files. Losing a little taxonomy neatness might be annoying. Losing enough framing that the archive turns flat and vague is a different class of damage.
Then there is everything that makes the body of work cohere internally. Media has to stay attached to the right places. Internal links should not collapse into repair archaeology. Drafts and scheduled pieces should not turn into rubble just because they were not public yet. If a move preserves only published body text, it has preserved the easiest part and dropped the working parts.
And finally, the workflow has to survive in some recognisable form. This matters more than a lot of migration talk admits. A small publisher is not only moving files. They are moving a working method: how drafts are staged, how pages are updated, how home and archive surfaces are maintained, how memberships or access rules are handled, how the whole thing stays operable week after week. If that all has to be reinvented from scratch, the exit was technically possible and practically hostile.
That is the standard that matters to me here. Not frictionless exit. Not one-click purity. A survivable exit. One where the archive, the structure, and enough of the publishing routine make it across intact enough that the tool still feels like something you chose, not something you are stuck inside.
A better export story still has seams
This is also why it helps to look at something less obviously tool-shaped than WordPress.
Substack is useful here because it offers a more mature exit story and still proves the point. You can export posts. You can export subscribers. You can move free and paid members into Ghost. If you used a custom domain, you are in a much better position than someone who built your public address on rented paths from day one. That is real portability.
It also is not the same thing as a clean departure.
The seams are different, but they are still seams. Paid migration depends on getting the payment side lined up correctly. Existing paid subscriptions can carry old platform baggage with them. Custom-domain moves still need redirect work because the old post paths and the new ones do not match cleanly. The content may come over, the audience may come over, and you can still spend real time repairing the public shape of the publication and the operating assumptions around it.
That is what makes Substack a useful contrast instead of a counterexample. It shows more honest portability than the worst platforms and still teaches the same lesson: a publisher is not only moving text. They are moving routes, readers, payments, drafts, habits, and all the little bits of structure that keep the work functioning.
Staying should remain voluntary
This is the trust test I keep coming back to.
A good publishing tool does not need to promise a perfect exit. It does not need to flatten every migration into a button and a cheerful success message. Publishing systems are too messy for that, and pretending otherwise usually means the hard parts are merely hidden until later.
But a trustworthy tool should make departure believable. The archive should survive. The routes through it should be recoverable. The publishing routine should not disintegrate the moment you step outside the original interface. If those things hold, staying keeps its proper shape. You are there because the tool still fits.
If the real answer is that leaving would cost too much structure, too much repair work, and too much of the routine that keeps the publication alive, then the tool is holding more of the relationship than it should.
If you want the neighboring Toni Notes workflow context, start with Most publishing problems are workflow problems in disguise, The last mile is part of the writing, and AI is useful for publishing, but only when it removes drudgery.