How not to migrate your Bubble app to code

Hey everyone!

We’ve been working on migrations to code for complex Bubble apps for some time now. A large number of our clients come to us after having tried to do it themselves, and getting stuck. Others have been able to do it largely independently and successfully.

I wanted to share that experience, as I’m seeing lots of applications going down the wrong path and wasting a lot of time and money in the process.

I’m not going to dwell too much on the reasons why people migrate from Bubble. Everyone is different. There are definitely bad reasons to migrate, but good ones include:

Migrating your app initially feels very fast and refreshing. All of a sudden, you can prompt something into existence! Database tables are easy to create and suddenly you’re on your way.

But is a bit misleading. Most Bubble apps don’t need to migrate to code, but the biggest reason they do, more so than any Bubble limitations, is that they were badly built in the first place. So, when you try to automate a coded migration with your ‘Bubble JSON’ and some skills, the new app has exactly the same technical debt that you’re migrating away from Bubble from.

It’s interesting to me that there are a lot of founders that are aware of the consequences of technical debt and not fully understanding their app (they come to us to sort it out for them).

A good chunk of them would’ve been able to straightforwardly resolve their issues in Bubble and scaled without ever having a need to migrate!

Once they do migrate, they inevitably find that they’re hitting bugs, performance issues, and don’t understand how their app works. All they have achieved is moving their tech debt to a different stack, rather than actually resolving it.

When you see on LinkedIn and X the people saying ‘I migrated my Bubble app to code in two weeks!’, they’re actually one or more of the below:

I will preface this by saying that ‘right’ way is not the quickest way (or the cheapest way, if you’re working with other developers). But it will have the highest return on investment (whatever that investment is for you).

As a Bubble founder, you only get one opportunity to completely rebuild your app, and kill technical debt. That time is when you migrate to code. Why would you throw away that opportunity just for the convenience of vibe coding it?

A good migration treats the Bubble app as a product spec, not a technical spec. Your Bubble app is very different from what it was when it launched, and its technical design likely hasn’t kept up. By treating the Bubble app as a guide for how it should work for the end users, it lets you redesign the technical side in the right way. In other words, you can redesign your application for what it has become, rather than what it was when you first built it.

Now, as part of this, I would avoid giving your agent access to the Bubble app JSON (or Buildprint workspace).

But George?! Isn’t that what I pay Buildprint for?!

Maybe. If you are, you probably shouldn’t because it’s doing you more harm than good. If you’re going the route of trying to migrate everything 1:1, including your tech debt, and kill your app in the process, then sure.

But if you want your new app to be built well and be a maintainable foundation for future business growth, I suggest you do it the right way.

When you give an agent access to your Bubble source code, it tends to assume that the way something is built in Bubble is the way it should be built in code. Even if you say ‘ok, don’t treat this as spec, just product guideline’, just by seeing the source code, it will naturally want to preserve what is there rather than redesign from first principles.

The exception for this is when building data migration functionalities where naturally it’s helpful to use Buildprint or something to read the database structure and grab database data. But for most app logic, an agent should not be aware of how your app is built.

Cut the fat on your Bubble app if you can. There’ll be some features in every application that you built but nobody actually uses. Why migrate it at all? It’s extra effort and complexity. This could be true for small features, or entire modules.

A lot of founders worry that they need to maintain 1:1 parity, but the reality is you can convince most users to migrate if on the whole things are better. Designing features specifically for individual customers that most people don’t use is a habit you need to get out of anyway.

Perhaps the easiest way to think about it is this:

If I were starting my app over knowing everything I know today, what would I build?

Build that.

Short answer; yes. The long answer is ‘yes, but…’.

The realities are that some people don’t care about the technical quality/doing it the right way, and will still waste a ton of time and money without even succeeding. We’ve seen one team spend weeks to build a compiler to translate their Bubble app (and they’re far from alone in this)!

Buildprint will be able to migrate your app to code in an automated way. Again, I don’t think that’s the right option for most people, but recognise that lots of apps aren’t able to take the option of doing it right because it takes too much time or costs too much money.

I’m not going to try and help you to decide whether to migrate or not (that’s best reserved for a different newsletter post). But, I can at least give you your options.

If you want the highest chance of success, and to put your app and business on a path to sustainable future development and business growth, then rebuild from scratch, from first principles. Design your app for what it has become. Don’t blindly copy Bubble logic. Read every line of code and understand how your app works.

One of our clients processing $50 mil+ through Bubble didn’t read code at all, but by working with us they’ve been able to take advantage of our experience whilst utilising their internal team for primary development. Throughout the process, they’re learning how their app is built so they don’t need to replace their team after moving to code and can ensure the app scales to support their hundreds of thousands of users from day one.

If you don’t care about the technical quality of the migration, then I’d wait a couple of months, as Buildprint will soon migrate it 1:1 for you. It’s likely that Buildprint will have both an automated and white glove offering, where automated does it the quickest and you can do it all yourself. White glove would take a more careful approach to migration and resolve the technical debt rather than migrating it one to one.

If you think you’ll be wanting to use the Buildprint migration tooling, then do drop me a message so I can add you to a waitlist.

Have a great week!

George