When the thing you are building stopped being a website. The clearest signal is that your product experience now lives inside the marketing site, and you keep asking the platform to behave like an application framework. That is an architecture problem, not a Webflow problem.
We build in Webflow for a living, which makes this an awkward article to write and, we think, a more useful one to read. A studio that has never told a client to leave a platform is a studio you should not fully trust about that platform.
So here are the three signs we take seriously, the bad reasons we talk people out of, and what leaving actually costs.
Because the alternative is worse for everyone. If we only ever recommend the thing we sell, our advice is worth nothing, and clients work that out eventually. The projects we regret are the ones where the platform was wrong and we made it work anyway.
There is also a practical reason. Most of the teams who ask us about leaving do not need to. They need one specific problem solved, and the migration they were considering would have cost six figures and reintroduced every problem they had already fixed.
Being able to say honestly that you should stay is only credible if you are also able to say you should go. This piece is the second half of that.
The first is a developer who prefers a different stack. That is a real preference and it is not a business case. The cost of a migration lands on the marketing team's velocity, not on the engineer who wanted a nicer local setup.
The second is a single missing feature. Almost every gap we get shown turns out to be solvable with the Data API, a small custom component, or a change to how the content is modelled. Rebuilding an entire site to fix one page is not proportionate.
The third is cost, when nobody has priced the alternative properly. The subscription is visible and the engineering time to replace it is not. A self hosted stack has a hosting bill, a CMS bill, a monitoring bill and a person who maintains it. That last one is the expensive part and it never shows up in the comparison.
This is the strongest signal and the one we see most. It starts small. A calculator. Then a dashboard preview. Then a logged in area that needs real state. At some point the site is an application with a marketing page bolted on, and the tool is being asked to do the wrong job.
The tell is where your complexity lives. If most of your build effort goes into custom code that fights the platform's rendering model, you are paying for a visual builder you are not using. That is the moment to look honestly at the split.
The right answer is often not to move everything. It is to separate the application from the site, which is the middle path we come back to below.
Webflow publishes its Data API rate limits and they are worth checking against your actual integration load. The documentation lists 60 requests per minute on Starter and Basic, 120 requests per minute on CMS, eCommerce and Business, and custom limits on Enterprise, applied on a per API key basis.
Exceeding that returns an HTTP 429 Too Many Requests error, and the Retry-After header indicates how long to wait, typically 60 seconds. You can track your usage through the X-RateLimit-Limit and X-RateLimit-Remaining response headers on every request.
Those numbers are generous for publishing content and tight for anything that syncs constantly. If your architecture needs to write thousands of records from an external system throughout the day, you are not going to engineer your way around a per minute ceiling. That is a genuine platform boundary, and it is a fair reason to move the data layer elsewhere. Our piece on Webflow plan limits covers the wider picture.
Webflow's value is that a marketing team can ship without a developer. If your reality is that every content change goes through an engineer anyway, you are paying for a benefit you are not receiving.
This happens more often than teams admit. The template is complex, the CMS structure is fragile, and nobody trusts the marketing manager to touch it. So the visual editor becomes a slower version of a code editor.
Before you migrate, check whether the problem is the platform or the build. In our experience it is usually the build, and a rebuild inside Webflow costs a fraction of a migration off it. But if the workflow is genuinely developer led and always will be, a code first stack is a more honest fit.
For some teams, yes, and its published limits tell you which ones. Webflow Cloud documents a worker bundle size of 10 MB, 128 MB of worker memory per instance, 30 seconds of CPU time per request, a 20 second request timeout, a maximum cold start of 400 ms and 100 MB of compressed build output.
On data, it documents a SQLite database sized from 100 MB to 1 GB by plan, with 1,000 queries per invocation and a 30 second SQL query duration. It also lists 6 simultaneous outgoing requests, 1,000 subrequests per request, 10 environments per app and 100 environment variables.
Read those as a shape rather than a scorecard. That is a real application runtime with real headroom for a tool, a portal or a calculator sitting beside a marketing site. It is not a runtime for a data heavy product with long running jobs. Our overview of Webflow Cloud goes into what fits.
More than the rebuild, which is the part teams underestimate. The visible cost is design and development time to reach parity. The invisible costs are the integrations you rewire, the redirects you maintain, the editor training, and the six months where your marketing team is slower because the new workflow is unfamiliar.
There is also a risk cost that is real and hard to price. A migration is the single most common way a site loses organic traffic, and recovering it takes quarters, not weeks. That risk is worth accepting for a genuine architectural need. It is not worth accepting to satisfy a preference.
Our rule of thumb is that a migration should solve a problem that will still be a problem in three years. If the answer is that you will have solved it another way by then, do that instead.
Split the surfaces. Keep the marketing site in Webflow, where a content team can move fast, and build the application on its own stack at a subpath or subdomain. Connect them at the edges with shared design tokens and a shared navigation.
This gets you the thing people usually want from a migration, which is engineering control over the complex part, without giving up the thing they forget they will miss, which is a marketing team that can ship a landing page on a Tuesday.
It is not free. You now maintain two front ends and have to keep them looking like one company. But that is a much smaller ongoing cost than either extreme, and it is what we recommend most often when a team is genuinely at the boundary.
Treat the URL map as the primary deliverable, not an afterthought. Every existing URL either keeps its path or gets a permanent redirect to the closest equivalent. A spreadsheet of every old URL, its new destination and its status code is the artefact that decides whether the migration goes well.
Export the content properly rather than by hand. Webflow gives you routes out through code export and the Data API, and using them beats a copy and paste job that silently drops fields. Our notes on Webflow code export cover what you do and do not get.
Then watch the data for a full quarter. The full method is in our guide to migrating without losing SEO. The short version is that a migration is not finished on launch day, it is finished when the numbers come back.
We would ask what you are actually trying to do that you cannot do today, and then push hard on whether the platform is the reason. Nine times out of ten the honest answer is that the build needs work, and that is a much smaller project.
The tenth time, the answer is that you have quietly become a software company whose website happens to be attached, and we would tell you so. Splitting the surfaces is usually the right first move, and a full migration is usually the last resort rather than the plan.
If you want that conversation without a sales pitch attached, we are happy to have it. You can reach our team at phoenix.studio and we will give you our real opinion, including when that opinion is that you should not hire us to rebuild anything.
Tell us where you want to go. We'll tell you how we'd get you there.