CMS Migration Guide 2026: Checklist and Best Practices
Let's Build Your Webflow Website!
Partner with experts who understand your vision. Let’s create a converting user experience and build your website for future growth.
CMS migrations have a predictable failure mode. The technical work is scoped correctly. The development team delivers on time. The site launches. Then organic traffic drops 25% and nobody is sure whether it is the redirects, the content model, or something in the new platform's rendering.
It is almost always the redirects. Or the content model. Or both. And both were decided in the planning phase - before a single page was built - which is where most CMS migration plans are weakest.
This guide covers the complete CMS migration process with clear ownership at each phase. It is written for marketing, content, and digital leaders who need to protect SEO equity, maintain content integrity, and improve editorial operations through the migration - not just survive it.
When to Migrate Your CMS
A CMS migration is a significant operational project. It warrants the investment when the current platform is creating constraints that cannot be resolved within the existing architecture.
The specific triggers that justify a migration:
Marketing velocity is blocked by developer dependency. Content editors cannot publish, update, or create new pages without raising a developer ticket. This is not a workflow problem - it is an architectural problem. The CMS does not expose the right editorial controls, or the templates are too rigid to accommodate content variation.
Multi-channel delivery is not possible from the current platform. Content needs to reach a web experience, a mobile app, and third-party systems simultaneously. The current monolithic CMS generates HTML for one channel and cannot expose content as structured data for others.
Performance is not fixable within the current stack. Core Web Vitals failures tied to the rendering architecture of the CMS cannot be resolved without re-architecting the platform. Moving to a headless architecture with SSG/ISR rendering is the correct fix.
The platform is being deprecated or is no longer supported. Legacy platforms with end-of-life timelines require migration regardless of other factors.
Governance requirements cannot be met. Role-based access control, approval workflows, and audit trails at the required granularity are not available in the current platform.
The decision to migrate should not be driven by visual design preferences or by a general sense that the site looks dated. Those problems are solved by a redesign, not a migration. If the content architecture, editorial workflow, and delivery capabilities are functional, a redesign on the existing platform is the lower-risk and lower-cost option.
Types of CMS Migrations
Understanding the type of migration determines the risk profile, the timeline, and the scope of work.
The most common type for B2B SaaS and mid-market organisations in 2026: WordPress to headless (Webflow, Contentful, Sanity, or Storyblok), or Sitecore/AEM to a composable architecture. Both are high-risk migrations that require the full process described in this guide.
Pre-Migration Audit and Content Modeling
70-80% of migration outcomes are determined in this phase. Teams that compress planning to accelerate the build are the ones that spend months recovering from preventable failures.
Site Crawl and SEO Inventory
Before any content model design or platform configuration begins, crawl the current CMS and document the SEO state:
- Complete URL inventory with HTTP status codes
- Organic traffic per URL from analytics (trailing 90 days minimum)
- Keyword positions per URL from Google Search Console
- Inbound backlink count per URL from a link analysis tool
- Meta title, meta description, and canonical tag coverage per URL
- Structured data (schema markup) inventory - what types exist, on which pages
- Core Web Vitals field data per page group from Search Console
Every URL with organic traffic, rankings in positions 1-20, or inbound backlinks is a priority SEO asset. These pages cannot be deleted, restructured, or moved without a documented redirect decision.
Content Audit: Keep, Prune, Merge, or Rewrite
The migration is the correct moment to rationalise the content inventory. Carrying underperforming, outdated, or duplicated content into the new CMS compounds existing problems.
Keep as-is: Pages ranking in positions 1-20, generating organic traffic, or carrying inbound backlinks. Migrate with parity.
Update and keep: Pages ranking but underperforming on conversion. Migrate and schedule content improvement post-launch.
Merge: Multiple pages targeting the same query with diluted traffic. Consolidate to one URL, redirect the others.
Prune: Pages with no traffic, no rankings, no backlinks, and no conversion value. Remove and redirect to the nearest relevant category.
Marketing owns these decisions. They cannot be delegated to a developer or made by default during the build.
Content Modeling for the New CMS
A content model is the schema of content types and fields that defines how content is stored and structured in the new CMS. It determines:
- What editorial fields marketing teams can populate for each page type
- Which SEO fields (meta title, description, OG image, canonical override, noindex flag) are available per content type
- How content relationships are structured - blog posts to authors, products to categories, resources to topics
- What the editorial interface looks like for each content type
The content model must be designed before the build begins - not during it. A content model built to match the current CMS structure rather than the new platform's capabilities creates technical debt on day one.
The SEO fields every content type needs:
- Meta title (plain text, character-limited, required)
- Meta description (plain text, character-limited, required)
- OG image (media field, required for content shared socially)
- Canonical URL override (optional - for cases where the default URL is not the canonical version)
- noindex flag (boolean - allows marketing to exclude pages from indexing without developer involvement)
Marketing should review and approve the content model before development begins. If the content team cannot see how they will publish and manage content in the new system from the model specification, the model is not ready.
The 301 Redirect Map
The redirect map is a spreadsheet with one row per current URL. Every URL in the inventory gets a destination. The columns:
- Current URL
- HTTP status code
- Organic sessions (trailing 90 days)
- Ranking keywords (top 3-5)
- Inbound backlink count
- Content decision (keep/prune/merge)
- Destination URL on the new platform
- Notes
Rules:
- Pages with traffic, rankings, or backlinks get a 1:1 redirect to the most thematically relevant new URL
- Never redirect traffic-bearing pages to the homepage
- Pages being merged each redirect to the merged destination
- Pages being pruned redirect to the nearest relevant category
This map is a Phase 1 deliverable. It is reviewed and approved by the SEO and marketing teams before development begins. A redirect map built during or after the build is a risk, not a plan.
SEO and Redirect Strategy
Protecting Organic Equity Through a CMS Migration
The specific technical steps that determine whether a CMS migration retains or loses organic traffic:
Redirect implementation. Every redirect in the map must be implemented as a 301 (permanent redirect). A 302 (temporary) delays the transfer of ranking signals and signals to Google that the original URL may return. After implementation on the new platform, crawl the staging environment to verify every redirect returns a 301 status code with the correct destination.
Redirect chains. A chain occurs when URL A redirects to URL B which redirects to URL C. Each step in the chain reduces the equity transferred and adds latency. Resolve all chains to direct 1:1 redirects before launch.
Meta data parity. Every priority page must have its meta title and meta description migrated correctly - not left as platform defaults. Run a crawl of staging to confirm meta data is present and not defaulting to template values on any priority page.
Schema markup migration. Structured data must be reimplemented in the new platform and validated with Google's Rich Results Test before launch. Schema dropped in a CMS migration reduces rich result eligibility and AI citation potential. Include schema validation as a binary pass/fail criterion in the pre-launch QA checklist.
Canonical tag configuration. Every public page needs a self-referencing canonical tag pointing to its production URL. Verify canonical configuration per page type in pre-launch QA.
The Pre-Launch SEO Checklist
Core Web Vitals targets: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. Source: Google web.dev/vitals - verify current thresholds before launch.
Data and Content Migration
Structured Data Migration
Content migration from one CMS to another requires a data transformation layer - content stored in the source CMS schema must be mapped to the destination CMS content model. The transformation is rarely 1:1.
Field mapping. Each field in the source content type maps to a field in the destination content type. Rich text fields, relationship fields, and media references require specific transformation logic. A content entry with 20 fields may require 20 separate mapping decisions.
Content with embedded formatting. WordPress blog posts with shortcodes, Sitecore components embedded in rich text, or Drupal fields with platform-specific markup require transformation to the new platform's content format. This work is proportional to the volume and complexity of existing content.
Media and asset migration. Images, PDFs, and other media assets must be migrated to the new DAM or media library with their metadata intact. Image alt text is a content field that is frequently lost in asset migrations - verify alt text migration as an explicit quality check.
Content relationships. Blog posts linked to author profiles, products linked to categories, resources tagged to topics - each relationship must be preserved in the new content model. Relationship migration requires that the referenced content types are migrated first.
Maintaining Content Integrity
Quality checks for migrated content:
- Sample audit: manually verify 10-20% of migrated entries against source content for field accuracy, relationship integrity, and formatting correctness
- Image verification: confirm all images load correctly and alt text is present
- Internal link audit: check that internal links within migrated content reference the new URLs, not the old ones
- Rich text verification: confirm embedded content (videos, tables, code blocks) has migrated correctly
- SEO field verification: confirm meta titles, descriptions, and OG images are populated on all migrated entries
Launch and Post-Launch Monitoring
Launch Day Sequence
Time the launch for midweek, mid-morning in the primary timezone. Within the first two hours:
- Confirm the production CMS is live and serving content correctly
- Confirm staging is no longer publicly accessible
- Crawl a sample of 20-30 priority URLs and confirm redirect status codes
- Confirm the production robots.txt allows indexing
- Submit the updated sitemap in Google Search Console
- For domain migrations, use the Change of Address tool in Search Console
- Verify GA4 is tracking live sessions and conversion events
- Complete a test user journey end-to-end on the production environment
Post-Launch Monitoring Cadence
A 5-15% temporary dip in the first two weeks is normal. A problem is sessions down more than 20% after two weeks with no recovery trend. Escalate at that threshold - do not wait for day 60.
Ownership and Governance
RACI for CMS Migration Stakeholders
The content team's involvement does not end when the build begins. Content migration quality checks, SEO field verification, and editorial workflow testing in staging all require active content team participation before launch.
Post-Migration Content Velocity
The operational benefit of a CMS migration - faster publishing, reduced developer dependency, better governance - is only realised if the new CMS is configured correctly for editorial use.
The measure of content velocity post-migration: how long does it take to publish a new landing page without developer involvement? If the answer is longer than it was on the previous platform, the migration has not achieved its operational objective.
Benchmark this before the migration. Measure it at 30, 60, and 90 days post-launch. If content velocity has not improved, identify whether the bottleneck is the platform configuration, the editorial workflow, or the governance model - and fix the correct constraint.
Work with Shadow Digital
CMS migrations that fail do so for predictable reasons - redirect maps built too late, content models designed without editorial input, SEO fields not included in the content type specification. None of these are technical problems. They are planning problems.
Shadow Digital approaches CMS migrations with the redirect map as a Phase 1 deliverable, the content model reviewed and approved by marketing before development begins, and post-launch monitoring built into every project scope.
For teams considering a move to Webflow specifically, Webflow migration covers the platform-specific process. For the SEO layer of any CMS migration, the website redesign SEO guide covers the technical steps in detail. For the broader website migration process, the website migration guide for marketers covers the full ownership and risk framework.
Book a strategy call to talk through your CMS migration scope. Or see our work to understand the standard of process we apply.
A Note on Sources
Core Web Vitals thresholds (LCP under 2.5 s, INP under 200 ms, CLS under 0.1) are sourced from Google web.dev Core Web Vitals documentation - verify current thresholds at web.dev/vitals. Technical guidance on 301 redirects and Change of Address is based on Google Search Central documentation at developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes and support.google.com/webmasters/answer/9370220. Timeline estimates are indicative ranges for mid-market B2B organisations - actual timelines depend on content volume, integration complexity, and data quality. All figures should be verified against current guidance at time of execution.
Frequently Asked Questions
How Long Does a CMS Migration Take?
A platform swap with URL restructure typically runs 18-28 weeks for a mid-size B2B site. A monolith-to-headless migration on the same domain runs 20-32 weeks. Migrations involving a domain change run 24-40 weeks. The planning phase alone - crawl, content audit, content modeling, and redirect map - should not be compressed below 4-6 weeks for any migration above low complexity.
How Do I Migrate a CMS Without Losing SEO Rankings?
Build the redirect map before development begins, mapping every indexed URL with traffic, rankings, or backlinks to a relevant destination. Migrate meta data with parity on all priority pages. Reimplement schema markup and validate it before launch. Block staging from indexing throughout the build. Submit the updated sitemap in Google Search Console on launch day. Monitor Search Console for crawl errors in the first week. Organisations that follow this process retain 90-95% of organic sessions within 30 days.
What Is the Difference Between a CMS Migration and a Website Redesign?
A redesign changes the visual design, content strategy, and potentially the IA of a site - it may or may not involve a CMS change. A CMS migration changes the platform storing and delivering content - it may or may not involve a visual redesign. The two often happen simultaneously, which compounds both the complexity and the risk. When they do, treat them as the same project with a single shared redirect map, content model, and pre-launch QA process.
Should I Clean Up Content Before or During the Migration?
Before. The content audit and keep/prune/merge decisions should be completed in the planning phase, before the content model is designed and before any migration scripts are written. Cleaning up content during the build phase means migration scripts are written against content that then changes, adding rework. Cleaning up after launch means underperforming content has been carried into the new platform unnecessarily.
How Do I Handle Content That Does Not Map Cleanly to the New CMS?
Some content - particularly rich text with embedded platform-specific components, shortcodes, or inline formatting - does not transform cleanly between CMS platforms. The options are: custom transformation scripts to convert the format, manual re-entry in the new platform, or treating affected pages as net-new content creation rather than migration. Identify these content types in the planning phase and scope the transformation work explicitly before development begins.
When Should a CMS Migration Be Handled by an Agency vs. an Internal Team?
Internal teams can manage low-complexity migrations - same-platform version upgrades, small sites with minimal integrations, and domain migrations with stable URL structures - if they have the technical capability to build and verify a redirect map. Agency involvement is appropriate for any migration involving URL restructuring, monolith-to-headless architecture change, complex data transformation, or significant organic traffic at risk. The cost of a poorly executed migration almost always exceeds the cost of specialist involvement.
What Success Metrics Should I Set for a CMS Migration?
Beyond "no downtime" - which is a minimum standard, not a success metric: organic sessions within 5% of pre-migration baseline within 30 days; 90% of target keyword positions maintained within 30 days; demo/trial conversion rates at or above pre-migration baseline within 60 days; time to publish a new landing page without developer involvement (should be lower than pre-migration); number of content updates requiring developer tickets in the first 30 days (should be lower than pre-migration).
