Bubble was probably the right call when you started. It got a real product in front of real users without a development team, and that is not a small thing. Plenty of businesses that exist today would not, if they had waited to hire engineers first.

The question is not whether it was a mistake. It usually was not. The question is whether it is still the right home for the thing you have now.

How do you know it is time?

Not by the tool. By what the tool has started deciding for you.

Performance stopped being fixable. You have already trimmed the workflows, cut the repeating groups and paid for more capacity, and it is still slow at the sizes you are hitting now.
The cost curve turned. Per-workload pricing that was trivial at a hundred users is now a line item you think about, and it grows with success rather than with effort.
A feature you need cannot be built. Not “would be awkward”: genuinely cannot, or only through a plugin nobody maintains.
You cannot get your data out in a shape anyone would want. This one is worth checking before you need the answer.
Hiring has stalled. You want a second developer and the pool of people who will take the job, on that platform, at that seniority, is thin.

One of these on its own is usually a reason to optimise. Three of them at once is a reason to move.

And when is it not time?

Just as often, the honest answer is stay.

If the product still fits comfortably inside what the platform does well, if growth has been steady rather than sharp, if the frustration is really about one badly built workflow that could be rebuilt in a week. Migrating is an expensive way to solve a cheap problem. We have told people this and lost the work. It is the right answer more often than the industry admits.

Does the whole thing have to be rewritten at once?

No, and it usually should not be.

The version that goes wrong is the one where a team disappears for five months, rebuilds everything, and turns the new system on in a single evening. Every assumption gets tested at the same moment, on real customers, with no way back.

The version that works is boring. You move one piece at a time, with the live product running throughout:

The data comes out first. Before anything is rebuilt, your data is exported into a real database with a schema that makes sense, and kept in sync while both systems run.
The heaviest thing moves next. Whatever is slowest or most expensive, usually a search, a report or a scheduled job. It moves behind an API and Bubble calls it. Users notice nothing except that it got faster.
Screens follow, in order of value. The new front end takes over one route at a time. Anything not yet migrated still comes from Bubble.
The last piece is the login. When everything else has moved, the old application goes read-only, and then off.

At every step there is a working product and a way back. That is the whole design goal.

What actually carries over?

More than people expect, and less than they hope.

Your data carries over, once it has been cleaned up. No-code schemas tend to accumulate fields nobody uses and relationships that were expedient at the time. Your business logic carries over as rules, though not as code; the logic was worth learning, and rewriting it in a real language is often where the bugs finally get found. Your design carries over cleanly.

What does not carry over is the platform’s own scaffolding: its workflow engine, its plugins, its hosting. That is the part you are leaving, and it is the part that has to be rebuilt.

What does it cost, and how long?

Anyone giving you a number before seeing the app is guessing. What we can say is what drives it: the number of distinct screens, how much logic sits in workflows rather than in data, how many third-party services are wired in, and whether anyone can still explain why the odd parts work the way they do.

Under a subscription it is a queue like any other. You are not buying a migration project with a fixed scope and a change-order process; you are paying monthly while the work happens, reprioritising as we learn what the app actually does, and stopping when it is done.

Where we come in

We have moved products off no-code platforms and onto their own stack, and we have also told people not to bother. If you want to know which one you are, the first call is twenty minutes and we will say plainly which we think it is, including when the answer is that Bubble is still fine.

If it is time, the work goes into your queue and runs like everything else: one thing at a time, in your priority order, with a live product the whole way through.

Migrating off Bubble without breaking what already works