Why AI agents get Bubble migrations wrong
AI agents get Bubble migrations wrong when they read the app's export as a blueprint. The .bubble file lists every page, workflow and field in the editor, but not which ones the business still uses, which credentials matter or who calls the app from outside. Those facts have to be settled before anyone writes the new code.
What does a Bubble export actually contain?
Everything the editor holds, and nothing that runs. Bubble lets you export your app as JSON, and its support article describes that file as optimized for importing into another Bubble application. Code does not leave: the ownership page states that Bubble apps run only on Bubble's platform, and records leave separately, as CSV or through the API.
Inside the file sit the pages, reusable elements, backend workflows, data types, option sets, plugins, styles and API Connector calls. They point to each other through generated ids instead of the names you see in the editor, so the meaning of one button can be spread across a page, a reusable element and a workflow somewhere else in the file.
That makes the export an excellent inventory and a poor blueprint. An inventory tells you what is on the shelves. A blueprint tells you what the building needs, and years of edits leave a lot on the shelves that the building stopped using.
Why does an agent reading it raw end up guessing?
Because the file never says what matters. A model has to infer it from references scattered across a large input, and that kind of inference is where the long-context models tested in 2025 were weakest.
The NoLiMa benchmark, published at ICML 2025, evaluated 13 language models that claim to support at least 128K tokens of context. At 32K tokens, 11 of them dropped below half of the score they reached on short inputs. The task asked them to connect facts that share little wording, which is close to what an export asks: a trigger and its target often share nothing but an id.
Developers feel this in daily work. In the 2025 Stack Overflow Developer Survey, the frustration with AI tools cited most often, by 66% of the developers who answered, was "AI solutions that are almost right, but not quite". In a migration, almost right is a workflow rebuilt that nobody used, or a business rule that quietly did not make it across.
Doesn't a bigger context window fix it?
No. The models in that benchmark advertise 128K tokens or more, and most of them lost more than half their short-input score at 32K. Models added to the benchmark later in 2025 did better, with GPT-4.1 scoring 79.8 at 32K against 97.0 on short inputs, but a bigger window only lets the agent read more of the file at once. It does not make the file say which parts are alive.
The missing information is not in the export at any size. Whether a page still gets traffic from an email, whether a payment provider still calls a webhook, whether a paid plugin still does anything: those are facts about how the app is used, and a definition file cannot carry them.
What does the export not tell you?
Three facts, and each one changes the scope or the risk of the rebuild.
What is dead. Pages nothing navigates to, workflows nothing triggers, plugins still billed on a paid plan. Rebuilding them is waste. Unreferenced is not the same as unused, though: every Bubble page has its own public URL, so a page with no internal links may be the one an email or an external sign-in sends people to.
Which credentials the app depends on. API keys and integration settings typed into the editor often exist nowhere else. A rebuild that finds them halfway through stalls on access nobody remembers granting.
Who calls the app from outside. Backend workflows exposed as endpoints, webhooks and Data API consumers keep calling the old app. The export shows what is exposed. It cannot show who depends on it, and a cutover that never listed those callers breaks them on the day you switch.
What should happen before anyone writes code?
The facts get settled first, by code that reads the export the same way every time, and people decide what to keep. Generation comes after, from documents you can check.
The order we run starts with an audit that lists what is unused in each area of the app, with a confidence level per item. The app is cleaned in Bubble and exported again. The as-is documentation then describes the database, the APIs, the workflows and the business rules in a form you can verify, and keeps every credential the export carries in a local .env file. The target architecture, the new data model and the migration plan come from that documentation, not from the raw file.
The build works from an atomic backlog with two gates: every requirement has a story, and every migrated column is read or written by the new code. On our projects, agents write code against those documents and an engineer decides what passes each gate, so the code starts from facts instead of filling gaps. We published this method, the one we use on our own migrations, as UnBubble, under an open-source license. UnBubble is an independent project, not affiliated with or endorsed by Bubble.
What does that look like in an export?
Take the fictional equipment-rental app we built for the UnBubble repository, since no client's export can be shown. Its export has seven pages. Leaving out the home page and the 404 page, which Bubble serves on its own, three have no internal navigation pointing at them. A reading that follows only internal references would mark all three as dead.
One of those three is the page an external calendar authorization returns to, reached through a link that carries its full URL instead of internal navigation. Deleting it breaks the calendar connection, so the audit keeps it and flags only the other two. The same export has six backend workflows: one that nothing triggers, one called only by that dead workflow, and one exposed as a public endpoint that another system may be calling right now. A paid plugin sits in the install list with no element using it.
None of this appears as a label in the file, and all of it changes the scope.
Client projects run into the same gap. When the Colo Saúde platform reached Yowpi from a previous vendor, it had no technical owner, and nobody could say what the real security posture of a system holding patient data was. The first project settled that question: our security audit scored the platform 7 out of 10, and the fixes took it to 10. The migration to Next.js, React Native and Supabase started only after that, and it is under way.
Frequently asked questions
Can't a coding agent just read the whole export?
It can read it, and it will produce something plausible. The file carries no signal of use, so the agent decides what matters by inference, and long inputs degrade inference. With verified documentation and a scoped backlog, the same agent works from facts instead of guesses.
Does this mean AI is the wrong tool for a Bubble migration?
No. Agents are useful for writing the new code once the scope is right. The mistake is letting an agent decide the scope from a file that was never meant to describe it.
What happens to the data itself?
Records do not travel in the export. They move by CSV or through Bubble's API, table by table, following the migration plan. Each table is reconciled before the switch, so the app owner can sign off on the numbers.
Next step
If your Bubble app runs an operation that cannot stop while it moves, the Operational Architecture Diagnostic is where we map what transfers, what gets redesigned and where the migration starts.
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 proposal in the first conversation.
Book a diagnostic