Migrate from Bubble to Code

Migrate from Bubble to code you own when your Bubble.io app is live and Bubble has become the limit: the scope and the price of the rebuild are fixed before any code is written, from what your app already does. You describe the live app in the Forge, its pages, workflows and data types come back as features and stories, and the price follows. The rebuild then runs batch by batch next to the live app, users and data move as their own batch, and the switch happens when you say so.

Migrate from Bubble to code: a sample Forge blueprint of a live studio booking marketplace being rebuilt off Bubble, with the brief, the features and the locked estimate beside the scoping conversation (sample written for this screen)

Your Bubble app is the scope

A rebuild is usually quoted from a call and a range. Here the input is the app itself. You describe what it does in the Forge, page by page: the data types, the workflows, the plugins, the parts users rely on and the parts nobody opens. The blueprint comes back as features and user stories, with what is kept, what changes and the assumptions taken written down, so you read what the rebuild contains before it is priced.

It is not a 1:1 copy. A Bubble app accumulates workflows that exist because of Bubble; the blueprint says which ones go and which behaviors stay exactly as your users know them. The blueprint is yours whether or not we build it, and the price never moves in the background: add a feature or drop one, and the estimate follows in front of you.

The sample blueprint's features, including the users and data moved from Bubble as a feature of its own

A Bubble to code migration, batch by batch

The foundation ships first: accounts, roles and the data model, read from your Bubble data types. Then the features, in the order you set, each batch shown on a live preview with a five-day review window and acceptance criteria you can read per story.

Users and data move as their own batch, scoped in the blueprint as a data import: the export from Bubble is previewed and checked before anything is created, mismatches flagged, then the records created one by one. Bookings, orders, or whatever your app holds keep their dates and their status. Your Bubble app stays live until the switch, and the switch is one step at the end, taken when you say so.

A build in progress in the client portal: the request's stories with their acceptance criteria

How pricing works

The rebuild is priced from what your Bubble app does, not from a day rate: a fixed base for the foundation (accounts, roles, the data model read from your data types), then each story and each capability, the data import included, at the same rule for every blueprint. The range shows once you verify your email; send the blueprint, and the fixed quote and delivery plan arrive within one business day.

Each batch is priced before it starts: 30% to start it, the rest when it is done. Against a workload-unit bill that grows with usage, the rebuild is priced once; hosting afterwards is in your name, and nothing is billed by the hour. Something new that comes up during the rebuild is scoped and priced as its own request, and you decide whether it goes in.

When it is time to leave Bubble, and when to stay

Founders who want to migrate from Bubble to code name the same five triggers:

  • The workload-unit bill grows faster than revenue.
  • Pages slow down as the data grows, and searches that were instant are not.
  • A workflow runs into Bubble's timeout.
  • A feature does not fit what Bubble or its plugins can do.
  • An investor, an acquirer or a partner asks for the code.

Staying is an answer. If Bubble still fits, the blueprint shows the price of leaving before you decide, and that price can say wait. A Webflow, FlutterFlow, Softr or Glide app follows the same path: to rebuild a no-code app, the app is the scope.

Everything is yours at the switch

At the switch you own the code in your repositories, the hosting accounts, the data, and the reference documents: system map, runbook, handover and ownership. Nothing stays in a plan you rent.

Afterwards, two paths. Software Maintenance and Support Services describes the engagement that keeps the product running with one person answering for it. A founder who keeps shipping alone, each change asked of agents and priced on its own, chooses ITzWorking Agents.

Who it is for, and who it is not for

For

  • A live Bubble app with users and data, where the founder decides.
  • A founder who has hit one of the triggers above and wants the price before the decision.
  • An app whose next investor or acquirer asks for the code.

Not for

  • An app still validating its idea: stay on Bubble, or scope a new product on MVP Development Services.
  • A plugin-level fix inside Bubble, or a hybrid where we maintain the Bubble side.
  • A quote to migrate from Bubble to code without a scope: the blueprint comes first, always.

Questions founders ask

Can you export Bubble code?

No. Bubble has no code export; what you can export is the data, one file per data type, and your own description of the app. That is why the rebuild starts from what the app does, not from its source.

How do I get my app out of Bubble?

Describe it in the Forge, read the blueprint, send it for the fixed quote. The rebuild runs next to the live app, the data moves as its own batch, and you switch when the new app is ready.

What does a Bubble to code migration involve?

Reading the app into a scope, rebuilding the foundation and the features in code, moving users and data, and switching the domain. Each is a batch you see on a live preview.

Will the app go down during the migration?

No. Bubble stays live until the switch; the new app is built and reviewed beside it. The switch is a domain change after a last import of what changed since the previous one.

What happens to my data and users?

They move as their own batch, scoped as a data import: previewed and checked before anything is created, then created record by record. Users sign in to the new app with the same email; passwords do not export from Bubble, so every user sets up their sign-in again on the new app, scoped in the blueprint.

What is the rebuilt app written in?

TypeScript, front and back, the stack we run our own products on. The blueprint lists the foundation, the web application and the backend, before the quote.

Do I own the code afterward?

Yes, from the first batch: the repositories, the hosting and the accounts are in your name, and you can leave with everything.

How long does it take?

The delivery plan arrives with the quote, batch by batch. The foundation is on a live preview within days; the rest follows in the order you set, and the switch waits for you.

How a build runs

  1. You describe the product in the Forge. The blueprint lists every feature and what it needs.
  2. You shape the scope and the price follows it. You send the blueprint and receive the fixed quote and delivery plan within one business day.
  3. We build it batch by batch. Every request, choice and delivery is visible in your portal.
  4. At launch you get the code, the accounts and the documents. La Résidence can run it from there, as a separate engagement, or you take it over.

Who answers for it

Julien Casse, founder of ITzWorking. Shipping software since 2010: fintech in Luxembourg, then co-founder and CTO of kodehyve, from sole developer to a team of twenty.

He reads the code himself and makes the calls the model cannot. The client list is short on purpose: one named person answers for your product. Read more about the founder

Migrate from Bubble to Code