.jpg)
A CMS migration that goes wrong does not announce itself until traffic drops. By the time you see the decline in Google Search Console, weeks of ranking signals have already been lost. The good news: every common migration failure is preventable with the right preparation.
This guide covers the complete process for migrating a CMS without losing organic traffic - from pre-migration audit through post-launch monitoring. It is written for marketing teams, SEOs, and agencies managing the transition, with 2026-specific considerations around Core Web Vitals, AI crawling signals, and modern platform architectures.
Why migrate your CMS? Benefits and risks
The most common reasons teams migrate CMS platforms in 2026: WordPress maintenance overhead and security liability, moving to a headless architecture for performance, consolidating fragmented content stacks, or switching to a platform that gives marketing teams more autonomy without developer dependency.
The benefits are real. A well-executed migration to a modern platform typically delivers faster page speed, cleaner HTML output, better Core Web Vitals scores, and a lower maintenance burden. The risk is in the transition itself, not the destination.
Risk severity based on observed migration outcomes and Google Search Central documentation on site migrations (developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes).
Pre-migration planning
The pre-migration phase determines whether the launch goes smoothly. Teams that skip it spend weeks post-launch chasing issues that a two-day audit would have prevented.
Content inventory and SEO audit
Step 1: crawl the existing site. Run Screaming Frog on the current domain. Export every URL, status code, title tag, meta description, H1, canonical tag, and internal link count. This is your migration source of truth.
Step 2: identify top-performing pages. Pull organic traffic data from Google Search Console for the past 90 days. Export your top 50 pages by sessions and your top 50 by impressions. These pages carry the most ranking equity and need the most careful treatment.
Step 3: document URL structure. Record your current URL patterns (e.g., /blog/post-slug, /category/subcategory/slug). Determine whether the new platform will preserve this structure or require changes. URL changes require 301 redirects. No exceptions.
Step 4: audit structured data. Run Google's Rich Results Test on representative pages for each schema type you use (Article, Product, FAQ, BreadcrumbList). Document which types are in place and where they live in the code. You will need to rebuild these on the new platform.
Step 5: baseline your performance metrics. Record Core Web Vitals scores (LCP, CLS, INP) for your top pages using Google Search Console's Core Web Vitals report and PageSpeed Insights. These are your post-migration benchmarks.
Define goals, scope, and team
Before any migration work begins, define in writing:
• Which pages are moving as-is, which are being updated, and which are being cut
• Who owns SEO sign-off at each stage (pre-launch checklist cannot be bypassed)
• The go-live date, the QA window before it, and the monitoring period after it
• Whether the URL structure is changing and the full redirect map owner
• The budget for migration tools, QA, and any specialist support
Step-by-step migration process
URL mapping and redirects
This is the highest-risk step in any CMS migration. Unconfigured or incorrect redirects cause direct ranking loss because Google's link equity for the old URL does not transfer to the new one.
Build the redirect map before any other migration work. Create a spreadsheet with the old URL in column A and the new URL in column B. Every URL that exists in the current crawl needs a row. Redirects should be:
• 301 (permanent), not 302 (temporary). A 302 does not pass ranking signals
• Direct, not chained. A redirect that goes A → B → C loses equity at each hop
• Complete. A redirect map with 95% coverage means 5% of your link equity disappears
Configure redirects on the new platform before pointing your domain. Google Search Central recommends implementing redirects server-side and testing with a crawler before launch: developers.google.com/search/docs/crawling-indexing/301-redirects.
Content transfer and optimization
Export content from your current CMS in a structured format that maps to your new platform's data model. For most migrations this means CSV or JSON export with all fields: body content, title, meta title, meta description, slug, canonical URL, and any custom fields.
• Transfer metadata explicitly. Do not assume the new CMS will inherit titles and descriptions from your content
• Re-upload images from original source files wherever possible. Re-compression from already-compressed images degrades quality
• Verify rich text formatting in the new editor. Bold, headings, and list formatting often needs manual correction after import
• Preserve internal links by updating hrefs to the new URL structure as part of content migration, not as a post-launch cleanup task
Technical SEO during migration
Canonical tags. Every page should have a self-referencing canonical tag. If the new platform generates URLs with query parameters for filters or pagination, ensure canonical tags point to the clean version.
XML sitemap. Generate a new sitemap on the new platform and verify it includes all migrated pages and excludes any pages intentionally removed. Do not submit the old sitemap to Google Search Console post-launch.
robots.txt. Confirm the new platform's robots.txt is not blocking any pages you want indexed. A misconfigured robots.txt that disallows crawling of the new domain is one of the most damaging (and most common) migration errors.
Hreflang. If the site is multi-locale, verify hreflang tags are present and correctly configured on the new platform for every locale and their alternates.
Page speed. Run PageSpeed Insights on the new platform in staging before launch. A migration that improves content but degrades speed hurts SEO even with perfect redirect implementation.
Core Web Vitals. Specifically check LCP (largest contentful paint) on key landing pages, and CLS (cumulative layout shift) on pages with dynamic content or ad placements. Google uses these as ranking signals.
Post-launch monitoring and optimization
The 30 days after launch are higher-risk than the launch itself. Google re-crawls the new domain, processes redirects, and adjusts rankings. What you monitor in this window determines how quickly you recover from any transition dip.
1. Submit the new sitemap to Google Search Console within one hour of launch
2. Run Screaming Frog on the live domain within 24 hours. Check for 404s, redirect chains, and missing meta tags
3. Check Google Search Console daily for the first two weeks: coverage errors, crawl anomalies, and any increase in 4xx status codes
4. Monitor organic traffic in GA4 week-over-week. A 10-20% dip in the first two weeks is normal. A sustained drop beyond four weeks warrants investigation
5. Compare keyword rankings for your top 20 pages before and after launch using Ahrefs or SEMrush
6. Verify Core Web Vitals scores in Google Search Console's CWV report after 28 days of data accumulates
If specific high-value pages lose rankings post-launch, check in order: redirect status (is the 301 returning correctly?), canonical tag (is it pointing to itself?), content completeness (did all content transfer?), and internal links (are pages being linked from the site?).
Tools and best practices
For 2026 migrations specifically: AI crawlers (GPTBot, ClaudeBot, Bingbot AI) are now a meaningful source of traffic for content-heavy sites. Check your robots.txt to confirm whether you want to allow or disallow these crawlers. Some platforms block them by default. Make the decision deliberately.
Common pitfalls and how to avoid them
Pitfall 1: treating redirects as a post-launch task. Redirects must be in place before the domain is pointed to the new platform. There is no safe way to launch first and redirect later.
Pitfall 2: launching without submitting the new sitemap. Google will eventually find the new site. Submitting the sitemap accelerates that process by days or weeks, which matters for time-sensitive content.
Pitfall 3: copying metadata from the old site without reviewing it. A migration is an opportunity to fix thin, missing, or duplicate meta titles and descriptions. Running the migration without reviewing metadata means inheriting its problems on a new platform.
Pitfall 4: not setting up Google Search Console for the new property before launch. GSC historical data does not migrate. Setting up the new property early captures data from day one of the new site.
Pitfall 5: assuming staging environment performance reflects live performance. CDN, caching, and server response times differ between staging and production. Always run performance benchmarks on the live domain after launch.
Pitfall 6: migrating a site that has unresolved technical SEO issues. Existing crawl errors, duplicate content, and broken internal links do not disappear during migration. Audit and fix them before moving platforms, not after.
Typical timelines by site size
When to hire expert support
DIY migration works for small sites (under 50 pages) with low organic traffic where a ranking drop has limited business impact. For anything larger, the cost of a migration error measured in lost organic traffic over 3-6 months routinely exceeds the cost of specialist support.
Hire a specialist when:
• The site has more than 500 pages and URL structure is changing
• Organic search drives more than 30% of your leads or revenue
• The migration involves a headless architecture with complex routing
• The timeline is tight and there is no internal resource with migration experience
• The current site has existing technical SEO debt that needs to be resolved during the migration
For migrations to or involving Webflow, a certified Webflow agency with documented SEO migration experience is worth the investment. The technical SEO steps - redirect configuration, sitemap submission, canonical setup, and Core Web Vitals optimisation - are specialised enough that a generalist web agency without this background regularly misses them.
Work with Belt Creative
Belt Creative handles CMS migrations for marketing teams that cannot afford to lose organic traffic. We plan the redirect map, manage the technical SEO setup, and monitor the first 30 days post-launch so nothing falls through the cracks.
See our work for migration case studies, or get in touch to talk through your project before you start.
A note on sources
Google Search Central site migration documentation: developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes. Google Search Central 301 redirects guide: developers.google.com/search/docs/crawling-indexing/301-redirects. Tool pricing verified at time of writing; confirm current pricing with vendors before purchase. Timeline estimates based on typical agency migration experience; individual projects vary.
Frequently asked questions
How long does a CMS migration take?
Between 2 weeks and 9 months depending on site size. A small site under 50 pages can migrate in 2-4 weeks. A medium site (50-500 pages) typically takes 4-8 weeks. Large sites (500-2,000 pages) run 8-16 weeks. Enterprise migrations with thousands of pages, multi-locale, and complex redirect requirements commonly take 4-9 months.
What are the biggest SEO risks in a CMS migration?
The three highest-impact risks are: (1) URL changes without 301 redirects, which cause direct ranking loss; (2) missing or incorrect metadata on the new platform, which drops CTR and rankings; and (3) a misconfigured robots.txt that blocks Googlebot from crawling the new site. All three are preventable with a thorough pre-launch checklist.
Do I need 301 redirects if my URLs are not changing?
If URLs are identical on the new platform, 301 redirects are not needed. However, verify this at the server level, not just visually. Some platforms append trailing slashes, change www/non-www handling, or alter HTTP/HTTPS behaviour in ways that technically create new URLs. Run a crawler after launch to confirm all old URLs resolve correctly.
Which tools should I use for a CMS migration?
Screaming Frog for pre and post-migration crawls, Ahrefs or SEMrush for keyword and ranking baselines, Google Search Console for indexing and Core Web Vitals monitoring, and Google PageSpeed Insights for performance benchmarking. These four tools cover the majority of migration SEO needs without additional cost at small to medium scale.
How do I handle redirects for a headless CMS migration?
Redirects in a headless architecture are typically managed at the CDN layer (Vercel, Netlify, Cloudflare) or in the routing configuration of your front-end framework, not in the CMS itself. Define redirect rules before the deployment goes live, test them in staging, and verify with a crawler after launch. The SEO principles are identical to a traditional CMS migration; only the technical implementation differs.
Will my Core Web Vitals improve after migrating?
Usually yes, particularly when migrating from a plugin-heavy WordPress setup to a modern platform with clean output and CDN-hosted assets. The improvement is not automatic: heavy animations, large unoptimised images, and third-party script bloat will degrade Core Web Vitals on any platform. Benchmark before and after, and treat any regression as a post-launch priority fix.
How do I handle paginated content during a CMS migration?
Paginated pages (/blog/page/2, /blog/page/3) need redirects if the URL structure changes. If you are consolidating pagination (moving from paginated archives to a single infinite-scroll page), implement 301 redirects from all paginated URLs to the main archive page. Verify that the main page is indexable and that canonical tags are configured correctly.
How much does a CMS migration cost?
DIY migrations cost primarily in time: 40-120 hours for a small to medium site. Agency-managed migrations range from $5,000-$15,000 for small sites, $15,000-$40,000 for medium sites with significant content, and $50,000-$150,000+ for large enterprise migrations with complex redirect mapping and multi-locale requirements. The cost of a poorly executed migration, measured in organic traffic loss over 3-6 months, regularly exceeds these figures for high-traffic sites.
Can I migrate my CMS in phases?
Yes, and for large sites it is often the safer approach. Migrate high-priority sections first (homepage, key landing pages, top blog content), monitor the SEO impact, and migrate remaining sections iteratively. Running the old and new platforms in parallel during a phased migration requires careful canonical and redirect management to avoid sending conflicting signals to Google.
What should I monitor in the first 30 days after a CMS migration?
Daily: Google Search Console for coverage errors and crawl anomalies. Weekly: organic traffic in GA4 compared to the same period before migration. Weekly: keyword rankings for your top 20 pages. Monthly: Core Web Vitals report in Google Search Console after 28 days of data. Any sustained traffic drop beyond four weeks on specific pages warrants a redirect audit and content completeness check on those pages.
Sources: Google Search Central (developers.google.com/search); Screaming Frog (screamingfrog.co.uk); Google PageSpeed Insights (pagespeed.web.dev). Verify all tool pricing and availability at time of purchase.
