A CMS migration plan has to answer three questions, and the timeline at the top of most of them answers none: what you actually have, what survives the move, and who owns the redirects. Get those settled before the platform shortlist and the rest of the project is bookkeeping. Skip them and you will find out the answers anyway, in week eleven, at two in the morning.
Every migration plan I have been handed opens the same way. Six or seven phases in soft corporate colours, discovery through launch, and a go-live date at the right-hand edge that somebody has already promised to somebody else. It is a beautiful document. It is also an itinerary, and an itinerary is not a plan — it is a list of places you intend to be, written by someone who has not weighed the luggage.
What you need is closer to a manifest. Not where the project will be in week nine, but what is going on the boat, what it weighs, and which of it arrives as something other than what it was when it left.
The plan describes the new platform, and the risk is all in the old one
Read the average migration plan and count the lines describing the destination. Templates to build, components to design, a content model to agree. Now count the lines describing what currently exists. Usually one, and usually it reads migrate content, as though content were a single object with a handle on it.
That asymmetry is the whole problem. Nobody has ever been surprised by the new CMS. It does what the demo did. The surprises come from the site you already have: the four hundred pages nobody has opened since 2019, the PDFs linked from nowhere, the taxonomy three teams extended in three directions, the redirects from the last migration that turn out to be load-bearing. None of it is on the timeline, because a timeline has no column for things you have not counted.
So the first question is not when you launch. It is what you have got.
What the sites people migrate from actually look like
We scored 13,838 live sites drawn from the Tranco top-sites list against four things: whether a machine can reach the page, whether it stays reachable, whether its meaning is marked up, and whether there is any substance there to mark up. The full method and dataset are published.
The reachability numbers are fine. Median access sits at 95 out of 100, median durability at 91. The plumbing works. Hosting is solved, TLS is solved, the page comes back when you ask for it.
Then the floor drops out. Median structure: 55. Median substance: 44.
That gap is your migration risk, stated in advance and in public. The half of your site that works is the half the new platform replaces for you anyway — hosting, delivery, uptime, all of it arrives free with the move. The half that is already weak is the half you carry across by hand, in a hurry, under a date someone promised. Structure and substance do not port themselves. They are precisely what gets flattened when four hundred pages go through a migration script overnight.
A plan that budgets for the platform and not for the meaning has budgeted for the easy half.
Three questions, and the order matters
What survives, what gets rewritten, what dies. Not as a policy — as a list, with a name against each page. Most sites carry a third of their pages purely because deleting things requires a decision and migrating them does not. A migration is the cheapest opportunity you will ever get to make that decision, and the only moment when the cost of keeping something is visible. We wrote about scoring every page for exactly this.
What breaks quietly. Loud breakage gets fixed on launch day, because somebody sees a 404 and shouts. Quiet breakage is a canonical tag now pointing at a staging domain, structured data that did not survive the template rebuild, an image library that arrived without alt text. Nobody shouts. Traffic drifts down over six weeks and gets filed under seasonality. Ask any team who has migrated whether they kept their pre-launch numbers to compare against; the answer tells you how the last one went.
Who owns the redirects, and when. Redirect mapping is the most deferred task in this entire field. It has no visible output until the moment it has a catastrophic one, it is boring, and it is always assumed to be somebody else's job — which is why it lands on whoever is left in the room in the final week, working from a URL list exported that morning.
Where the plan should start
Backwards from the usual order. Before the platform shortlist, before the design sprint, before anyone says the word component: inventory what you have and score it. Every later decision is cheaper once that exists, and guesswork until it does.
That is the argument for auditing first, and I would make it even if we sold nothing. You can do it with a crawler, a spreadsheet and a patient afternoon. You can score the move without a scan to sanity-check the shape before committing, or get the grade and skip to arguing about what it says. If you already know which move you are making, the guide for that pair will tell you what usually carries and what usually gets rebuilt.
What you cannot do is plan the crossing without weighing the cargo, and then act surprised at the waterline.