Notice who publishes the articles you have been reading.
Platform vendors, migration agencies, hosting companies, and consultancies that bill for the move. Every well-ranked page on this question is published by somebody whose revenue depends on the answer being “leave”, and none of them is lying. They are answering a question they have a stake in, and the answer they would give if they had no stake is simply not written down anywhere.
This article is that answer. It is not an argument that you should stay. It is the case for staying, made properly, so that a decision to leave is a decision rather than a drift.
It contains no WordPress instruction of any kind. How to operate the platform is a different subject with a different owner, and this page will not drift into it.
Wanting to leave is not a reason to leave
The most useful question in this whole decision is the one nobody asks: would this problem come with me?
Because a surprising proportion of the reasons people give for moving are not platform properties at all.
“It’s slow.” Sometimes the platform. Frequently the hosting, the images, the theme, or an accumulation of things added over years. A new platform on the same hosting with the same images produces a faster site for a while and then the same site.
“It’s a security risk.” Usually a maintenance question rather than an architecture one. An unmaintained site on any platform is an unmaintained site.
“It’s bloated.” Almost always describes something that was installed rather than something that shipped. Removing things is available.
“The editor is bad.” This one is real and it is a genuine reason, and it is also worth checking whether the alternative is better for your specific writers rather than better in general. The test for that is short: can a non-developer actually publish on this? is an hour and it settles the question with the person who actually publishes.
“It doesn’t scale.” Frequently true of a specific setup and not of the platform. Worth establishing which.
“We want modern tooling.” An honest preference, and it is a preference rather than a business reason. It is worth saying out loud in those terms, because a project justified by a preference and budgeted as a necessity ends badly.
The reasons that genuinely survive the question
Some do, and they have a shape in common: they are things the platform structurally cannot do, rather than things your instance currently does badly.
A content model the platform cannot express. If your content is genuinely structured in a way the system fights, that is architectural and it will not improve.
Multiple front ends from one content source. A website, an app, a display, a partner feed. This is what the decoupled architecture is actually for, and it is the strongest reason on this list.
A team that has grown past what the workflow supports, in a way no configuration addresses.
A requirement that eliminates the platform. A localisation model, a compliance constraint, a data residency rule. Multi-language and multi-site covers the localisation version of this, and it does genuinely eliminate platforms.
A decision made for you. The people who maintain it have gone and nobody is replacing them.
Notice that none of those is “we are frustrated”. Frustration is a real signal and it points at something; the work is finding out at what.
What leaving actually costs
The migration cluster on this site exists because this is consistently underestimated, and the underestimate has a consistent shape: people budget the content transfer and nothing else.
The content transfer is the smallest part. What goes wrong is everything attached to it: relationships, embedded media, taxonomy structure, internal links, metadata, redirects, and the things nobody remembers exist until they are gone. What actually breaks during a CMS migration is the catalogue, and it is long.
The failures pass every check you would think to run. The count is right and the structure is gone. This is the recurring finding across everything this site has written about migration, and it is why a migration that “went fine” can produce a site that is quietly worse for years.
Everything integrated has to be rebuilt. Forms, search, newsletter, comments, analytics. Under a headless architecture these unbundle into separate services, which is covered in what you lose when you go headless.
Your team relearns everything, during a period when they still have to publish.
And you inherit a new set of dependencies, which have their own risks. What happens if the vendor shuts down or gets acquired covers the ones you are taking on.
That is why when not to migrate a CMS exists as its own article on this site: the timing and the reason are most of whether a migration is worth doing.
The six questions
Answer these honestly before deciding either way.
1. What specifically is wrong? One sentence, naming a thing rather than a feeling. If you cannot write it, that is the finding.
2. Is it the platform, the setup, the hosting, or the process? Three of those four travel with you.
3. Has anyone tried to fix it in place? Not “would it be easier to start over”, which is always the more attractive-sounding option. Actually tried.
4. What would be better afterward, specifically? Named. If the answer is “it would be modern”, that is a preference.
5. Who does the migration, and who runs the result? Both, by name. The second one matters more and gets asked less: self-hosted or cloud, who is on call at 2am is the question underneath it.
6. What is the total cost, including the year afterward? Not the quote. The quote, plus the integrations, plus the retraining, plus the things that will be found in month three.
If those six produce a clear case, migrate, with a plan. If they produce “we are frustrated and this looks nicer”, you have found something out, and it is worth more than the migration would have been.
The middle path nobody proposes
The framing is always stay or move, and it is a false pair.
Fix what is actually wrong. If the problem is hosting, change hosting. If it is a theme, change the theme. If it is the process, change the process. Each of those is smaller than a migration by an order of magnitude and each one is reversible.
Change one thing and wait. A migration is the largest possible change and the hardest to evaluate, because everything moved at once and you cannot tell which change produced which effect.
Decouple partially, if the actual requirement is a second front end, rather than replacing the whole system.
Improve the editorial workflow instead. A remarkable number of platform complaints are workflow complaints in disguise, and workflow is cheaper to change than architecture.
The honest position
For a great many content teams, the right platform is the one they already have, running better.
That is not a defence of any particular product. It is arithmetic: the launch takes weeks and the operating takes years, and the category is optimised for making the weeks look good. A platform decision made because the new thing demos well is a decision made on the smallest part of the timeline.
If you are going to move, move for a reason that survives question two, with a cost estimate that includes the year afterward, and on a schedule you chose. If you cannot, the case for staying is stronger than anyone selling you an alternative is going to tell you.
The short version
- Everyone ranking for this question sells the answer “leave”. That answer may still be right; it is not disinterested.
- Ask whether the problem travels with you. Speed, security, bloat and process usually do.
- Reasons that survive: a content model the platform cannot express, multiple front ends, a hard requirement, a team past what the workflow supports.
- Leaving costs far more than the content transfer, and the failures pass the checks you would run.
- Six questions. If you cannot name what is wrong in one sentence, that is the finding.
- The middle path is real: fix the thing that is actually wrong, one change at a time.
