CMS Migration Plan: 14-Week Template With Cutover Runbook

9 min read ยท 2026-10-25

A CMS migration plan is the roadmap for moving your website content, templates and integrations from one content management system to another without losing pages, search rankings or form leads. It sets what moves, what gets cut, who owns each step and how the switch happens on launch day.

The template below covers 14 weeks in six phases, from discovery to post-launch checks. Each phase has steps and a milestone you can check. It also covers a filled-in example, who owns what, an SEO checklist, the cutover runbook and how to report progress to stakeholders.

Adjust the timeline to your site. A marketing site with a few hundred pages fits the 14 weeks. A site with thousands of pages, several languages or heavy integrations will need more time in the migration and testing phases.

The roadmap at a glance

Goal: Launch the website on the new CMS with all approved content migrated, every old URL redirected, forms and integrations working, and traffic stable in the first month. Duration: 14 weeks

  1. Discovery and scope (Weeks 1-2)

    Agree on why you are migrating, what is in scope and who decides.

    • Write down the reasons for the move, such as end of support, slow publishing or a new design, and turn them into two or three goals.
    • List every site, subdomain, language and integration in scope: forms, CRM, analytics, search, DAM, translation.
    • Name the decision owner for content, design, SEO and engineering.
    • Take a baseline from analytics and Google Search Console: top pages, organic traffic, conversions and indexed pages.

    Milestone: A one-page migration charter with goals, scope, owners and a traffic baseline, signed off by the marketing and IT leads.

  2. Content audit and URL map (Weeks 2-4)

    Decide what moves, what gets rewritten and what is retired, before anything is built.

    • Crawl the current site to export every URL with its title, template, traffic and inbound links.
    • Mark each page keep, merge, rewrite or retire, based on traffic, conversions and accuracy.
    • Build the URL map: one row per old URL with its new URL or the closest relevant page.
    • List content types (product page, article, case study, event) with their fields.

    Milestone: An approved content inventory and URL map, with a decision and an owner for every old URL.

  3. Content model and build (Weeks 3-8)

    Set up the new CMS so editors can publish every content type in the inventory.

    • Model each content type in the new CMS with its fields, rules and relationships.
    • Build page templates and reusable components from the approved design.
    • Set up roles and workflows: who drafts, who reviews, who publishes.
    • Connect integrations: forms to the CRM, analytics tags, consent banner, site search.
    • Prepare staging so the team can test with real content.

    Milestone: Every content type and template working on staging, with one real page of each type published by an editor.

  4. Migrate content (Weeks 7-11)

    Move the kept content into the new CMS, with automated import where it pays off and manual work where it does not.

    • Write an import script for high-volume types such as articles, and test it on a sample first.
    • Migrate low-volume or rewritten pages by hand with a checklist per page.
    • Move images and files, keep alt text, and fix broken internal links.
    • Set a content freeze date on the old site, and log every change made after it for a final sync.

    Milestone: All pages marked keep, merge or rewrite live on staging, checked against the inventory with no missing rows.

  5. Test and prepare cutover (Weeks 10-13)

    Prove the new site works and rehearse launch day.

    • Test redirects for every row of the URL map with a crawler and fix every miss.
    • Check metadata, canonical tags, structured data, the XML sitemap and the robots.txt file on staging.
    • Run user acceptance testing with editors and a business owner per section.
    • Test forms end to end, from submission to the record in the CRM.
    • Check page speed and accessibility on the main templates.
    • Write the cutover runbook and do a full rehearsal.

    Milestone: Go or no-go meeting passed: redirects, forms and key pages tested, runbook rehearsed, sign-off from marketing, SEO and IT.

  6. Launch and stabilize (Weeks 13-14)

    Switch to the new site with a rollback ready, then watch closely for problems.

    • Follow the runbook: final content sync, DNS or routing switch, redirects on, smoke tests.
    • Submit the new XML sitemap in Google Search Console and watch the coverage reports.
    • Check 404 errors, traffic and form submissions daily for the first two weeks.
    • Hold a short review at the end of week 14 and hand over a list of open fixes.

    Milestone: New site live with no critical issue open, forms delivering leads and organic traffic tracked against the baseline.

Example: a CMS migration plan filled in

Picture a B2B company moving a marketing site of about 600 pages from an old on-premise CMS to a headless CMS with a new front end. The goals: faster publishing, a new design and no loss of organic leads. Here is how the plan could look with owners and milestones.

The plan retires a large share of old pages, which is common. Pages with no traffic, no links and outdated content cost time to migrate and add nothing.

  • Weeks 1-2 (Digital marketing lead): charter signed, baseline taken from analytics and Search Console. Milestone: scope covers the main site and blog, not the support portal.
  • Weeks 2-4 (Content strategist and SEO lead): crawl of 600 URLs, about a third retired, old press releases merged into one archive page. Milestone: URL map approved.
  • Weeks 3-8 (Tech lead and front-end developers): six content types modeled, templates built, forms connected to the CRM. Milestone: one real page per type on staging.
  • Weeks 7-11 (Content team and developer): blog posts imported by script, product pages rewritten by hand, content freeze from week 10. Milestone: inventory reconciled on staging.
  • Weeks 10-13 (QA lead and SEO lead): redirect crawl, UAT with section owners, rehearsal on a Tuesday evening. Milestone: go decision recorded.
  • Weeks 13-14 (Tech lead): launch, daily 404 and lead checks, review meeting. Milestone: no critical issue open, lead volume stable.

Who owns what

A CMS migration touches marketing, IT, legal and every team that publishes content. Without named owners, decisions such as retiring a page or changing a URL stall for weeks.

Put these roles in a RACI on the first page of the plan, and give every section of the site a business owner who signs off its pages in UAT.

  • Sponsor (head of digital or marketing director): final call on scope, budget and the launch date.
  • Project manager: plan, RAID log, weekly status and the go or no-go meeting.
  • Content strategist: content audit, keep or retire decisions, editorial rules.
  • SEO lead: URL map, redirects, metadata, Search Console checks.
  • Tech lead: CMS setup, integrations, import scripts, hosting and DNS.
  • Section owners: review and approve migrated pages.
  • Legal or compliance: privacy notices, consent banner and regulated content.

The SEO checklist for a CMS migration

Most traffic drops after a migration come from missing redirects, changed titles or pages that were dropped without a replacement. Keep URLs the same where you can. When a URL must change, send a permanent 301 redirect straight to the new page, not through a chain.

Run these checks on staging before launch, then again on the live site in the first week. If the domain changes as well, use the Change of Address tool in Google Search Console after launch.

  • Every old URL in the map returns a 301 to a relevant new URL, with no chains or loops.
  • Page titles, meta descriptions and headings carried over for pages that rank.
  • Canonical tags point to the new URLs.
  • Internal links updated so they do not depend on redirects.
  • Staging blocked from search engines, and that block removed from the live site.
  • New XML sitemap submitted in Google Search Console.
  • Analytics and tag manager firing on every template.

The cutover runbook

The runbook is a step-by-step script for launch day: each step with a time, an owner, a check and what to do if it fails. Write it in a shared sheet so everyone sees progress live during the cutover.

Rehearse it once on staging. Pick a quiet time for the real launch, usually early in the week, so the team is available for fixes. Avoid launching just before a holiday or a big campaign.

  • Final content sync from the old CMS, covering every change logged since the freeze.
  • Lower the DNS time to live a day or two ahead so the switch spreads faster.
  • Switch DNS or routing, then turn on redirects.
  • Smoke test the homepage, top pages, forms, search and a sample of redirects.
  • Agree on a rollback trigger and the steps to point traffic back to the old site.
  • Send a launch note to stakeholders with the open issues list.

Risks and dependencies

Most CMS migrations slip for the same reasons: content takes longer than expected, integrations surprise the team, and stakeholders ask for redesign changes late. Track each risk in a RAID log with an owner and a fallback.

Content is the most common blocker. Rewriting a page needs a writer, a reviewer and often legal sign-off. Start content work in week 2, not after the build.

  • Content late from business teams: owner is the content strategist, fallback is migrating the page as is and rewriting after launch.
  • Integration not ready (CRM, search, DAM): owner is the tech lead, fallback is a simpler version for launch.
  • Old CMS license ending: owner is the sponsor, fallback is a short extension negotiated early.
  • Scope creep from design requests: owner is the project manager, fallback is a post-launch backlog.

How to report progress to stakeholders

Send a weekly one-page status: phase, percent of the inventory migrated, redirects tested, open risks and the decisions you need. Stakeholders want to know whether the launch date holds and what they must do this week.

For the steering committee, show the six phases on a timeline with the current week marked, a red, amber or green status per phase and the next milestone. Keep page-level detail in the inventory sheet, not on the slide.

Common mistakes to avoid

  • Starting the build before the content audit means you build templates for pages you will retire, so finish the audit and URL map first.
  • Migrating every page as is moves years of outdated content, so mark each page keep, merge, rewrite or retire before you move it.
  • Redirecting all old URLs to the homepage loses rankings, so map each old URL to the closest relevant new page.
  • Leaving the content freeze undefined causes lost edits, so set a freeze date and log every change made after it.
  • Testing only on desktop with one editor misses real problems, so run UAT with section owners on the main devices.
  • Launching without a rollback plan turns a small issue into an outage, so write the rollback trigger and steps into the runbook.

Frequently asked questions

How long does a CMS migration take?

It depends on the number of pages, content types, languages and integrations. A marketing site of a few hundred pages often fits in about three months. Large sites with many languages or complex integrations can take much longer, so plan from the content audit, not from a fixed date.

What should a CMS migration plan include?

Goals and scope, a content inventory with keep or retire decisions, a URL and redirect map, the content model, a migration method, a testing plan, a cutover runbook and post-launch checks. Add owners for each phase and a RAID log.

How do you avoid losing SEO in a CMS migration?

Keep URLs where you can, redirect every changed URL with a 301 to the closest relevant page, and carry over titles and metadata for pages that rank. After launch, submit the new sitemap in Google Search Console and check 404 errors daily for the first weeks.

Should you migrate content manually or with a script?

Use a script for high-volume, well-structured content such as blog posts or product pages. Move low-volume pages or pages being rewritten by hand. Always test the script on a sample and compare the result against the inventory.

What is a content freeze in a CMS migration?

It is the date after which editors stop changing the old site, or log every change for a final sync. It prevents edits from getting lost between the import and launch. Keep it as short as you can and announce it early.

Generate this roadmap with AI