CMS migration checklist: a step-by-step plan to replatform without losing traffic
A practical CMS migration checklist for marketing and digital teams planning a replatform. Three phases, twelve steps, thirteen SEO safeguards - everything you need to move sites without breaking rankings, redirects, or the team.
On this page
Most CMS migrations don't fail at launch. They fail in the six weeks after, when rankings drop, redirects break, and nobody can find the brief that said which URLs were meant to change.
This page is the working summary of our CMS migration checklist. The full PDF gives you the printable version, the SEO safeguards in detail, and the QA sheet the team actually ticks off on cutover day. Read what's here first. If the shape of the plan fits how your team works, grab the download.
One thing up front: a CMS migration is not a technical project. It's an operational one. The work that protects your traffic happens in spreadsheets, content audits, and redirect maps, not in the new platform's admin UI. Treat it like a dev sprint and you will lose rankings.
What's in the CMS migration checklist
The downloadable guide is built around three phases, twelve migration steps, and thirteen SEO checks. The page you're reading covers the structure and the load-bearing decisions. The PDF gives you the printable checklist, the redirect-mapping template, and the post-launch monitoring schedule.
- The 3-phase migration framework, with owners and exit criteria for each phase
- 12 migration steps from content audit to cutover
- 13 SEO safeguards covering redirects, canonicals, sitemaps, and crawl health
- A redirect-mapping template you can drop straight into a spreadsheet
- A 90-day post-launch monitoring plan
The three phases of a CMS migration that doesn't break your traffic
Every migration we've reviewed that went sideways skipped or rushed one of these three phases. Usually phase one.
Phase 1: Pre-migration planning
The outcome of a CMS migration is mostly decided before anyone touches the new platform. Phase one is where you crawl the current site, lock the redirect map, agree on what you're not migrating, and write down what success looks like.
Concretely, phase one covers:
- A full crawl of the existing site with status codes, canonicals, and indexable URLs
- A content inventory split into keep, merge, rewrite, and retire
- A redirect map covering every URL that earns traffic, backlinks, or internal links
- A backup of content, media, and database that you've actually tested restoring
- Written success criteria, owned by marketing, not by IT
If your team can't agree on which URLs are retiring before the build starts, stop. That conversation does not get easier later.
Phase 2: Running the migration
Phase two is the build, the test migration, and the cutover. The pattern that works: stage the new site behind auth, run the migration end-to-end on staging at least twice, validate against the redirect map, and cut over during your lowest-traffic window.
- Staging environment with production-equivalent content and integrations
- A dry-run migration with reconciliation against the source
- Redirect validation - every old URL hits a 200 on the new site or a deliberate 301
- Search, forms, and tracking validated before DNS flips
- Low-traffic cutover window with rollback plan written down, not improvised
Phase 3: Post-migration monitoring
Phase three runs for 90 days. The mistake is treating cutover as the finish line. The first month after launch is when Google re-crawls, rankings shuffle, and any redirect you missed shows up as a 404 in Search Console.
- Submit the new sitemap and monitor coverage in Search Console daily for the first two weeks
- Watch Core Web Vitals on the new platform, not just the homepage
- Track rankings on your top 50 commercial queries against pre-launch baseline
- Keep redirects in place for at least 12 months
- Hold a 30-day and 90-day review with marketing, SEO, and the platform team
How to protect SEO during a CMS migration
Of the thirteen SEO checks in the guide, these five do the most work. If you only have time for half the list, do these.
- Map every URL that has earned a backlink, ranks in the top 50, or carries internal links. Anything else can be redirected to a parent category. These cannot.
- 301, not 302. 302s are temporary and Google treats them that way. Use 301s for permanent moves.
- No redirect chains, no redirect loops. One hop from old to new. Chains bleed link equity and Core Web Vitals scores.
- Update internal links to the new URLs. Don't rely on redirects to do the job - the redirect map is a safety net, not a primary route.
- Run a broken-link scan on the new site before DNS cutover. Then run it again 48 hours after.
The other eight safeguards - sitemap regeneration, canonical audit, hreflang handling, robots.txt review, structured data parity, image alt audit, crawl-error triage, and the 12-month redirect retention rule - are in the downloadable PDF above. The long-form companion piece, how to run a CMS migration without losing traffic, walks through a worked example.
Who this checklist is for
This is built for the team that actually owns a replatform, not just the agency running the build.
- Heads of digital and marketing leaders signing off on a new CMS
- SEO leads protecting organic traffic through cutover
- Ecommerce and content ops teams coordinating across regions or brands
- Platform and dev leads who want the marketing side of the plan written down
- Teams moving off legacy platforms - WordPress at scale, Sitecore, Adobe, or an aging headless stack
If you're evaluating where you'd land after a migration, the Core dna platform overview covers how we approach content, commerce, and multi-property delivery from a single backend.
