A CMS migration plan is a written roadmap for moving your site's content, templates and integrations from one content management system (CMS) to another. It says what moves, what gets cut, who owns each step and how the switch happens on launch day. Most of the outcome is decided before anyone touches the new platform, so the plan matters more than the tool. Below is the plan we would hand a business owner, in the order we would work through it.
TL;DR
- Write the plan first: goals, scope, owners, timeline, risks and a rollback path.
- Audit every page, then mark it keep, merge, rewrite or retire before you build anything.
- Map every old URL to a new one with a 301 redirect. Never send everything to the homepage.
- Test redirects, forms and key pages before launch. Watch errors and form submissions daily after.
- Pick a quiet week for cutover, not a product launch or your busy season.
When you need a migration plan
You need one any time a change affects where content lives, how pages are structured, or how people and search engines find them. Common triggers include a redesign, a CMS move, a domain change, a URL structure update, a rebrand or a big content cleanup.
The size of the plan depends on what is actually changing. A cleanup inside the same CMS is a small job. A redesign, a new CMS and new URLs all at once is a much riskier one. Ask which of those three you are doing before you set a budget.
You also do not have to wait for your old system to fail. A migration can happen in one launch or in stages, so you can move on your schedule.
Step 1: Set goals, scope and success measures
Write down why you are moving. Faster pages? Easier editing? A dealer portal, a booking tool, a second language? Each goal changes which platform fits and what "done" means.
Then write the success measures. Keep them plain: organic traffic holds within a range you agree on, forms still reach your inbox, key pages load as fast as before or faster. A person on the business side should own them, not only the developer.
Where it goes wrong: goals like "modernize the site" cannot be tested. If you cannot check it after launch, rewrite it.
Step 2: Build the team and name the owners
A plan may assign an executive sponsor who owns funding and final decisions, a project manager who runs the plan, and specialists for design, data and systems. For a business with ten employees, one person can hold two roles. What cannot be shared is the final say. Pick one person.
Also name who approves content. Editors and business owners should sign off before launch, not discover problems after it.
Step 3: Audit your content
Crawl the whole site, including subdomains, and list every page. For each one, record:
- URL and title
- Content type and status
- Last modified date and author
- Organic traffic and backlinks
- Internal links and embedded files
This is the same inventory approach described in this content migration framework. A content audit also lists images, media and metadata, which helps you decide what to move and what to drop.
Then make a call on every page: keep, merge, rewrite or retire. Retiring pages is normal. A cleaner site often performs better than a copy of a cluttered one.
If your team cannot agree which URLs are going away, stop there. That conversation does not get easier later.
Step 4: Map every URL and integration
This is the step that protects your search rankings and your leads.
- Give each old URL a new home with a 301 redirect, which tells search engines the move is permanent.
- Use a 410 for pages you deleted on purpose.
- Do not redirect everything to the homepage.
- Avoid redirect chains and loops.
- Update internal links to point to the new URLs directly.
The URL mapping rules above cover 301s, 410s and the homepage trap. At minimum, map every URL that has backlinks, ranks well or is linked often inside the site. Coredna's checklist suggests the top 50 ranking pages as a floor.
Redirects pass on value only if your internal links stay healthy too. A clear internal links and SEO guide helps you decide which links to keep pointing at your best pages.
Now list integrations: your CRM, email tool, payment processor, booking system, analytics and any forms. Missing one of these is how a launch goes live with a dead contact form. For a deeper SEO pass, see our prelaunch checks for site migrations.
Step 5: Snapshot your baseline
Before you change anything, take a snapshot of your analytics and ranking data. Note your top pages by organic traffic. After launch, you compare against this. Without it, you cannot tell a dip from normal movement.
Also save a tested backup of the old site. Test that you can actually restore it.
Step 6: Choose an approach and a timeline
You have two main options.
| Approach | How it works | Fits when |
|---|---|---|
| One launch | Everything switches on a single day | Smaller sites, a clean redesign, few integrations |
| Phased | Sections move in stages, tested at each one | Large sites, several languages, portals or member areas |
A phased move is lower risk because you learn on a small part first. Microsoft's migration guidance advises starting with simpler, lower-risk pieces to build confidence. It also says to avoid critical business periods such as financial closes, launches and holiday seasons.
For a realtor, that means not cutting over in peak listing season. For a home service business, not in your busiest booking weeks. Our guide to how long a redesign really takes will help you set realistic dates.
Budget for more than the build. A migration budget should include testing, training and a contingency reserve.
Step 7: Build on staging and run a practice move
Set up the new platform on a staging site, which is a private copy not visible to the public. Move a small section first. A pilot shows whether formatting, metadata, asset paths and permissions come across correctly.
Then do a full dry run. Check redirects, forms, key user paths, analytics tags and integrations. Test from a search engine's point of view too: can it crawl the pages?
Step 8: Test before launch
Run user acceptance testing with the editors and owners who will use the site. Then use this checklist, drawn from a standard post-migration QA list:
- Pages load and layouts look right
- Navigation and links work
- Images and videos display
- Search, buttons and forms work
- Account creation and login work, in more than one browser
Add accessibility to the list. Our five-minute accessibility checklist is a quick place to begin.
Step 9: Launch day runbook
Write the launch as a numbered list with a time and a name beside each line. Include a written rollback plan: the exact point at which you switch back, and who decides.
Run a broken-link scan before the DNS cutover and again 48 hours after. DNS is the setting that points your domain at the new server.
Pick a low-traffic window. Keep the old site and backup available until you are sure.
Step 10: Monitor after launch
For the first two weeks, check 404 errors, traffic and form submissions every day. Fix broken URLs the day you find them. Keep watching beyond that. One checklist runs post-migration monitoring for 90 days. Compare traffic against your baseline from Step 5.
Our technical SEO checklist gives you a list for the fixes that come up in that window.
Where a studio takes work off your hands
Most owners can write the goals and approve the content. The audit, the URL map, the staging build and the launch runbook are where hours disappear and mistakes hide. That is the part we do for clients: you stay involved from idea to launch, and we handle the build.
If you want a plan scoped to your own site, talk to us about web design and development. We work with realtors, home service businesses, B2B distributors, property managers and founders across Canada and the US.
Our view: the plan is the project
Owners often ask us about the new platform first. We understand that. It is the exciting part.
But the platform is rarely what decides whether a migration goes well. The plan does. A clear inventory, an honest decision on each page and a URL map that someone has checked line by line will carry a project further than any feature list.
We build in the open. You see the audit, you approve what stays and what goes, and you know the launch plan before launch day. That is how we like to work, because a migration touches your leads, your search visibility and your team's daily routine.
If your site also needs a portal, a bilingual setup or an automation, say so at the start. It changes the plan, and it is much cheaper to plan it in than to bolt it on later.
Loic
FAQ
How long does a CMS migration take?
It depends on page count, integrations and whether you redesign at the same time. A small brochure site can move in weeks. A large site with portals or several languages takes longer, and a phased move spreads the work out. Our redesign timeline guide breaks down the stages.
Will I lose my Google rankings?
Not if the redirects are right. Map every page that has links or traffic with a 301, update your internal links and compare against your pre-launch baseline. Watch errors daily for the first two weeks.
What should be on a CMS migration checklist?
Goals and scope, a content inventory with a decision per page, a URL map, an integration list, a tested backup, a staging dry run, user acceptance testing, a launch runbook with rollback, and post-launch monitoring. Steps 1 to 10 above follow that order.
Should I move everything at once?
Smaller sites with few integrations can launch in one go. If your site is large, has member areas or runs in two languages, move in phases and test each one before the next.
Sources
- Coredna: CMS migration checklist
- Slickplan: website content migration plan
- Shopify: CMS migration types, process and checklist
- Ralantech: how to build a migration plan
- Content migration framework on GitHub
- Contentful: CMS migration tips
- HubSpot: website content migration plan
- Microsoft: plan your migration
- Storyblok: step-by-step CMS migration guide
- Semrush: complete CMS migration guide
- Roadmap Creator: CMS migration plan template
- Internal links and SEO guide
