How to Migrate Off Bubble or Lovable Without Losing Your Users

The call usually starts the same way. "We built it on Bubble two years ago and now the bill is $349 a month and it is slow." Or "Lovable got us to a demo and now it loops every time we touch permissions." Either way the question is the same: how do we get off this thing without losing the users we already have?

I have done this migration enough times now that it has a shape. This is that shape: what comes with you, what gets rebuilt, the steps in order, what it costs, and when you should not do it at all.

First, be honest about what you actually have

The two platforms leave you in very different positions, and knowing which one you are in sets expectations for everything that follows.

If you are on Bubble, you have an app that exists only as configuration inside Bubble's system. There is no code export. There never has been. You can export your data as CSV, and you can look at your screens and workflows, but none of it runs anywhere else. That sounds bad, and in one sense it is, because it is the reason you are reading this. In another sense it is clarifying: there is no temptation to salvage code, so the migration is a clean rebuild from a very detailed blueprint.

If you are on Lovable, you can export real source code. People hear that and assume the migration is "just hosting it somewhere else." It is not. The code was generated by a model with no plan, so there is no separation between business logic and screens, the naming is inconsistent, error handling is missing in half the places, and it depends on Lovable's own helpers. Every developer I know who has been handed a Lovable export has said some version of the same thing: faster to rebuild than to refactor. I covered why in $2,400 a year on Lovable vs hiring a developer. The export is not your app. It is a very good description of your app.

What comes with you

More than people expect. Four things survive the move intact, and they are the four things that actually took you two years to figure out.

Your data. Users, records, history. It exports from both platforms, and it migrates into the new database once the new data model exists. Nobody loses their account.

Your screens, as a blueprint. Every screen in your current app is a finished, tested, user-approved specification. That is worth more than any document. On a normal project, working out what the screens should be is a third of the effort. You have already done it.

Your feature list, and the knowledge of which features nobody uses. Two years of real usage tells you exactly what to rebuild and what to quietly drop. Most migrations end up smaller and better than the original because of this.

Your users' expectations. They know how the product works. The new version should work the same way on day one and get better after. A migration is not the moment for a redesign.

What gets rebuilt, and why that is the cheap part

The parts that do not come with you are the parts that were always the problem: the data model, authentication and roles, payments, and the integrations. Those are also, not coincidentally, the parts that every app needs and that nobody should be rebuilding from scratch in 2026.

This is the whole reason the migration is affordable. In the lab, registration, login, password recovery, email verification, roles and permissions, payment processing, email delivery, and user management are already engineered and running in production across multiple platforms. We do not rebuild them per client and we do not charge for them. Your migration budget goes to the features that are actually yours, and the foundation your Bubble or Lovable app never had is included.

The one part that takes real thought is the data model. Bubble and Lovable both let you add fields and tables as you go, so after two years the data usually has a status stored in three places and totals calculated two different ways. The migration is the moment to fix that properly, and it is the part I spend the most time on, because it is the part that determines whether the new app is still clean in five years. I went deep on why in custom internal tools and dashboards: the schema matters more than the screens.

The migration, step by step

This is the order we run it in. The order matters, because the expensive mistakes all come from doing step four before step three.

1. Inventory the app. Every screen, every user role, every workflow, every integration, every place money moves. Screenshots of every screen. This takes a day and it is the specification for everything after.

2. Cut the feature list. Go through the inventory with your usage data and be ruthless. Anything nobody has touched in six months does not get rebuilt. Most apps lose 20 to 30% of their features here and nobody notices except the budget.

3. Design the data model first. Before any screen is built, the new database gets designed properly: what a customer, an order, or a booking actually is, how they relate, and what rules they obey. This is where the three versions of "status" become one.

4. Build on the core. Auth, roles, payments, and user management are already there. The engineer builds your actual features on top, using your existing app as the visual reference, and uses AI to move fast on the parts that are well understood. The difference from vibe coding is that the engineer can read what the AI produces and knows when it is wrong.

5. Migrate the data. Export from the old platform, transform it into the new model, import, and verify. This is scripted so it can be re-run, because you will run it more than once.

6. Run both in parallel. The new app goes live on a private URL. You and a few trusted users work in it alongside the old one for a week or two. Every difference gets logged and fixed.

7. Switch. Final data migration, DNS moves to the new app, old platform goes read-only. Users log in with the same credentials and see the same product.

8. Cancel the subscription. This is the step people enjoy. After a safe period, usually a month, the Bubble or Lovable plan gets cancelled and the monthly bill ends permanently.

What it costs, and what it stops costing

Let's do the math, because this is a financial decision more than a technical one.

A migration on a proven core runs $2,500 to $6,000 one time, depending on how many real features survive step two. Auth, roles, password recovery, payments, and user management are included at no cost because they already exist. A typical mid-sized app, four or five real features, lands around $3,000 to $4,000, which is the same range as building it clean in the first place. I put a full itemized example of that kind of quote in the Lovable post above: a booking engine, payments, notifications, and an admin dashboard, $3,000 total.

Now the other side. Bubble Starter is $29 a month, but an app with real users and two years of data is rarely still on Starter. Growth is $119 and Team is $349 a month, and workload unit overages sit on top. Lovable Pro is $25 a month for 100 credits, and a team that is still actively building is realistically at $100 to $200 a month in credits. Call it $1,400 to $4,200 a year, every year, for software you do not own and cannot leave with.

A $3,500 migration against a $200 a month platform bill pays for itself in about 18 months. Against $349 a month, in about 10. After that the software costs you hosting and nothing else, and it is yours.

The subscription math for Bubble specifically is in the top Bubble alternative for scalable web apps, and the broader argument about renting versus owning is in who owns your code.

When you should not migrate yet

I turn some of these calls down, and here is when.

You are still validating. If you do not yet know whether people want the product, stay on the platform. It is the cheapest place to find out, and a migration locks in a feature set you might throw away next month. Use the platform as the blueprint and migrate when the blueprint stops changing.

It is an internal tool for five people and nobody is paying for it. Bubble is a reasonable permanent home for that. The monthly bill is annoying but the migration would cost more than years of it.

The problem is a single feature, not the platform. Sometimes the wall is one workflow. That can occasionally be built outside the platform and connected to it. It is a patch, not a fix, but it can buy a year.

If none of those apply, if you have paying users, a feature list that has settled, and a bill that keeps climbing, then you are not early. You are late, and every month is another payment for a product you will rebuild anyway.

The short version

Export the data. Treat the old app as the blueprint. Cut what nobody uses. Design the database properly this time. Build the real features on a core where the hard parts already exist. Run both side by side, switch, cancel. Two to six weeks, $2,500 to $6,000, and then it is yours.

If you are earlier than that and still deciding whether to build on an AI platform at all, read can you vibe code a full app in 2026 first. And if you want every option laid out before you commit to any of them, that is in how to build an app as a non-technical founder.