Open any directory of content platforms and scroll. A meaningful share of the entries have the look of software that stopped: a blog that ends, a changelog that thins out, documentation for a version nobody runs. That is the ordinary shape of a young software category, and it is the background risk behind every platform decision you make.
The useful question is not which vendors will survive. Nobody knows that and anybody who tells you is guessing. The useful question is what it would cost you if the one you picked did not, and that is answerable in advance, in about an afternoon.
Lock-in is four separate things, and only one of them gets discussed
“Can I get my content out?” is the question people ask, and it is the least of the four.
Your content. The words, the images, the metadata. This is the part vendors compete on and most of them do reasonably. It is also the part that matters least, because content is portable by nature and even a mediocre export gives you something to work from.
Your content model. The structure you built: which types exist, what fields they have, how they reference each other, what is required and what is optional. An export usually contains content shaped by the model rather than the model itself. Rebuilding the model on a new platform is a design job, and it has to be done before a single post can land.
Your integrations. Everything wired into the platform: the front end that reads from it, the analytics, the search, the forms, the deployment. Each of those was built against one platform’s specific way of doing things, and each is separate work to redirect.
Your team’s habits. Six months of learned workflow, editorial conventions, and unwritten rules about who does what. This is unrecoverable and nobody counts it, and on a small team it is frequently the largest of the four.
When people say a platform has a good export and therefore low lock-in, they have addressed the first item and left the other three standing.
The four ways a vendor leaves, and they are not equally bad
Shutdown is the rare one and, oddly, the least dangerous, because it comes with notice, an export path and usually a migration window. It is a bad month and a known bad month.
Acquisition is the common one and the more awkward, because nothing appears to happen. The product keeps running. What changes arrives slowly: the roadmap redirects toward the acquirer’s priorities, the support you knew is replaced, the plan you are on is closed to new customers and then, at renewal, to you. There is no day on which you have to act, which is why teams end up acting late.
Repricing does not require anybody to leave. A plan tier moves, a usage limit tightens, a feature you rely on becomes an add-on. Your options are pay, downgrade, or migrate, and migrating on someone else’s schedule is the expensive version.
Quiet abandonment is the worst and the least visible. Nobody announces anything. The platform runs. Releases slow, then stop. Documentation goes stale. Support answers, eventually. You find out when something breaks and nothing is coming to fix it. There is no notice period, because there is no notice.
Any planning that only covers shutdown is planning for the one case that comes with a warning.
What actually protects you, in order of how much it helps
1. A complete, self-serve, tested export
Not “we support export”. Three specific properties, and all three matter:
Complete. The words, yes, but also the media files themselves rather than links to them, the metadata, the relationships between pieces, the publication dates, the authors, the taxonomy. An export that quietly refers to your images rather than containing them looks fine while your account is still active, and that is exactly when you will test it.
Self-serve. You can run it yourself, today, without a support ticket. A vendor who requires a request to export your own content has told you what leaving will be like on the worst possible day.
Tested. By you, now, on your real content. Not read about.
2. A model you wrote down somewhere else
If the only description of your content model lives inside the platform’s interface, you will be reconstructing it from screenshots under time pressure.
Keep a plain document that lists your types, their fields, which are required, and how they reference each other. It takes an hour to write when you build it and it is the difference between rebuilding in a day and rebuilding in a week. It is also useful for a dozen other reasons, which is why the teams that keep one are not the ones being cautious, they are the ones being organized.
3. A boundary between your front end and their platform
If every template in your site reads directly from the platform’s own way of naming things, changing platform means touching every template. If there is one layer in between that maps their names to yours, changing platform means rewriting that layer.
Ask your developer whether that layer exists. It is a small thing to add at the beginning and an expensive thing to add later, and it is the most valuable insurance in this article that you personally will never see.
4. Knowing your own switching cost, as a number
Not precisely, but roughly: how many pieces of content, how many content types, how many integrations, how many people to retrain. A team that knows its move is a two-week job behaves differently from one that assumes it is a six-month job. Usually it is smaller than the fear, and the fear is what keeps teams paying for platforms they have outgrown.
Open source protects the code, not necessarily your content
The obvious hedge is to pick something open source and self-host it. That is a real hedge and it is narrower than it looks.
What open source genuinely gives you: nobody can take the software away. If the company behind it stops, the code exists and you can keep running the version you have indefinitely.
What it does not give you: maintenance. A project whose contributors move on is code that still runs and stops getting security fixes, stops supporting new versions of the things it depends on, and eventually stops being safe to run. You have the right to fix it. Whether you have anybody who can is a different question, and for most content teams the answer is no.
And self-hosting moves the risk rather than removing it. You now own the upgrades, the backups, the security patching and the 2am problem. That is a reasonable trade for some teams and a bad one for others, and it should be made deliberately rather than as a reflex against lock-in.
The licence itself is worth reading rather than assuming. Licences in this category are not uniform, some have changed over time, and “open source” on a marketing page is not a licence. Read the actual terms on the actual repository, and note the date you read them.
The test to run before you commit
Half a day, on the platform you are seriously considering, during the trial.
Put real content in. Not lorem ipsum. Ten of your own pieces, including the two that never fit anywhere, with their images, their categories, and their relationships to each other.
Export it yourself. No support ticket. Note how long it takes to find the export and how long it takes to run.
Open what came out. Are the images files, or links to files on their servers? Are the relationships there, or just names? Are the dates there? Is the model described anywhere, or only the content?
Write down what is missing. That list is your actual lock-in, expressed concretely, and it is worth more than every review of the platform you will read.
Then ask what it would take to put that content into a different system. Not do it. Just cost it, in days. If nobody on the team can answer that question even roughly, that is the finding.
What this does not mean
It does not mean pick the biggest vendor. Large platforms get acquired, reprice, and sunset products too, and the largest ones are frequently the least motivated to make leaving easy.
It does not mean avoid young platforms. A young platform with an honest export and a clear model is a lower risk than an established one with neither.
And it does not mean the answer is never to move. It means knowing what a move costs before you need one, so that when a vendor changes the terms you are choosing rather than trapped. What that move actually consists of, and which parts of a site survive it in what condition, is the whole of the CMS migration guide, and reading it while you are calm is a great deal easier than reading it while you are not.
The short version
Lock-in is content, model, integrations and habits, and only the first is on anybody’s feature list. Vendors leave in four ways and three of them arrive without notice. What protects you is a complete export you have actually run, a model written down outside the platform, one layer of separation between their system and your site, and a rough idea of what your own move would cost.
Open source is a genuine hedge on the code and not on the maintenance. And the test that tells you where you stand takes an afternoon and belongs in the trial, not in the crisis.
