CMS Migration:Strategy, Process and Tips for B2B SaaS Websites

In a CMS migration, you move your website's content and functionality into a new system. Importing the text is usually the smallest part. Most of the work goes into functions the old system handled on the side, such as a form connected to your CRM. Overlook something like that and you lose leads after launch.

That is why the most important decision comes before the first export. You define how your team will build and maintain pages in the future. That tells you which system fits and how much is allowed to change during the move.

When a CMS migration is worth it

Switching your CMS is worth it when the system itself slows down your marketing. You usually notice this in day-to-day work before any analysis shows it. If the real problem is that your message and page structure no longer fit, a new system alone will not fix it.

Typical triggers in B2B SaaS teams

We see similar signs in B2B SaaS teams again and again. A new landing page waits in the development backlog although the campaign is ready to go. Plugin updates and security issues cost time every month that marketing could use elsewhere.

Then there are technical limits. Heavy themes slow down load times, and a page builder imposes a layout that no longer fits the product. A second language or a new product line can only be added through workarounds in some systems.

What matters is whether one of these limitations actually slows down your marketing. A single serious bottleneck can justify a switch, while smaller problems can often be solved in your current CMS.

When you should stay with your current system

A close connection to the product makes the switch more complex, but it is not automatically a reason against it. If a login area or a shop lives in the same system, you can also run the marketing website and the product application separately in the future. That means more migration effort, but it often removes exactly the dependency that holds marketing back today.

A stronger reason against switching is when your current CMS reflects how your team works. One example is a large editorial team that works reliably with its approval process in the current system. If what is mainly missing is a clear message, revising copy and structure in your existing system usually helps more.

Strategy: first decide how your team should work

Which target system fits depends on who will build pages and how structured your content is. The old system mainly determines how the export works technically. So before choosing a system, write down your goal in one sentence, for example: "Our marketing team publishes campaign pages without developers." That sentence later becomes the acceptance criterion for the project.

Large websites with many languages often bring additional requirements, such as security reviews or fixed roles and approvals in the CMS. Clarify these before choosing a system, because they often narrow the options more than the editor does.

When Webflow fits

Webflow fits when your marketing team should build landing pages and campaigns itself, without code. Editor and CMS run in one system, and hosting is included. For this to work in practice, reusable components and templates belong in the project scope.

When Astro with a headless CMS fits

With a headless CMS, your content lives in a separate system such as Sanity, and your own code handles the presentation. With the Astro framework, this results in a fast, lean website. It fits when your team wants to own the code and has development capacity for new page types. On top of that, AI agents can implement changes in the code, so smaller teams can also build new pages faster.

Define the scope: 1:1 move, relaunch or stages

How much changes besides the system drives effort and SEO risk more than the old CMS does. What matters is whether your website still describes your current audience and offering correctly.

Our take: a pure 1:1 move is only worth it if the website's message is still right. For SaaS teams that have grown since their last launch, that is rarely the case. The website might still address founders of small teams, for example, while sales has long been talking to marketing leads at mid-sized companies.

A move in stages sounds less risky, but it brings its own requirements. As long as the blog and the rest of the website run on different systems, you need consistent navigation, shared tracking and redirects across both systems. For smaller websites, a complete switch in one go is therefore usually simpler.

The more changes at once, the harder it is to tell after launch where a change in rankings or leads comes from. So only change URLs where there is a reason to.

What moves in a CMS migration and what gets rebuilt

Recurring content such as blog posts or use cases moves into the new CMS in a structured way. Page layouts are rebuilt in the new system, as is everything a plugin or module used to handle. Every URL that changes in the process needs a plan, usually a redirect.

Content and content model

The content model defines which content types your website has and which fields each type needs. A blog post, for example, has a title, author, category and body. Approve this model before anything is imported. Every later change to the fields has to be reworked in all entries already imported.

Plugins and special functions

What gets lost in a move is mainly what the old system generated through extensions. In WordPress these are plugins and shortcodes, in TYPO3 extensions, and in HubSpot custom modules. In the imported text, such elements often only show up as fragments or not at all.

So create a list of functions. For each entry, decide whether the new system covers it, whether a custom component or integration is needed, or whether the function is dropped. This list determines the effort more than the number of pages.

URLs and page structure

Every system has its own URL patterns. By default, dynamic CMS pages in Webflow consist of the collection path and the item's slug, for example /blog/onboarding-checklist. Date-based WordPress addresses like /2024/05/onboarding-checklist/ therefore cannot be reproduced for CMS posts. In Astro, you define routing in code yourself and can often keep old paths.

So define the new URL scheme early and keep existing URLs wherever the system allows. From this you derive the redirect map, the table that assigns every old URL its new address.

Special cases by source system

Which special cases come up depends on the source system. The overview shows the most common points and leads to the detail pages for your migration path.

The six phases of a CMS migration

A CMS migration runs in phases, each ending with a result. Your team signs off each result before the next phase begins. That way, gaps in the inventory or the redirect map show up while they are still easy to fix.

The phases apply to every target system. The easiest way to build the inventory is with a crawler such as Screaming Frog, supplemented by the pages with traffic from Google Search Console. For Webflow, we describe the project plan with all roles in detail in our article on Webflow migration.

Who delivers what

Your team remains responsible for the decisions, even if an agency does most of the implementation. That mainly includes the page scope. Your team also signs off the redirect map and the forms at the end. Name one person in marketing who owns the project and is allowed to make decisions.

What the duration depends on

The duration depends mainly on the chosen approach. The import itself hardly matters: in our projects, the pure content migration usually takes a few hours of working time. A complete relaunch with migration typically takes us 12 to 20 weeks.

Approvals take up most of the calendar time, above all the approval of the content model. Every additional content type and every integration mainly extends the testing phase. A second language adds extra checks for redirects and for mapping the language versions.

Protecting rankings and leads during the switch

Redirects are one of the most important factors for keeping your rankings, but not the only one. Changed content, new internal linking, wrong canonicals or accidentally blocked pages can also cost rankings. Leads, on the other hand, are usually lost when forms no longer reach the CRM after the move. Without a saved baseline, you notice such losses late.

Redirects and URL plan

Redirect every old URL with a 301 redirect directly to the matching new page. In its guide to site moves, Google advises against redirecting many old addresses to the homepage. If an old page deliberately has no meaningful successor, do not force an unrelated redirect. In that case, a 404 or 410 status is the cleaner solution.

Prepare the redirect map in advance and check its target addresses on staging. Whether the redirects from the previous live URLs actually work can only be fully tested after the switch, though. So plan this test as a fixed part of go-live and avoid chains of multiple redirects. Google recommends keeping redirects for as long as possible, generally at least one year.

Forms and tracking

You reconnect forms in the new system. Then check for every form whether all fields arrive complete in the CRM. Also check whether the lead source is captured correctly and the lead reaches the right sales team.

The most reliable way is for sales ops to test this with real test submissions from every form. You also set up tracking and the consent banner again. Save the numbers from the old system beforehand, otherwise you will have nothing to compare against after launch.

Metadata, indexing and AI search

Page titles and meta descriptions do not move over automatically in every system, and the same goes for structured data. Transfer them deliberately and check internal links against the new addresses. Also check canonicals and make sure no live page is set to noindex. With multiple languages, mapping the language versions (hreflang) is part of this.

In its documentation on AI features, Google explains that the same fundamentals apply to AI Overviews as to classic search. Accessible text and a clear structure therefore help with both.

Four tips from our migration projects

Many correction rounds can be avoided with a few rules you set before the first import. In our experience, these four points save the most rework.

Secure campaign URLs first

Ads and newsletters often link to landing pages that do not appear in any sitemap. Old links also live in sales decks and on partner sites. So ask performance marketing and sales for their active links before the redirect map is final.

Test with the hardest pages

For the test import, pick 5 to 10 typical pages and deliberately include the most complex ones. These are, for example, posts with tables and embedded elements. Formatting the new system does not support then shows up before you have to rework hundreds of entries.

Plan a content freeze and a final sync

New posts keep being published in the old system during the project. So set a date after which nothing more is published there. Shortly before go-live, you then transfer only the new and changed content from the project period. This kind of delta import prevents entries you have already edited from being overwritten or duplicated.

Define the way back before launch day

Clarify beforehand who decides on launch day and for which errors your team switches back to the old website. A broken form can often be fixed live. If redirects for important pages are missing, a planned way back is the safer choice. For this, the old website and a full backup stay available until the new one runs stably.

Go-live checklist for your CMS migration

These checks decide whether search traffic and leads survive a CMS migration. Tick them off around go-live together with the person in charge:

• Inventory, baseline and full backup saved before implementation
• Redirect map with all old URLs approved, pages without a successor deliberately set to 404 or 410
• Redirects tested on the live domain after the switch, without chains
• Canonicals checked and no noindex on live pages
• New XML sitemap submitted in Google Search Console
• Test submissions from every form traced into the CRM, including source and owner
• Tracking and consent banner checked on the live domain
• Search traffic, error pages and leads compared with the baseline in the following weeks

You can find the general checks for launch day in our website relaunch checklist, which is also available as a PDF with space for owners.

Do it yourself or with an agency?

A small website without language versions and without a CRM connection can be moved by a team with experience in the target system. If many pages bring in leads through search or integrations are attached to the website, the risk of errors after launch grows. Experienced support then mainly saves correction rounds.

Before you get a proposal, clarify who creates and tests the redirect map. Also ask who is responsible for the import and who signs off the forms all the way into the CRM. The answers show you whether the migration is planned into the proposal or expected to run on the side.

If positioning and design should also be redone alongside the system, a relaunch is the right framework. Then you plan message, structure and migration together instead of just copying the old website into a new system.