Website Migration Plan: 12-Week Template With Redirects and Cutover

9 min read ยท 2026-10-25

A website migration plan is the step-by-step plan for moving a site to a new platform, domain, URL structure or design without losing traffic, rankings, leads or tracking. It covers the URL inventory, a redirect map, the build and content move, testing, a cutover runbook for launch day, and a monitoring period after go-live.

The template below runs over 12 weeks for a marketing or company site with a few hundred to a few thousand pages, moving to a new CMS. Most migrations that lose traffic fail on the same few things: missing redirects, content dropped without a decision, tracking not tested and nobody watching the numbers after launch. Each of those has its own milestone in this plan.

The roadmap at a glance

Goal: The new site is live with every old URL either redirected or retired on purpose, tracking verified, and organic traffic and leads back to their baseline within the agreed monitoring period. Duration: 12 weeks plus 4 weeks of monitoring

  1. Scope and baseline (Weeks 1-2)

    Agree on what is changing and record how the current site performs.

    • Write down the type of migration: platform, domain, URL structure, design, hosting, or a mix. Each one adds risk.
    • Pick a launch window away from peak sales periods, campaigns and code freezes.
    • Export a baseline from Google Search Console and your analytics tool: clicks, top pages, top queries, conversions and leads by page.
    • Record current rankings for priority keywords and page speed for key templates.
    • Name an owner for each workstream and agree on a go or no-go owner for launch.

    Milestone: A one-page migration brief with scope, launch window, owners and baseline numbers, signed off by the marketing lead and IT.

  2. Inventory and redirect map (Weeks 2-5)

    Know every URL on the old site and decide what happens to each one.

    • Crawl the current site and combine the list with URLs from the XML sitemap, Search Console and analytics.
    • Add traffic, backlinks and conversions to each URL so you can see which ones matter most.
    • Decide for each URL: keep, merge, rewrite or retire.
    • Build a redirect map in a spreadsheet with old URL, new URL and redirect type, using 301 redirects for permanent moves.
    • Have the SEO lead and content owners review the top pages by traffic and links one by one.

    Milestone: A redirect map covering every old URL with a decision and target, approved by the SEO lead.

  3. Build and content move (Weeks 4-9)

    Build the new site and move content without losing what makes pages rank.

    • Build templates with title tags, meta descriptions, headings, canonical tags and structured data carried over or improved.
    • Move content, keeping body text, images with alt text and internal links on high-value pages.
    • Rebuild forms and connect them to the CRM or marketing automation tool.
    • Set up analytics, tag manager, consent banner and conversion events on the staging site.
    • Block the staging site from search engines with authentication.

    Milestone: All in-scope pages built on staging with content, metadata, forms and tracking in place.

  4. Test (Weeks 9-11)

    Prove the new site works before any real user sees it.

    • Crawl staging and compare titles, headings, canonicals, status codes and internal links with the old site.
    • Test every redirect in the map on staging and fix chains and loops.
    • Submit each form and confirm the lead reaches the CRM with the right source data.
    • Check conversion events fire in analytics, and test the consent banner.
    • Run page speed and mobile checks on main templates, and a basic accessibility check.

    Milestone: Test report with zero open critical issues, signed by the QA owner, SEO lead and marketing ops.

  5. Cutover (Week 12)

    Launch the new site following a written runbook, with a rollback plan ready.

    • Freeze content changes on the old site a few days before launch.
    • Follow the cutover runbook: DNS or hosting switch, redirects live, remove staging protection and noindex tags, submit the new XML sitemap.
    • For a domain change, use the change of address tool in Search Console after redirects are live.
    • Run the post-launch checklist within the first hours: redirects, forms, tracking, robots.txt, SSL and key pages.
    • Keep the team on standby for the rest of launch day with a clear rollback decision point.

    Milestone: New site live, post-launch checklist passed and go-live confirmed by the go or no-go owner.

  6. Monitor and fix (Weeks 13-16)

    Catch problems early and bring traffic and leads back to baseline.

    • Check Search Console daily in the first week for crawl errors, 404s and indexing changes.
    • Compare organic clicks, rankings and leads with the baseline every week.
    • Fix broken redirects and 404s on pages that still get visits or have backlinks.
    • Update important backlinks and your own profiles, ads and emails to point to the new URLs.
    • Keep the redirects in place long term, and hold a review at week 16.

    Milestone: Week 16 review shows traffic and leads at or near baseline, with all known issues closed or scheduled.

Who owns what

A website migration touches marketing, SEO, development, IT and sales operations. Give each area one owner and make one person responsible for the go or no-go decision.

Hold a weekly migration meeting from week 1 and a daily stand-up in the last two weeks before launch and the first week after.

  • Project lead: owns the plan, the timeline, the risk log and the weekly meeting.
  • SEO lead: owns the baseline, URL inventory, redirect map and post-launch monitoring.
  • Content lead: decides what to keep, merge, rewrite or retire, and runs the content move.
  • Development lead: builds templates, implements redirects and runs the technical cutover.
  • IT or hosting owner: handles DNS, SSL certificates, hosting and access.
  • Marketing ops or analytics lead: owns tracking, forms, CRM connections and conversion tests.
  • Go or no-go owner (often the marketing director): approves launch and any rollback.

How to build the redirect map

The redirect map is the most important document in the migration. In Excel or Google Sheets, create one row per old URL with these columns: old URL, page type, monthly organic clicks, number of linking domains, conversions, decision (keep, merge, rewrite, retire), new URL, redirect type, owner and test status.

Sort by traffic and links so the pages that matter most are reviewed first. Redirect each old URL to the most relevant new page, not to the home page. Retire a page only on purpose, and decide whether it should return a 404 or 410, or redirect to a close match. Before launch, test every row on staging and record the result in the test status column.

Example: a migration from a legacy CMS to a new one

Picture a B2B software company with 1,400 pages moving its site from a legacy CMS to a new one, with a new design and a cleaner URL structure. The domain stays the same. Here is how the plan could look.

The main risk here is the new URL structure, so most of the effort goes into the redirect map and testing.

  • Weeks 1-2 (owner: project lead and SEO lead): baseline exported, launch set for a quiet month after a major event. Milestone: brief signed off.
  • Weeks 2-5 (owner: SEO and content leads): 1,400 URLs crawled, 300 old blog posts merged into 60 updated guides, 90 retired. Milestone: redirect map approved.
  • Weeks 4-9 (owner: development lead): 14 templates built, content moved, forms connected to the CRM. Milestone: staging complete.
  • Weeks 9-11 (owner: QA and marketing ops): all redirects tested, 6 form issues fixed, conversion events checked. Milestone: zero critical issues.
  • Week 12 (owner: development lead): cutover on a Tuesday morning following the runbook. Milestone: post-launch checklist passed.
  • Weeks 13-16 (owner: SEO lead): 404s fixed weekly, organic clicks tracked against baseline. Milestone: week 16 review with leadership.

The cutover runbook

A cutover runbook is a timed list of every action on launch day, with an owner and a check for each. Write it in week 10, rehearse it on staging and share it with everyone involved. Launch early in the week and early in the day, so the full team is available to fix issues.

Include a rollback plan with a clear trigger, such as forms not reaching the CRM or a large share of redirects failing, and the steps to point traffic back to the old site.

  • Content freeze confirmed on the old site.
  • Backups of the old site and database taken.
  • DNS or hosting switch made, SSL certificate valid.
  • Redirect rules deployed and a sample of top URLs tested live.
  • Staging protection, noindex tags and blocking robots.txt rules removed.
  • New XML sitemap submitted in Search Console.
  • Forms, conversion events and consent banner tested in production.
  • Go-live confirmed in the team channel by the go or no-go owner.

How to present the plan to leadership

Leaders care about two things: when the new site goes live and what risk it carries for traffic and leads. Put the plan on one slide with the six phases as bars across 16 weeks, the launch date and the go or no-go checkpoint. Add one line for the baseline numbers you will protect.

Be honest that organic traffic can dip for a few weeks after a migration, even when it is done well, and explain how you will monitor and respond. Leave crawl reports and redirect details out of the main deck. Bring them only if asked.

Metrics to watch after launch

Compare every metric with the baseline from week 1, and look at trends over several weeks rather than single days. Report weekly to the marketing lead for the first month.

If a metric drops sharply, check redirects, indexing and tracking before deciding that the content or design is the cause.

  • Organic clicks and impressions: from Search Console, compared with the same period before launch.
  • Indexed pages: from the page indexing report in Search Console, watching for unexpected drops.
  • 404 errors and redirect issues: from Search Console and a weekly crawl.
  • Rankings for priority keywords: tracked weekly against the baseline list.
  • Leads and conversions: form submissions and conversion events, checked against CRM records.
  • Page speed: on main templates, compared with the old site.

Common mistakes to avoid

  • Skipping the URL inventory leaves pages without redirects, so crawl the site and combine the crawl with Search Console and analytics data.
  • Redirecting old pages to the home page loses relevance and rankings, so map each old URL to its closest new page.
  • Leaving the noindex tag or a blocking robots.txt rule from staging on the live site removes it from search, so check both in the cutover runbook.
  • Testing tracking after launch means lost data and missed leads, so test every form and conversion event on staging.
  • Launching on a Friday or just before a campaign leaves no one to fix problems, so launch early in the week in a quiet period.
  • Removing redirects a few months after launch breaks links and loses value, so keep them in place long term.

Frequently asked questions

What should a website migration plan include?

It should include the scope, a traffic and lead baseline, a URL inventory, a redirect map, build and content tasks, a test plan, a cutover runbook with a rollback plan, and a monitoring period. Each phase needs an owner and a milestone.

How long does a website migration take?

It depends on the size of the site and the type of change. A small site moving hosts can take a few weeks. A larger site moving to a new CMS with new URLs often takes about three months, plus a monitoring period after launch.

Will a website migration hurt SEO?

Traffic can dip for a while after a migration, especially when URLs or the domain change. A complete redirect map, careful testing and close monitoring after launch reduce the risk and help traffic recover.

How long should you keep 301 redirects after a migration?

Keep them as long as you can. Google advises keeping redirects for at least a year, and many teams keep them permanently. Removing them breaks old links and bookmarks.

What is a website migration checklist?

It is a list of tasks to complete before, during and after launch, such as crawling the old site, building the redirect map, testing forms and tracking, and submitting the new sitemap. The cutover runbook is the launch-day part of that checklist.

Generate this roadmap with AI