The CMS migration checklist that protects your rankings

Most CMS migrations blow their budget not on the database export, but on the content chaos that follows it. The export is the easy part. What costs a quarter of a content team's year — and what quietly erodes rankings for months after launch — is the re-authoring, the redirects nobody mapped, and the metadata that never made the trip.

This checklist walks through the work in the order it actually needs to happen. None of it is glamorous. All of it is cheaper than recovering a rankings slide you could have avoided.

Your sitemap is an aspiration. Your CMS is the truth. Before anything moves, export every page the system actually serves — including drafts, orphaned pages, old campaign landing pages and anything a crawler can still reach. The sitemap will miss pages that rank. The CMS will not.

Count them. Categorise them. Decide which ones are worth migrating and which ones are worth retiring deliberately. A page you retire without a plan is a page that becomes a 404, and a 404 is a ranking you handed back for free.

Every retiring address gets a redirect target. Not most of them — every one. Build the map as a single graph and validate it as a whole: no chains, no loops, no redirect pointing at another redirect.

A chain wastes crawl budget and dilutes authority at every hop. A loop is worse — it strands the crawler and the visitor together. Validate the graph before launch, not after, because the moment you cut over is the moment the old URLs start resolving somewhere new.

Titles, descriptions, canonicals and structured data migrate with the page, or the rankings do not. These are not decoration — they are the layer search engines read to understand what a page is about and how it relates to every other page.

Treat metadata as part of the content, not a property of the old platform. If the new CMS cannot carry it faithfully, that is a migration problem to solve before launch, not a detail to tidy up later.

Importing markup imports every problem the markup had. The inline styles, the broken tables, the nested divs that only rendered correctly in the old editor — paste them into a new system and you have simply moved the debt.

Re-author the content into clean, structured fields. It is slower than a copy-paste, and it is the difference between a migration that works and one that looks fine in a browser and falls apart in a crawler.

Stage the new site in full and compare it against the old, page by page, before you switch. Check the URLs, the metadata, the structured data and the rendered output — not just the editor view.

Then cut over in one move, and know exactly how you flip back before you flip. A rollback plan is not pessimism; it is the thing that lets you launch on a Friday without spending the weekend in a war room.

Launch is not the finish line. The last redirect bug surfaces in a crawler log, not a browser — a browser follows the chain and shows you a page; a crawler records every hop and tells you where the authority leaked.

Watch the crawl reports for weeks after cutover. Look for 404s, redirect chains, pages that dropped out of the index and pages that never got re-crawled. Fix them as they appear, and keep watching until the crawl settles.

The heaviest step in this list is re-authoring. Done by hand, it is a quarter of a content team's year. On an agent-first platform, it becomes a supervised import: the agent reads the old content, re-authors it into clean structured fields, and a human reviews the result before it goes live.

That does not remove the checklist — you still inventory, map and validate. It removes the part that used to be measured in person-months, and turns it into a review queue instead.