The site builder was the right call
Before anything else, so we understand each other: if you started your SaaS website on Webflow or WordPress, you did nothing wrong. A site builder gets you live in two weeks, costs a double-digit amount per month, and needs no developer. In the seed stage, that is exactly what counts: speed over architecture. I regularly recommend this route to founders myself.
But every tool has its territory. What worked well with five pages and a blog becomes a brake at a certain size: on your marketing, your rankings, and your team. I'll show you five signals that tell me a SaaS website has outgrown its tool — and just as honestly, when you're better off staying where you are.
If you want the big picture first: in the anatomy of a B2B SaaS website, I describe which page types a SaaS needs in the first place. This article picks up later: at the question of when the foundation underneath no longer carries the load.
Five signals your SaaS has outgrown its tool
These five signals come from the migration inquiries that land on our desk. They rarely appear alone: if you recognize two of them, the others are usually already on the horizon. Go through them in order and keep count.
Signal 1: your content model no longer fits into collections
Webflow organizes content in CMS Collections, and their limits are printed in black and white on the pricing page: depending on the plan, 2,000, 10,000, or 20,000 items and 20, 40, or 100 collections. Even the largest plans allow at most 100 fields per collection, including a maximum of 20 reference fields (as of September 2026).
For a SaaS, that gets tight faster than it sounds. Features, integrations, use cases, industries, and comparison pages all cross-reference each other: that is exactly what you need reference fields for. As soon as you want to roll out programmatic pages like "integration with X" or "solution for industry Y" in series, you hit this ceiling.
WordPress has the opposite problem: hardly any hard limits, but no content model either. Custom post types and structured fields only enter the system through plugins like ACF. Your model then lives in plugin configurations that turn every major update into a nail-biter. Whether headless WordPress is a way out is a question of its own — I answer it in the FAQ below.
Signal 2: multilingual support gets expensive or stays undone
As soon as your SaaS serves an English-speaking market alongside the DACH region, you need at least two language versions with clean hreflang annotations. This is exactly where site builders and a code stack part ways most clearly.
Webflow handles multilingual sites through the paid Localize add-on: from $9 per month per locale, at most three additional languages in the base package, up to ten in the Advanced package from $29 per locale. The built-in AI translation is capped as well: 10,000 words per language per month, 50,000 in the Advanced package (as of September 2026).
WordPress says it with refreshing honesty in its own documentation: "WordPress currently does not support a bilingual or multilingual blog out-of-the-box." You need plugins like WPML or Polylang — and they weave themselves deep into the database and theme.
In a code stack, by contrast, multilingual support is a routing concern plus a language field in the CMS: Sanity keeps language variants as separate documents, Next.js routes /de/ and /en/. Our own website runs exactly this way: bilingual, with no surcharge per language.
Signal 3: docs, changelog, and blog live in three systems
A SaaS website is more than marketing pages. Documentation, changelog, and blog belong to it, and a site builder covers exactly one part of that. The typical picture in inquiries: marketing pages in Webflow, docs on GitBook or ReadMe, the changelog in a third tool.
Three systems mean three logins, three designs, and three subdomains. On the SEO side, this is the most expensive part: your docs collect authority on docs.yourproduct.com instead of paying it into your main domain under /docs. For queries like "set up X", the docs platform's template then ranks instead of your website.
The rule to remember: one product, one domain, one content system. A structured CMS like Sanity holds marketing pages, docs, and changelog as different document types in the same backend, with one design and one search across all of it.
Signal 4: your team grows, your workflows don't
With three people in marketing, you suddenly need what developers have had for years: drafts, approvals, previews, versioning. In Webflow, page branching only arrives at the Team tier for $2,500 per month, granular role permissions only in the Enterprise plan. Below that, your team shares one working surface where an accidental publish can hit the whole site.
WordPress only does editorial workflows through yet more plugins, and staging depends on your host. In a code stack, you get all of this out of the box: every change creates its own preview deployment on Vercel with a shareable URL, approvals run as reviews, and Git logs every line. Sanity adds draft and publish states per document.
Signal 5: Lighthouse stagnates no matter what you optimize
The fifth signal is one you measure in numbers: if your Lighthouse scores stop climbing despite optimization plugins, you're fighting the tool instead of working on the website. In our audits, I regularly see grown WordPress sites at mobile performance scores between 40 and 60 — that is project experience, not a statistic.
The cause is structural. WordPress drags additional CSS and JavaScript into every page with each plugin, and page builders produce deeply nested markup. Webflow ships noticeably cleaner code but lets you control neither code splitting nor deferred script loading in detail.
Next.js flips the ratio: pages are statically pre-rendered, images are resized automatically, JavaScript loads only where it is needed. Good Core Web Vitals scores then become the normal state, not the product of a plugin collection.
What the migration costs and how long it takes
First, some framing: the ranges below are our project experience at happycoding from migrations to Next.js and Sanity, not a market study. Your case can land above or below them, especially with special cases like product integrations or large docs inventories.
| Scope | Typical case | Duration | Budget |
|---|---|---|---|
| Compact | 10–20 pages, blog, one language | 4–6 weeks | €12,000–20,000 |
| Standard | 30–60 pages, blog and docs, two languages | 8–12 weeks | €20,000–40,000 |
| Large | over 100 pages, programmatic templates, integrations | 3–4 months | from €40,000 |
There is more in these ranges than design and development: content modeling, data migration, a redirect plan, and moving your tracking are part of it. Many underestimate the data migration: Webflow doesn't export dynamic content with the code, and you only get collections out one by one as CSV files. From a few hundred items onward, we therefore write import scripts against the Sanity API.
You'll find a detailed breakdown by project size in the article What does a SaaS website cost?. As a rule of thumb for multilingual sites: plan for a 30 to 50 percent surcharge on the base scope.
Migrating without SEO damage: your rankings are the asset
The biggest fear before any migration is justified: losing organic rankings. A case from our practice: a prospect came to us after a previous relaunch had changed the URL structure without a redirect plan. Around 30 percent of organic traffic was gone within a few weeks, and the recovery dragged on for months.
Yet securing a migration is no dark art — Google describes it in its own documentation on site moves: use permanent 301 redirects, keep redirect chains to at most three hops, and leave the redirects in place for at least a year. According to Google, ranking fluctuations during the transition are normal; for medium-sized sites, reindexing takes a few weeks.
Our order of operations in migration projects:
- Keep URLs: the best redirect is the one you don't need. Wherever the old structure holds up, we carry it over one to one.
- Redirect map before go-live: every old URL gets a target, based on a full crawl plus your Search Console data.
- Measurement from day one: submit the sitemap, watch Search Console and 404 monitoring, and check the hreflang annotations on multilingual sites.
A migration doesn't lose rankings through the stack switch, but through missing redirects.
This checklist is how we secure every relaunch technically. The stack switch itself actually pays off: faster load times and clean internal linking are two of the levers that start working after the migration.
When you shouldn't migrate
Radical honesty is part of the deal: a migration is a project with a five-figure budget, and in some situations I actively advise against it. Four of them come up again and again:
- Your website has fewer than 15 pages and barely grows: then the site builder plays to its strengths, and the limits in this article simply don't apply to you.
- Your problem is the message, not the technology: if positioning and copy don't land, the best stack changes nothing about your conversion.
- Nobody owns the content: the finest content model stays empty if nobody on the team writes. Settle the editorial question first, then the tool.
- Your budget is below €12,000: then you'll usually get more per euro out of your existing system than out of half a migration.
If, on the other hand, you're still at the very beginning and choosing your first tool, this decision lies ahead of you, not behind you: start in the builder and come back to this article once the first signals show up. For everyone else: migrate because of concrete limits you can name — not because of a gut feeling.
Next steps
Count the five signals honestly: if you hit two or more, a migration is worth a closer look. The first step costs you just one hour: pull a content inventory, export your URLs from Search Console, and note the three places where your current system slows you down most. With this list, a gut feeling becomes a basis for a decision.
As a B2B website agency, we handle this path: content modeling, data migration, redirect planning, and go-live, on the same Next.js and Sanity stack our own website runs on. If you want to know whether the switch adds up for your SaaS, book a no-obligation intro call: we'll look at your website together, count the signals, and you'll get an honest assessment — even if it is "stay in the builder".
