How long a migration off Bubble actually takes
The duration of a Bubble migration is set by how long you run both systems in parallel, not by how fast anyone writes code. Building the replacement is the predictable part. Reconciling it against the old system on real work, and cutting over one workflow at a time, is what fills the calendar and what keeps the operation standing.
Why is "how long will it take?" the wrong first question?
Because the answer depends almost entirely on a number nobody has measured yet: how much business logic lives inside the app. Ask the duration before the inventory and you get a guess dressed as a plan.
The inventory is four counts: workflows and their branches, external integrations, data types with their relationships, and permission rules per role. Producing it takes days. Skipping it costs months, because every unmapped workflow surfaces mid-project as a surprise, and surprises in a migration arrive with an operation attached to them.
There is a second reason the question misleads. Migration is not one duration, it is two: how long until the first workflow runs on the new system, and how long until the last one leaves the old. Teams quote the second and plan for the first.
What actually sets the schedule?
Four things, and only one of them is engineering.
The data model decision. Bubble documents CSV export and an API for your records, so extraction is solved. What is not solved is the schema. What arrives is Bubble's data structure, and rebuilding it unchanged imports the constraints you were trying to escape. Deciding which fields are real and which are residue of some workflow is the decision with the longest tail, because everything after it inherits the choice.
Integration count. Each external connection has its own authentication, sandbox, rate limits and counterpart who does not care about your timeline. Integrations are the most common source of a slipped date, and they are also the easiest to count in advance.
Parallel running. Both systems process real work while you compare outputs. This is the part teams try to shorten and the part that should not be shortened, for reasons below.
Approval latency inside your own company. Who signs off that the new number is the right number. This is invisible in every plan and present in every project.
How long does parallel running need to be?
Long enough to cover one full cycle of whatever your business does, including the cycle that only happens at month end or quarter end.
That is the practical rule, and it comes from what parallel running is for. It is not a soak test. It is the only mechanism that surfaces business rules nobody wrote down, and those rules tend to live in exceptions: the closing routine, the correction someone makes by hand every month, the customer with special terms.
Parallel running only earns its cost when you compare outputs. Pick the numbers the business already trusts, the ones in a report someone reads every week, and reconcile them between the two systems until they agree. Every disagreement is a specification you did not have. Running both systems without reconciling them is paying double for one system.
If the cycle that matters is monthly, you need at least one clean month, and realistically two: the first surfaces the differences, the second proves they were fixed.
Can you make it shorter?
Yes, in three ways, and none of them involve working faster.
Cut over per workflow, not per app. Move the workflows the business depends on first, and leave the rest running where they are. This shortens time to first value from the whole project to a few weeks, and it caps the damage of any single mistake at one workflow rather than the operation.
Delete before you build. Every workflow you retire is one you do not scope, build, test, reconcile or cut over. Migration is the rare moment when deleting is politically possible, and it is the largest lever on the calendar that exists.
Buy runway first. The most common cause of a rushed migration is a deadline set by a bill. Bubble's pricing FAQ documents that an app with overages disabled goes offline when it hits its workload limit, which is the kind of deadline nobody plans around well. In the Colo Saúde platform the first move was to stay: the app was stabilized on Bubble and its consumption cut by 60 percent, and only then did the rebuild on Next.js and Supabase begin. That sequence bought a calendar instead of a countdown.
The UniTrust brokerage system shows the other shape, where the work went toward a system built to hold the operation of a US insurance business. What decided each path was runway, which is the same variable that decides the schedule.
Frequently asked questions
Can we migrate over a weekend?
Only if the app has almost no business logic, in which case you would not be migrating. A weekend cutover assumes the new system is already correct, and correctness is exactly what parallel running establishes. Teams that skip it usually spend the saved weeks afterward, at a worse moment.
What is the longest part of a migration?
Usually reconciling the two systems, followed by the data model decision. Writing the code is predictable and rarely dominates. If a plan shows coding as the biggest block, the plan is missing the reconciliation.
Do we have to freeze changes to the Bubble app during the migration?
Not entirely, but every change made to the old system during the rebuild is a change that has to be made twice. Freezing the workflows already in flight, and letting the rest move, is the compromise that usually holds.
Next step
If you need a defensible date rather than a hopeful one, an Operational Architecture Diagnostic is a 30 minute conversation to size the inventory and the parallel run behind it. Book a conversation.
Read next
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No strings attached.
Book a diagnostic