A CMS migration moves your entire website — pages, media, metadata, and structure — from one content management system to another. A content management system (CMS) is software that lets a team create, edit, and publish digital content without hand-coding each change, and as the MDN Web Docs glossary explains, it conventionally splits into an authoring application and a delivery application.
For beginners, the key thing to grasp is that migration is a staged project, not a switch you flip. As Storyblok's migration guide frames it, the work requires planning, content modeling, and validation before any content actually moves. This article covers the core concepts, the tools, and the concrete first steps.
Official resource:
- Apply through Mozilla’s official page — Use this page to review requirements and apply directly.
Table of Contents
- What "migration" actually moves
- Traditional versus headless — which target fits you
- The first step is an audit, not an export
- Pilot first, then move at scale
- Protecting your search traffic when URLs change
- Frequently Asked Questions
What "migration" actually moves
A migration transfers four things: the content itself (pages and posts), media assets (images, video, downloads), metadata (titles, descriptions, publish dates, authors), and structure (how content is organized and linked). Miss any one, and the new site looks broken even when the text arrives intact.
The trap for beginners is treating it as a copy-paste job. Formatting, image file paths, author permissions, and URL structures rarely map one-to-one between systems. That is why Storyblok describes migration as a staged project built on content modeling — defining a structured schema for your content — rather than a bulk export and import.
Traditional versus headless — which target fits you
Your first real decision is what you migrate *to*. As Contentful explains, beginners choose between two architectures: For most beginners running a single website, a traditional CMS is the simpler target because it ships with a front end.
wordpress is the safest default reference point: W3Techs data reported by Barn2 puts it at roughly 40–43% of all websites and about 60% of sites using a known CMS as of 2026. That dominance means the most import tools, guides, and community help exist for WordPress as both source and destination.
- **Traditional (monolithic) CMS** — the back end and front end are tightly coupled. WordPress, Drupal, and Joomla work this way. You get themes, plugins, and a ready-made website out of the box.
- **Headless CMS** — content storage is separated from presentation, and content is delivered to any front end through an API. This suits teams serving a website, a mobile app, and other channels from one content source.
The first step is an audit, not an export
Before you touch a migration tool, inventory what you have. A content audit lists every page, flags stale or duplicate content, and lets you delete what should not travel with you. Storyblok recommends pairing this with content modeling — defining the schema your content will use — and doing both collaboratively across content, design, and developer teams.
This step saves the most pain later. Migrating junk pages costs the same effort as migrating good ones, and a clean inventory tells you exactly how many items your import tool must handle. It also surfaces content types your new CMS needs to support before you commit to it.
Pilot first, then move at scale
Do not migrate everything at once on your first attempt. Storyblok advises running a pilot migration — moving one small section to test how formatting, metadata, asset paths, and permissions survive the trip. If images break or author fields vanish on ten pages, you learn it cheaply.
Your tooling depends on the source system. Options range from custom scripts, to manual re-entry for tiny sites, to purpose-built import plugins for common platforms like WordPress. Run the pilot, fix what broke, and only then process the full catalog using the same tested path.
Protecting your search traffic when URLs change
Migrations often change URLs, and this is where sites lose traffic if handled carelessly. When a URL changes, Google Search Central recommends server-side permanent redirects (HTTP 301 or 308) from each old URL to its new one.
These preserve link credit and do not cause a loss of PageRank — but keep redirect chains short, ideally under three hops. A few rules make the move cleaner: Map every old URL to its new destination during the audit, so no redirect is missing on launch day.
- **Move all URLs at once.** For small and medium sites, Google advises migrating everything simultaneously rather than section-by-section, so its algorithms detect the move faster.
- **Expect a delay.** Even done well, it can take a few weeks or longer for new URLs to fully replace old ones in search results.
- **Signal a domain change.** If you also move to a new domain, Google Search Console's Change of Address tool tells Google about the move and helps transfer signals to the new site.
Frequently Asked Questions
How long does a CMS migration take to show up correctly in search?
Even with redirects done right, Google says it can take a few weeks or longer for new URLs to fully replace old ones in results.
Should I migrate my whole site in one go or in phases?
For content, pilot one small section first to catch errors. But for the URL switch itself, Google advises small and medium sites move all URLs at once so the change is detected faster.
Do I need a headless CMS?
Only if you serve content to multiple front ends, like a site plus an app. For a single website, a traditional CMS such as WordPress is simpler because it includes a front end.
