SaaS website redesign in phases: when a section-by-section rollout beats one big launch, and how to run it.

What is a phased website redesign?

It's a redesign that ships in stages instead of on one launch day. Typically the homepage and product pages go first, while the blog, docs, and resource library keep the old design on the old platform until a later release. Visitors never leave the domain; routing decides, path by path, which system answers.

Developers call this the strangler fig pattern, a name Martin Fowler took from a vine that seeds high in a tree and slowly takes over its host. His version builds new code "on top of, yet separate to" the old system and moves behavior across bit by bit. Fowler's reason is blunt: he has seen the plan to replace a serious system in one go "go down in flames most of the time," not least because a full replacement takes a long time and users won't wait that long for new features.

A marketing site is far smaller than the systems Fowler writes about, and plenty of them should simply relaunch. The trade-off still holds at this size, though. One launch day puts every risk on the same morning: redirects, forms, tracking, and the new messaging all go live together. Phases let the new pricing page start converting months before the blog moves, at the price of keeping two systems running in the meantime.

When does a phased redesign beat a single launch?

When the site is large, the platform is changing, or the team can't pause publishing for months. Google's own guidance on site moves points the same way: it recommends moving all URLs at once for small and medium sites, and says large sites can move one section at a time so problems are easier to spot and fix.

The brand question gets less attention than it deserves. After a rename, a phased site sends some visitors from a new product page to an old blog post that still carries the previous name and logo, and they have to work out whether it's the same company. A refresh that keeps the name and colors close to today's can live with mixed pages for a few months; a rename usually can't.

Size alone doesn't force phases, though. A single launch can carry thousands of URLs when the redirects are planned and tested: on Surfe's move from WordPress to Webflow, we redirected 2,400 pages and tested every one before launch, as our WordPress to Webflow migration guide describes.

How do you sequence the phases?

Lead with the pages that sell: homepage, product, pricing, and the demo request flow, since they carry the new positioning and most demo traffic. Supporting pages follow in order of value. The blog and other big libraries usually move last, as they hold the most URLs and rankings, and a platform change deserves a small pilot before anything else.

The pilot idea comes from Google's site-move guidance for large sites, which suggests testing with a section that doesn't change often or swing with news and events, and warns that one section won't surface every problem a full move would. On a SaaS site, the legal pages, a partner directory, or the careers section fit that description. If routing, analytics, or redirects break there, nobody's demo request gets lost.

Whatever the order, each phase needs a gate. We'd hold the next release until the previous one has had about two weeks of real traffic, which is long enough to spot a broken form or a tracking gap. Rankings move more slowly, so keep watching them while the next phase is built rather than waiting for them to settle.

How do the old and new sites share one domain?

Through path-based routing in front of both systems. A reverse proxy or CDN rule sends each URL path to the system that currently owns it, so /pricing can come from the new site while /blog still comes from the old one. Visitors and search engines see one domain, and each phase becomes a routing change plus its redirects.

When the new site is on Webflow and the old domain is hosted elsewhere, Webflow documents a self-managed reverse proxy for exactly this. It needs a paid Site plan, a dedicated origin subdomain such as wf.example.com, a proxy that preserves the Host header and forwards query strings, and Webflow's Href prefix setting to keep internal links working under a subdirectory like /blog. Two caveats from the same article, updated October 5, 2026: Webflow's support team won't help set up or troubleshoot third-party proxies, and origin responses can't exceed 2 MB. Plan how your CDN's cache gets cleared after each publish, too.

The shared pieces are where phased projects leak. Header and footer, the consent banner, the analytics tag and its event names, fonts, and the demo request form all need to behave the same on both systems, or the site looks and measures like two sites. Our post on Consent Mode v2 on Webflow covers the consent side. Because both systems sit on one domain, first-party cookies and analytics sessions carry across, as long as both load the same tag with the same settings.

How do you keep publishing during a phased redesign?

Only the section that's moving gets frozen, and only for a few days. The rest of the site keeps publishing on the old system as usual. For the moving section, the team picks a cutoff date, migrates, checks old against new page by page, and publishes only on the new system from launch day.

On single launches, we pause content changes on the old site for the last few days before go-live, as our website redesign timeline explains. A phased project applies the same short freeze to one section at a time, which is the main reason marketing teams with a busy blog choose it. The blog keeps shipping while the product pages change, and it gets its own freeze when its turn comes.

The risk is double entry. A campaign page that needs a link from the new navigation and a banner on old blog posts touches both systems, and someone has to own each change. Keep a simple rule per phase: new pages go on the new system once their section has moved, and nothing new gets built on the old one. If the blog is moving from WordPress, our guide to importing WordPress posts into the Webflow CMS covers field mapping and what breaks.

What happens to navigation, internal links, and SEO between phases?

This is where phased projects lose rankings, if they lose them anywhere. Navigation has to match on both systems, old pages need their links updated when a section moves, and changed URLs need redirects. Google advises redirecting to the final URL directly and keeping redirects for as long as possible, generally at least a year.

Chains creep in because phases revisit the same URLs. Say phase one redirects /features to /platform, and phase three renames /platform to /product. Unless someone goes back and edits the first rule, an old link to /features now hops twice before it lands. One redirect map for the whole project, with earlier rules rewritten whenever a URL changes again, keeps every old address pointing straight at its current home. Our redesign SEO checklist covers building the URL map and the 90-day monitoring plan.

Pages that keep their URL and content usually ride out a new design with little SEO change; it's the URL changes that need planning. For those, watch each moved section on its own in Search Console, filtered by path, for at least a month. Google says it can take a few weeks or more for new URLs to show for a medium-sized site, so a dip in the first days after a phase is normal; a dip that's still there a month later usually traces back to a missed redirect or an internal link that still points at the old address.

We redesign and migrate websites for B2B SaaS companies, so we have an interest in the topic. Our website redesign service covers both single launches and phased ones.

Questions about redesigning a SaaS website in phases