A CMS migration moves content, media, URLs, metadata and integrations from one content management system to another. The SEO work is what decides whether rankings survive it.
Work in phases: plan, inventory every URL and map its redirect, build the new content model, test on a protected staging site, cut over, then check on day one, in week one and again after one to two months.
What breaks most often: URLs missing from the inventory, redirects that chain or point to the wrong page, and a noindex or robots.txt block left over from staging.
Change one thing at a time: Google advises against combining a site move with a redesign or a domain change in one step. Use permanent (301 or 308) redirects and keep them for at least a year.
Plan the cutover: a short content freeze, a final delta run, and a rollback you can trigger if the launch goes wrong.
What Is a CMS Migration?
A CMS (content management system) migration moves all content, data and functionality from one CMS to another: posts and pages, media, URLs and redirects, metadata, users and roles, and the integrations around them, such as forms, search and the CRM. It is a website migration in which the platform changes, and done right it improves load times, workflows and editing without losing rankings.
When a CMS Migration Makes Sense
Teams usually migrate when the current CMS slows the site down, blocks new features or becomes a security and maintenance burden. Localcoin, for example, moved its website off WordPress to Next.js with a headless CMS; in the client’s words, the result was “a lighter website, increased speed, and better SEO ranking”.
Localcoin
Migrating WordPress Website to Jamstack for the financial technology company.
Newer CMS platforms often come with stronger security features, which can better protect the website from vulnerabilities and cyber threats.
It opens the way to a redesign that better fits your current marketing goals, best done as a separate step after the migration.
Risks of CMS Migration
The main risk of a CMS migration is lost search traffic: old URLs that return 404s or redirect to the wrong page lose their rankings and links. The other risks are lost content, edits lost at cutover, integrations that stop working and editors who cannot publish. Each one has a step in the checklist below.
Broken URL mapping: old URLs that 404 or redirect to the wrong page lose their rankings and links, and break navigation for users.
Lost rankings: missing metadata, canonicals or structured data, or a staging block left in place, can push pages down or out of the index.
Lost content: posts, comments, media or fields that the import skips or truncates.
Downtime and lost edits at cutover: content published on the old site after the last export is gone unless you freeze edits or run a final delta migration.
Integrations that quietly stop working: forms, site search, gated content and CRM connections often depended on plugins and need rebuilding.
Editors blocked: a new model without previews, roles and training stalls publishing for weeks.
Image and file URLs: images ranking in image search and PDFs linked from other sites need redirects too.
Choose a traditional CMS such as WordPress or Drupal when a small team needs built-in templates and no developers; choose a headless CMS when content has to reach several channels, the site must be fast at scale, and a development team can own the front end.
The checklist runs in six phases. Each phase below opens with its checklist items, so you can copy them into your project tracker, and then explains how to do them.
Phase 1: Plan
Define the goal, the scope and what will not change (keep content and URLs stable where you can).
Assign an owner for SEO, content, development and QA.
Pick a low-traffic window for the cutover from your analytics.
Decide: all at once or section by section.
Audit the content: keep, merge, rewrite or retire each page, and record the decision in the inventory.
A common challenge during CMS migration is involving SEO specialists too late, which can lead to preventable issues like traffic loss or SEO damage. To ensure a smooth transition, you need a migration plan with assigned responsibilities and the right tools.
Content Audit
Decide what moves before anything moves. For each page, mark it keep, merge, rewrite or retire: pages with traffic, links or conversions stay; thin or outdated pages can be merged or retired, each with a redirect to the closest relevant page. Keep the rest unchanged during the migration, so any movement in rankings can be traced to the platform change rather than to new content.
Roles and Responsibilities
A project manager should document every element the migration will change, because even small changes can move rankings, and brief any external developers on them. Each team member needs a clear owner role, so nothing falls between SEO, content and development.
Timing and Change Control
Knowing the periods of lowest traffic on your site can help reduce disruptions during the migration. These optimal hours will vary based on your industry, business operations, and geographic region. Use tools like Google Analytics to determine the best time of day to carry out the process, minimizing the effect on users and potential traffic loss.
Google’s site-move guidance adds one rule worth putting in the plan: change one thing at a time. If you are also changing the domain or the design, sequence those steps rather than shipping them together, so you can tell what caused any drop.
Questions for the Planning Stage
Is the scope agreed, including what will not change?
Who signs off SEO before launch?
Is the cutover window agreed with marketing and sales?
Who decides on a rollback?
Is the migration approach incremental or a full rebuild?
Phase 2: Inventory and Redirect Map
Crawl the old site and back up all data.
Build the URL list from several sources: sitemap, crawl, Search Console, analytics and backlinks.
Map every old URL, including images and files, to one new URL (no chains).
Export titles, descriptions, canonicals and structured data for later comparison.
Crawl and Back Up the Old Site
Back up all existing data and keep a complete copy of the old site you can restore. Then crawl it: tools like Screaming Frog record the structure, metadata and status of every URL, which you will compare against the new site later. Keep the old and new crawls in separate, clearly labeled folders.
Source: Screaming Frog
Find the Pages That Earn Links
When exporting important data for a website migration, create a list of all subpages that receive external links. 404 errors on these pages post-migration can negatively impact SEO and harm organic traffic, so use tools like Ahrefs to track these links.
Source: Ahrefs
Build the Redirect Map
Use several URL sources, because each one misses something, and keep one row per old URL with its new address, status and the referring domains it has. That sheet becomes the redirect file and, later, the test list for launch day. See the tools for a successful website migration.
Questions for the Inventory Stage
Has the team fully mapped the existing CMS setup, including plugins, integrations, and content types?
Are potential risks (SEO, redirects, dependency gaps, legacy code) documented?
Does the team have a content and URL inventory to avoid content loss?
Does the redirect plan cover legacy URLs, canonical rules and pagination?
Phase 3: Build and Content Model
Design the content model before importing anything.
Migrate content with scripts, and review a sample by hand.
Rewrite internal links and embeds in the content to the new URLs.
Keep staging behind password protection.
Map each old content type to the new model first: which post types, custom fields and page-builder blocks become which documents and fields, what is rebuilt in the front end and what is dropped. Then migrate with scripts, so you can re-run the import as often as you need, and check a sample of pages by hand for formatting, images and links.
While importing, rewrite links inside the content (body links, embedded media, buttons) from old permalinks to the new URLs. Redirects will catch what you miss, but a site that links to itself through redirects wastes crawl budget and slows users down.
Build on a staging site behind password protection: Google’s guidance on private content recommends it to keep pages out of search, while a robots.txt block alone does not. On Vercel, Deployment Protection covers this: Standard Protection, available on all plans, puts every deployment except the production domain behind Vercel login (a password instead is a paid add-on on Pro). For a platform-specific walkthrough, see our WordPress to Sanity migration guide.
Security and Access Questions
Are authentication, access roles, and user permissions defined?
Is the new setup aligned with compliance requirements (GDPR, data handling, retention)?
Has dependency and plugin vulnerability risk been audited?
Is there a plan for ongoing security monitoring?
Phase 4: Pre-Launch QA
Crawl staging: no broken links, every redirect one hop, correct canonicals.
Compare metadata and structured data with the old site.
On multilingual sites, update hreflang annotations to the new URLs.
Run lab performance checks (Lighthouse) and confirm analytics tags.
Prepare the rollback plan.
Robots.txt, Noindex and Sitemaps
Robots.txt controls crawling, not indexing: Google may still index a blocked URL that is linked from elsewhere. To keep a page out of search, use a noindex meta tag or X-Robots-Tag header, and do not block that page in robots.txt, or Google never sees the noindex. Prepare a sitemap of the URLs you want indexed; one file holds up to 50,000 URLs or 50 MB uncompressed, and larger sites split it.
llms.txt
llms.txt is an informal proposal for a Markdown file that summarizes a site for AI agents: an H1 with the site name, a short summary in a blockquote, then sections listing links to key pages. Google says you don’t need any new machine-readable files to appear in AI Overviews or AI Mode, so treat it as optional. What matters for AI answers is that pages are indexed, eligible for a snippet and clearly structured.
Structured Data
Schema markup tells search engines what a page is about. Make sure the types that describe your content (Article, Organization, Product, BreadcrumbList, FAQPage where you have real questions) survive the migration and validate in Google’s Rich Results Test. Google no longer shows FAQ rich results and dropped HowTo rich results in 2023, so keep that markup for meaning, not for a SERP feature.
Broken Links and Canonicals
Perform a crawl of the new website to identify any broken links that could result in 404 errors. Fixing these errors before launch is essential to maintaining traffic flow and ensuring that both internal and external links work properly.
Canonical links prevent duplicate content and help you concentrate SEO value on your most important pages, strengthening your site’s overall SEO strategy. Make sure they’re set up correctly.
Hreflang on Multilingual Sites
If the site has language or country versions, every hreflang annotation must point to the new URLs, and each version must list all the others and itself. A map that changes URLs but leaves hreflang pointing at old addresses sends Google to redirects instead of the right language.
Titles and Meta Descriptions
Carry titles and meta descriptions over in a consistent format: titles feed the title links shown in results, and descriptions are sometimes used for the snippet, so losing them changes how pages look in search and how often they get clicked.
Editor and User Walkthrough
Before launch, have two or three editors publish a real page end to end in the new CMS, including preview, images and scheduling, and have someone outside the project complete the site’s key journeys: contact form, search and sign-up. Fix what blocks them before cutover.
Performance Baseline
Run lab performance checks such as Lighthouse on staging and compare them with the old site; field Core Web Vitals only exist once real users visit, so check those after launch.
Questions for the QA Stage
Has the team validated sitemap.xml and robots.txt?
Has structured data (schema) been implemented and tested?
Is there monitoring in place to track indexing changes post-launch?
Phase 5: Cutover
Freeze content edits, run the final delta migration.
Switch DNS or deploy; remove staging noindex and robots.txt blocks.
Submit the old and new sitemaps in Search Console.
Once you’ve completed all necessary web development tasks related to the migration, it’s time to launch the new version of your website. At this stage, your project manager and SEO specialist should focus on ensuring proper indexation and maintaining organic traffic flow.
Content Freeze, Delta Run and Rollback
Freeze: agree a short window in which nobody edits the old CMS.
Delta run: re-run the migration for everything created or changed since the last full import, just before you switch.
Rollback: keep the old site deployable, and decide in advance what triggers a rollback (for example, a broken checkout or a large share of 404s) and who makes the call. Going back to the old platform usually means pointing DNS back at it. Once the new site is live on Vercel, Instant Rollback switches production back to a previous deployment without a rebuild.
On Finvisor’s move from WordPress to Next.js and Sanity, the cutover was a DNS switch on a Sunday evening, when traffic is lowest. Rolling back would only have meant pointing DNS back at the old site. It was not needed: there was no downtime and no new 404s across about 950 URLs.
Finvisor
From WordPress to Next.js & Sanity: An AI-Ready Site With Guardrails Built In” (z case study)
Check two separate things. First, robots.txt must no longer block the pages you want crawled. Second, the pages themselves must carry no noindex: the default robots meta value lets search engines index and follow, so most pages need no robots tag at all. A leftover rule such as Disallow: / from staging blocks crawling of the whole site; a missing robots.txt does not, because Google treats it as having no restrictions.
If staging also carried a noindex tag on top of password protection, remove it from every page you want indexed. A full crawl will flag leftovers, but also check the source of key pages by hand.
Check Redirects
Use a crawler such as Screaming Frog to generate a redirect report and confirm every old URL returns a permanent redirect (301 or 308) straight to its new page. Temporary redirects (302, 307) are not used by Google as a signal that the target should be canonical, so reserve them for genuinely temporary moves. In Next.js, permanent: true in next.configreturns a 308, which Google treats the same as a 301.
Submit Both Sitemaps
During the move, Google’s site-move guidance says to submit both the old and the new sitemaps in Search Console (warnings on the old one’s redirects are expected). Once Google has the new sitemap, you can remove the old one. Split very large sitemaps into smaller files under a sitemap index.
Analytics and Tracking
Tracking does not move with the content. Before launch, confirm the GA4 tag (or Google Tag Manager container) and your consent banner load on every template, and check events in GA4’s Realtime report and with Tag Assistant. Keep the Search Console property verified: if verification relied on a meta tag or HTML file on the old site, re-add it or switch to DNS verification.
Phase 6: After Launch
Day one: crawl the live site, test top URLs and redirects, watch server errors.
Week one: Page indexing report, 404s, traffic to the top pages.
Months one to two: compare traffic, rankings and field Core Web Vitals with the baseline; keep redirects for at least a year.
After completing the CMS migration, it’s important to review and verify the results using the data collected before and after the migration.
Run these checks at three points: on launch day, after the first week, and again one to two months later to see the long-term effect.
Organic Traffic and Top Pages
Monitor changes in organic traffic post-migration, as fluctuations might not be immediate. It’s essential to check traffic trends over time to identify any long-term impacts on visibility and user behavior.
Review traffic to individual subpages through search and compare these results with the pre-migration data to determine if there were any significant drops in traffic to important pages.
Speed and Core Web Vitals
Compare loading speed and Core Web Vitals with the pre-migration baseline. After launch you have field data: check LCP, INP and CLS in Search Console’s Core Web Vitals report, alongside lab tests for page speed and responsiveness. Google’s thresholds for a good experience are an LCP within 2.5 seconds, an INP under 200 milliseconds and a CLS under 0.1.
For real-time monitoring, you need RUM (Real User Monitoring). Tools like Vercel Speed Insights show live performance data per device, browser, and exact URL. This will help you react faster and catch regressions early.
Jakub Dakowicz, Pagepro CTO
Questions for the Performance Review
Are you targeting the current Core Web Vitals: LCP, INP, CLS?
Is performance being tested with both lab tools (Lighthouse/PSI) and RUM (e.g., Vercel Speed Insights)?
Have performance budgets or thresholds been agreed upon?
Is the caching strategy aligned with how content updates (ISR, caching headers, CDN rules)?
Search Console Checks
Source: Google Help
Here are some common issues you should watch out for:
Indexed, though blocked by robots.txt: Google indexed the page from links without crawling it, which robots.txt does not prevent. If it should not be indexed, remove the robots.txt block and add noindex; if it should, remove the block.
Not found (404) on submitted or redirected URLs: add the missing redirects.
Server errors (5xx): often hosting or deployment issues; fix them first, because Google slows down crawling when a site returns them.
Other Page indexing statuses: investigate each affected URL to find the cause.
Use Google Search Console to compare the number of indexed pages on your new site with those on your old site to verify no pages were lost during the migration process to a new CMS.
Curated tech news delivered straight to your inbox every month.
Migrating a Large Site With Thousands of URLs
Move a large site section by section, which Google’s site-move guidance allows, and verify one section’s rankings before you move the next. Plan for two hard limits: one sitemap file holds up to 50,000 URLs, and Next.js redirects in next.config are limited to 1,024 on Vercel.
Scale is manageable with the right model: we replatformed GP Notebook, a UK medical reference platform with 100,000+ subpages, from a legacy CMS to Next.js and Sanity, and its organic traffic doubled within two years of the relaunch.
GP Notebook
Scaling a 100K+ Page Medical Platform with Next.js & Sanity
If the domain changes too, follow our domain migration guide and do it as a separate step.
Keeping Editors Publishing During the Migration
Editors do not have to stop for weeks. Either migrate section by section, so most of the site keeps its old workflow until its turn, or keep publishing on the old CMS until a short freeze, then run a final delta migration that brings across everything published since the main import. Train editors on the new CMS before launch, not after.
What to Do If Traffic Drops After a Migration
Some fluctuation is normal: Google’s site-move guidance says to expect temporary ranking changes during a move, and a small to medium-sized site can take a few weeks for most pages to move in the index. If traffic to key pages is still down after that, or falls sharply in the first days, check these causes in order:
Redirects: old URLs returning 404s, redirect chains or redirects to the wrong page.
Leftover blocks: noindex tags or robots.txt rules from staging.
Canonicals pointing to old, staging or wrong URLs.
Internal links still pointing to old URLs.
Content that was dropped or shortened during the migration.
The Page indexing report in Search Console, URL by URL, for the top pages that lost traffic.
What a CTO Should Own
The CTO owns three decisions: the content model, which sets how fast the team can ship for years; the redirect and rollback plan, which sets the launch risk; and the cutover window, which sets the business impact. Everything else can be delegated with a checklist.
How Long a CMS Migration Takes and What It Costs
It depends on the number of content types, integrations and URLs, and on whether the front end is rebuilt. See how long a website migration takes and what a website migration costs. With Nexity, Phases 1 to 4 (plan to pre-launch QA) fit into a four-week engagement that delivers a production-ready foundation:
Week 1, Discovery and Demo: a 48-hour demo with your real content, the full content and URL audit, an SEO risk report, and a fixed scope and price.
Week 2, Content Migration: content and media moved, the schema designed, the 301 redirect map generated.
Week 3, Core Build: core pages and the main user journeys built, staging live.
Week 4, Stabilise and Handover: QA, redirect testing and editor training.
Cutover and the after-launch checks follow. Custom integrations and advanced features are scoped after that, so a larger platform runs longer.
If your team is running on WordPress, Gatsby or a custom stack that’s slowing you down, Nexity is Pagepro’s system for moving it to a modern Next.js + Sanity foundation, and across 20+ migrations, none has lost Google rankings once the move settled. Learn more about Nexity.
How to Choose a CMS Migration Partner
Choose the partner that can show you, before you sign, how your own site will move: the URL inventory, the redirect plan, the rollback plan and results from a comparable migration. A portfolio proves design skill, not migration skill. Ask each candidate for this evidence:
Before-and-after data from a real migration: rankings, traffic and Core Web Vitals.
How they build the URL inventory and verify redirects.
Their rollback plan and who decides to use it.
Who owns SEO during the project, and how editors are trained.
References from a client who migrated from the same CMS you use.
Treat these as red flags:
No redirect map or URL inventory in the proposal.
SEO handled after launch rather than planned before it.
No rollback plan, or no named person who decides on a rollback.
A fixed price before anyone has looked at your content, URLs and integrations.
The strongest test is to see your own content migrated before you commit. That is why the Nexity engagement above starts with a demo built on your real content, before the scope and price are fixed.
A CMS migration keeps its rankings when the plan comes before the code: a complete URL inventory, a tested redirect map, one change at a time, a rehearsed cutover and checks after launch.
If you want to see your own site on a new stack first, our CMS migration service starts with a free 48-hour demo that rebuilds part of it with your real content. Or contact our experts.
A CMS migration is the process of moving a website from one content management system to another. It includes transferring content, media files, URL structures, metadata and workflows. The goal is to improve the site without losing SEO or breaking existing pages.
Can CMS migration affect SEO?
Yes. It can improve SEO or harm it. Redirect mapping, metadata, structured data, URLs and internal links must be preserved; with that done and checked after launch, expect only temporary fluctuation while Google processes the move. Across 20+ migrations, Pagepro has not had a client lose rankings once Google processed the move.
How long does a CMS migration take?
It depends on the number of content types, integrations and URLs. With Nexity, the first four weeks deliver a production-ready foundation; larger platforms take longer. See how long a website migration takes.
How long should we keep redirects after a migration?
Google recommends keeping them for as long as possible, generally at least a year.
Should we redesign the site at the same time?
Google advises changing one thing at a time. If you can, migrate the CMS first and redesign afterwards, so you can tell which change caused any movement in rankings.
Do we need an llms.txt file?
No. Google says no special files are needed to appear in AI Overviews or AI Mode. llms.txt is an informal proposal you can add, but indexing, snippet eligibility and clear structure matter more.
Should we migrate everything at once or in sections?
Small and medium sites usually move all at once. Large sites can move section by section, which makes problems easier to spot and fix.
