The dos and don'ts of a CMS migration

A CMS migration is one of those projects where the difference between a clean result and a painful one is decided early, often before any content moves. The same failures repeat from project to project, and so do the same things that go right, which is what makes a list like this possible. What follows is the buyer’s version of that list, written for the person approving the project rather than the person writing the code. None of it requires you to read a line of that code. It requires you to know what to ask for and what to push back on.

Do treat it as a data project, not a copy-paste job

The single most common misconception is that moving a CMS is like moving house: pack everything, carry it across, unpack it in the same shape. It is not. Content in an old system is stored in that system’s structure, and the new system has its own. The work in the middle is turning one structure into the other without losing anything, and it is where most of the real effort sits. When a vendor treats a migration as a quick export and import, that is the moment to slow down and ask how they plan to handle the parts that do not map cleanly.

Don’t let anyone skip the content inventory

Before content can move, someone has to know exactly what there is: how many pages, of what types, with what relationships between them, and which of it is still worth keeping. A migration is the best chance an organisation gets to leave dead content behind, and the worst time to discover halfway through that nobody agreed what “everything” meant. Insist on a written inventory early. If the plan cannot say how many things it is moving, it cannot say how long it will take or what it will cost.

Do decide what not to migrate

Not all of it should come across. Years of a legacy CMS usually leave behind duplicate pages, abandoned campaigns, and content nobody has read since it was published. Carrying that forward costs money to move and clutters the new system on arrival. Agreeing what stays behind is a decision the business makes, not one the developers should make quietly on your behalf, so make sure it is on the table and signed off rather than assumed.

Don’t underestimate redirects

This is the step almost everyone underestimates, and the one most likely to cause a visible problem after launch. When URLs change, every old link, bookmark, and search-engine result that pointed at the old address needs to be sent to the new one. Miss that, and traffic drops in a way that shows up in the numbers weeks later, long after the launch was declared a success. The work to prevent it starts before a single URL moves, not after. We wrote about why we track redirects from day one because it is that reliable a source of pain. Ask your partner how they plan to map and verify redirects, and treat a vague answer as a warning.

Do insist on a verification step before cutover

There is a moment in every migration where the new system is ready and the old one is about to be switched off. Before that switch, someone should have checked the migrated content against the original: the same number of pages, the same assets, the same structure, spot-checked on real pages. This is not a formality. It is the difference between finding a problem while it is cheap to fix and finding it when it is live. A migration plan without an explicit “we check this before we cut over” step is missing its most important safeguard.

Don’t accept a plan without a rollback

Even a well-run cutover can surface something unexpected. The plan should include what happens if it does: how quickly the old system can be brought back, and who makes that call. Whether a team has an answer to that question is a reasonable proxy for how carefully they have thought about the rest of the risk.

Do keep the people who edit content involved

The people who will use the new CMS every day are the ones best placed to say whether it works for them, and they are often the last to be asked. Bring them in before the model is finalised, not after launch when the shape is fixed. A migration that is technically perfect but slower for the marketing team to use has not really succeeded.

Don’t freeze the whole business to do it

For a large organisation with many teams on the same platform, the instinct is to halt everything, migrate, and restart. That is rarely necessary and always expensive in lost momentum. There are patterns for moving teams across in stages while the old and new systems run side by side, which we covered in moving teams off a legacy stack without a freeze. Ask whether a staged move is possible before agreeing to a standstill.

Do get the scope, price, and date in writing first

The commercial dos and don’ts matter as much as the technical ones. Before work starts, the scope should be written down, the out-of-scope items named explicitly, the price fixed against that scope, and a delivery date agreed. What “done” means should be defined alongside each piece of the work, so the question of whether something is finished has an answer both sides agreed to in advance. A migration quoted as a loose range against a vague spec is a migration that will grow, and you will be the one paying for the growth.

The short version

If you remember nothing else: a migration is a data project, the inventory and the redirects are where it quietly goes wrong, the verification step before cutover is non-negotiable, and the scope and date belong in writing before anyone starts. The individual migration guides go deeper on specific platforms, from WordPress to Sitecore. If you are weighing a move and want a straight answer on whether it is worth it, book a call and we will tell you.