Do not migrate your CMS when the thing bothering you is not caused by the CMS. That covers most cases. A slow site, an ugly design, a messy archive, a publishing routine that has stalled, a category structure that grew wrong: none of those is a platform problem, and all of them survive a migration intact because they travel with the content. The reasons that genuinely justify moving are narrow. The platform is unmaintained or its costs are rising past what the site is worth, the people who write cannot operate it, or you need a capability the platform structurally does not have and cannot be given. If your reason is not on that short list, the migration will take a month, cost you your publishing rhythm, and leave you with the same complaint on a different login screen.
This is the honest-broker article in this cluster, and it exists because everything else here explains how to move well. Knowing how to do something is not a reason to do it.
The test: does migrating fix this?
Write down the actual reason you want to move, in your own words, before reading further. Then find it here.
| What is bothering you | Does migrating fix it? | What actually fixes it |
|---|---|---|
| The site is slow | Rarely | Configuration, images, hosting, and what the theme loads. All of these follow you to a new platform |
| The design looks dated | No | A design change. This is a theme or template job on any platform, including the one you have |
| The archive is disorganized | No | Editorial work on the archive. Migration does not tidy content, it relocates it, usually with more mess |
| The editor is unpleasant to write in | Sometimes | Worth testing first. Many platforms offer more than one editing experience |
| Writers cannot publish without help | Often yes | This is a genuine platform-fit problem and one of the strongest reasons to move |
| Maintenance keeps eating time | Sometimes | Diagnose the cause first. Plugin sprawl and neglected updates are habits, not platforms |
| Costs are rising | Sometimes | Check whether the cost is the platform, the hosting, or the add-ons. They have different answers |
| The platform is abandoned or insecure | Yes | This is the clearest case for moving, and it has a deadline attached |
| A competitor uses something newer | No | Their team size, budget and business are not yours |
| I am bored of it | No | Read the next section. This is more common than anyone admits |
Two rows in that table are worth the whole migration. Most people arrive at this decision holding one of the others.
The reason nobody writes down
Almost everything published about whether to replatform is written for a company with a web team, a budget cycle and a business case, and it advises building one. That advice is fine and it is not aimed at the person reading this. A one-person publication or a small team does not decide this in a meeting. It decides it at eleven at night, after a frustrating hour with the editor, and the real driver is usually some mix of boredom, aesthetic dissatisfaction and the quiet hope that a new tool will restart a writing habit that has stalled.
That hope is worth naming, because it is the most expensive one available.
Migration feels like progress and produces nothing. It has tasks, visible completion, tool comparisons and a clean new interface at the end. Every hour of it is an hour that feels productive and does not add a post to your site. For a publication whose whole value is its archive, a month spent moving the archive instead of extending it is a real cost that never appears on any budget.
If your posting rate has dropped and a migration project is what appeared instead, the migration is the symptom. Nothing about a new CMS makes writing easier, and the honest version of that feeling is usually that publishing has become unrewarding for reasons a login screen cannot address.
The three reasons that do justify moving
One: the platform is not being maintained. If the software is no longer receiving security updates, or the company behind it has gone quiet, or the version you are on is past end of life and the upgrade path is broken, you have a deadline whether you like it or not. Move deliberately now rather than urgently later.
Two: the people who write cannot operate it. If publishing a post requires a developer, or a workaround, or a person who is on holiday, that is a structural mismatch between the platform and the operation. It gets worse as the team grows and it is not fixable with training. This is the strongest content-side reason to move and the one most likely to pay for itself.
Three: you need something the platform genuinely cannot do. Note the word genuinely. Most “it cannot do that” complaints turn out to be “nobody has configured that”. The test is whether the capability is absent from the platform’s own documentation, not whether it is absent from your current setup. Multiple languages, multiple sites from one archive, and content models with real structure are the usual honest examples.
Anything else deserves a second look before it becomes a project.
Before you commit, do the cheap version first
Every complaint in that table has a cheaper experiment attached, and the experiments take days rather than weeks.
- Speed: measure it, then check images, plugin load and hosting before blaming the platform.
- Editor: try the alternative editing modes your platform already supports. Many have more than one, and people often do not know.
- Archive mess: fix fifty posts by hand. If that improves things, the problem was the content. If it does not, the problem was not the archive.
- Maintenance load: count what you actually spend an hour on. Plugin sprawl is a habit that reinstalls itself on any platform.
- Team friction: watch one writer publish one post, start to finish, without helping them. This single exercise resolves more platform arguments than any comparison article.
There is one more preparatory step that is worth doing regardless of the outcome. Take a proper export of your content and store it somewhere the platform cannot reach, as described in exporting your content so you are never trapped again. If you decide to stay, you have lost an hour and gained real insurance. If you decide to move, you are already holding the thing the move depends on. Either way, verify you can restore a full backup of the site before you change anything, which is the standing rule across this whole cluster.
If you are moving anyway, move for the right shape of reason
Deciding to migrate is legitimate. Just be precise about what you expect to change, because the precision determines how you plan it.
A migration driven by writer experience should be evaluated by watching a writer publish on the candidate platform, not by reading its feature list. A migration driven by cost should be checked against what the new platform costs in month twelve rather than month one. A migration driven by capability should confirm the capability exists in a form you can operate, not just in a form that exists.
And whichever it is, price the whole job honestly rather than the transfer alone. Whether to hire someone or do it yourself turns on the same variables, and what breaks in every CMS migration is worth reading before the decision rather than after it, because the failure list is part of the cost.
The version of this decision nobody regrets
Choose the platform properly, once, then stay a long time. The publications with the best archives are usually the ones that stopped shopping. If you are genuinely at the start of this and want to narrow the field before any of the migration mechanics matter, that work belongs in how to choose a CMS, and doing it carefully is the single most effective way to never read the rest of this cluster.
If you are already on something that works, that your writers can use, that is still maintained, and that does the things you actually need: the correct action is to publish something today. The full mechanics, for the cases that do warrant a move, are in the CMS migration guide.
FAQ
Will migrating to a new CMS make my site faster?
Usually not by itself. Most speed problems come from images, from what the theme and plugins load, and from hosting, all of which move with you. Measure the cause before assuming the platform is it.
My archive is a mess. Should I migrate and clean it up on the way?
Cleaning up during a migration sounds efficient and usually stalls both jobs. Clean the archive where it is, on the platform you already know, then decide whether you still want to move.
How do I know if my frustration is with the CMS or with something else?
Ask whether the same complaint would exist if the content were identical and the login screen were different. Design, content organization, publishing discipline and image weight all survive a migration unchanged.
Is it bad to migrate just because I prefer another platform?
It is not bad, it is just expensive, and the expense is paid in publishing time rather than money. If you go in knowing that and the archive is small, it can be a perfectly reasonable choice.
What is the strongest single reason to migrate?
That the people who write cannot publish without technical help, or that the platform is no longer maintained. The first gets worse every month you leave it. The second has a deadline attached whether or not you have set one.
Written July 2026. This article recommends no platform and takes no fee from any vendor. It is deliberately the article in this section that argues against the work the rest of it describes.
