CMS Migration Checklist for Migration Owners: Redirect Map First

Before you touch the new CMS, crawl the live site, export a full URL inventory, and lock a one-to-one redirect map. Pair that with an analytics and Search Console snapshot, a performance baseline, and a staging validation pass, and you have covered the actions responsible for most migration failures. Expect a 10-15% temporary traffic dip for two to four weeks after launch. Anything worse than that after four weeks means something broke, not that Google is "still figuring it out."

What Should Be In A Pre-Migration Checklist?

Every CMS migration checklist worth using starts with a full crawl of the live site, run through Screaming Frog, Sitebulb, or a comparable crawler. Export URL, status code, canonical tag, title, meta description, H1, and word count for every indexed page. This crawl becomes the mandatory source of truth for redirect mapping later, so treat gaps in it now as debt you will pay for during launch week.

Pull your analytics and Google Search Console exports next. You want the last 12 to 16 months of data to smooth out seasonality, and you're looking specifically for top landing pages by organic sessions, pages with the most referring backlinks, and pages that convert. Those three lists tell you what you cannot afford to break.

With the baseline in hand, define what kind of migration you are actually running:

• CMS swap only, URLs staying identical
• CMS swap plus URL structure changes
• Full redesign with new templates, IA, and possibly new URLs

Each type carries different risk. A CMS-only move with unchanged URLs is comparatively low risk. A redesign that changes URL patterns and templates simultaneously is where most SEO losses originate.

Set your success criteria and rollback triggers before you start, not after something goes wrong:

1. Define acceptable traffic variance (the 10 to 15 percent window mentioned above)
2. Set a Core Web Vitals floor the new site must hit before cutover
3. Assign named owners for crawl, redirects, QA, and launch-day monitoring
4. Build the migration spreadsheet with columns for old URL, new URL, redirect type, owner, and status

Pro Tip: Build the migration spreadsheet as a live, shared document from day one. Teams that build it in the final week almost always miss pages that only backlink data or an old sitemap would have surfaced.

How Do You Map Content And Redirects During A Migration?

Every URL on your crawl needs a decision: keep, merge, or retire. Traffic, backlinks, and conversion value should drive that call, not gut feeling about what "looks outdated."

1. Rank every URL by organic sessions, referring domains, and revenue or lead attribution
2. Manually review your top 50 commercial and highest-traffic pages one by one, since automated rules routinely miss context that protects revenue
3. Merge thin or duplicate content into the strongest surviving page, then redirect the losers to it
4. Retire genuinely dead content with a 410 status, and 301 anything with topical relevance to a parent page

Redirects are the single biggest source of risk in any CMS migration checklist. Build strictly one-to-one mappings, use 301s for anything permanent, and never chain redirects. A hop from old URL to intermediate URL to final URL loses equity at each step and slows crawlers down.

Your redirect spreadsheet needs, at minimum: source URL, destination URL, redirect type, priority tier, backlink count, and QA status. Treat this sheet as the single source of truth, implement your server or CDN redirects to match it exactly, then validate with automated testing rather than spot checks. If you're migrating from a platform like WordPress into a system like Webflow, budget extra time here. Field mapping between WordPress exports and Webflow's collection structure rarely happens cleanly on the first pass.

What Technical SEO Elements Need Parity On The New Site?

Metadata parity is where most migration checklists get sloppy, and where a surprising amount of ranking loss actually originates. Every meta title, meta description, canonical tag, H1, and image alt attribute from your crawl needs to land on the equivalent new page, verified against the spreadsheet, not eyeballed.

Structured data deserves its own line item. Organization schema, BreadcrumbList, and any Article, Product, or FAQ markup you had live needs to be migrated or rebuilt, following current webpage metadata guidance. Losing JSON-LD quietly strips rich results and can drop your click-through rate even when rankings hold steady.

Statistic to watch: teams that skip structured-data parity often see search feature loss (star ratings, FAQ snippets, breadcrumbs) even when core rankings recover within the normal 10 to 15 percent volatility window.

Run through this before sitemap generation:

• Regenerate your XML sitemap against the new URL structure and submit it in Search Console immediately after cutover
• Verify robots.txt does not carry over any staging "disallow all" rule (this happens more often than anyone admits)
• Confirm Open Graph and Twitter Card tags render correctly for your top-shared pages
• If you run multiple languages, check hreflang tags point to live, correct URLs, not staging paths

Pro Tip: Screenshot your staging robots.txt the day before launch. That single file, left unchanged, has quietly deindexed more freshly migrated sites than any redirect error ever has.

What Does A Staging Validation Checklist Cover?

Staging is where you catch problems while they're cheap to fix. Run a full crawl of staging and diff it against your original live-site crawl. A staging-versus-production crawl comparison is the fastest way to catch missing metadata, redirected pages that wrongly return a 200, or canonical mismatches before they go live.

1. Compare status codes, canonical tags, and metadata field by field against the source crawl
2. Test every redirect rule manually on a sample and automatically across the full set
3. Confirm forms, search, login, and any ecommerce checkout flow all function end to end
4. Verify tag manager fires correctly and consent banners behave as expected, since broken tracking or consent handling causes silent analytics data loss
5. Baseline Core Web Vitals on your key templates and check image compression and caching rules carried over

Beyond SEO plumbing, run the experience itself: does the new checkout feel as fast, does navigation still make sense, do mobile layouts hold up under real content instead of placeholder text. A Free UX Audit built for migration contexts covers exactly this kind of functional and conversion smoke test.

Rehearse your rollback in staging at least once. Teams that rehearse rollback steps before cutover resolve launch-day failures faster, because nobody is improvising the process under pressure.

Pro Tip: Write down exactly what triggers a rollback and who has authority to call it, before launch day, not during it. A five-minute argument about authority costs you more traffic than the bug itself.

What Happens On Launch Day?

Lower your DNS TTL 24 to 48 hours ahead so the cutover propagates fast when you flip it. Import your final redirect map, run one last smoke test on staging, and confirm your team knows who to call if something breaks.

1. Flip DNS, then immediately verify a sample of redirects returns the correct status and destination
2. Submit your new sitemap in Search Console and double-check robots.txt allows crawling
3. Test analytics and conversion tracking fire correctly on the live domain, not just staging
4. Log every issue found in a shared triage sheet with severity and owner attached
5. Check Search Console coverage, 404s, and 5xx errors daily for the first 48 to 72 hours

Anything that breaks a core conversion flow or returns 5xx errors at scale gets escalated to your rollback owner immediately. Everything else goes into the hotfix queue, prioritized by traffic and revenue impact.

How Long Should You Monitor After A CMS Migration?

Check Search Console daily for the first 14 days, then shift to weekly reviews once the pattern stabilizes. Pull crawl logs regularly and triage new 404s as they surface, since a spike often points to a redirect gap your spreadsheet missed.

• Track rankings for your top 50 pre-migration queries against the original baseline
• Monitor Core Web Vitals continuously, not just once at launch, since real user data behaves differently than lab tests
• Watch for UX regressions users report even when analytics look fine
• Keep every redirect live for at least 12 months, since search engines and referring sites take time to update links
• Hold formal stakeholder reviews at the 30 day and 90 day marks

A 10 to 15 percent traffic dip for two to four weeks is within normal reindexing volatility. Escalate if that loss persists past four weeks, if 5xx errors show up at scale, or if sitemap coverage in Search Console drops sharply. Any of those three signals means investigate immediately, not "wait and see."

An Agency's View On Reducing Migration Risk

Some agencies run migration-adjacent projects through the same discipline they apply to a Design Sprint or a Rapid MVP build: define the exit criteria before you start, then test against them in a controlled environment before anything touches production. The value isn't the checklist itself. It's having a named owner for every artifact and a rollback procedure that has actually been rehearsed, not just written down.

On one replatform we supported, a staging crawl diff caught a canonical loop on the site's highest-converting category template two days before cutover. Left unresolved, it would have deindexed the page within a week of launch. Catching it in staging cost an afternoon. Catching it in production would have cost a quarter of lost revenue on that page alone.

That gap between "written checklist" and "tested checklist" is where most migrations actually fail.

The Part Of This Checklist Everyone Skips

Most migration guides treat the redirect map as a technical afterthought, something you generate near the end once design and content are locked. That ordering is backwards. The redirect map should exist in draft form before you finalize your new information architecture, because URL structure decisions and redirect complexity are the same decision made twice.

The other place conventional advice falls short is escalation thresholds. Plenty of checklists tell you to "monitor traffic after launch," which is close to useless without a number attached. A 10 to 15 percent dip for two to four weeks is normal. Anything beyond that, past the four week mark, is a signal, not noise. Teams that skip defining this threshold in advance tend to either panic at week one over normal fluctuation, or ignore a real problem for two months because nobody agreed on what "bad" looked like.

If you take one thing from this, prioritize the crawl and the redirect spreadsheet before anything else touches the calendar. Everything downstream, staging QA, launch sequencing, post-launch monitoring, depends on that map being accurate on day one.

How Raw Studio Supports A Managed CMS Migration

Raw Studio is the alternative to running a migration entirely in-house with a stretched internal team. Our approach pairs a research-driven UX/CRO audit with hands-on web development support, using frameworks like our Design Sprint and Rapid MVP to validate template and IA decisions before they're locked into a new CMS.

If you're weighing whether to run this checklist internally or bring in outside help, start with the Free UX Audit. In a migration context, it checks the same things this article covers on staging: conversion flows, template consistency, and where a redesign might be quietly working against the metrics you're trying to protect. Teams with an experienced technical SEO lead and engineering bandwidth can often run this checklist solo. Teams without that bandwidth, or those combining a CMS swap with a full redesign, tend to get more value from a partner who has rehearsed this exact sequence before. See the full range of services or check pricing to figure out which category you fall into.

‍