Moving off Bubble

Usually one of four things. The app has outgrown the platform's performance or its pricing. The business needs something Bubble can't do, or can only do through a plugin nobody maintains. The developer who built it, often a freelancer, has moved on and nobody else will touch a Bubble editor. Or the board has asked who owns the system and didn't like the answer.

None of those is a criticism of Bubble. It got the business a working system without a development team, which is its job. The question is what happens next.

• The data. Every data type exports as CSV, and the Bubble API can pull records with their relationships intact. Files in Bubble's storage come out too. This is the valuable part, and it comes out cleanly.
• The design, as a description. Bubble can export a file describing the whole app: pages, workflows, data types, styles. It isn't code and it doesn't run anywhere else, but it's a complete map of what the app does.
• The workflows, as the specification. Every Bubble workflow is a business rule written out step by step: when this happens, do these things. That's precisely what a rebuild needs and precisely what most legacy systems don't have.
• The users, as records. Passwords don't travel; the new system starts with a reset or a fresh login.

Everything that runs. The pages, the workflows, the login, the file handling, the plugins' behaviour, the integrations. There's no shortcut, and anyone promising a one-click conversion is promising something Bubble doesn't allow.

What makes it tractable is the specification. A rebuild from a Bubble app knows what every page shows, what every button does and what every rule is, before a line is written. Most rebuilds spend their first weeks discovering that. This one starts with it.

1. Map it. The assessment reads the pages, workflows and data types, and writes them down as a system description with the rules made explicit.
2. Get the data out and check it. Every data type, every record, every file, reconciled against Bubble.
3. Design the new system from the map, on a mainstream web stack in your own accounts.
4. Build one process at a time, starting with the one that matters most, and run it in staging on the migrated data, checked by the people who use it.
5. Switch that process, with Bubble still running everything else, and the data kept in step until the next process moves.
6. Repeat until Bubble can be switched off. Each stage priced before you commit; stop after any stage with a working system.

No cutover weekend. Bubble keeps running until the last process has proven itself elsewhere.

It leaves Bubble once, checked, and never meets a change until the change has proven itself somewhere else. The migration is tested against a copy in a test environment, then run in staging with every data type and record reconciled against Bubble. Only when the tests have shown it's safe does anything connect to live, and Bubble stays running as a fallback until you're confident.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Bubble app it maps the pages, workflows and data types, extracts a sample of the data to see how it comes out, and prices the rebuild process by process as fixed numbers. What drives the price and the payment terms each have a page.

Treat the workflows as the specification and the data as the asset. Marc Allington has rebuilt systems from worse maps than a Bubble app gives you. Everything we build runs on open, widely used technology in your own accounts, with full source code and ownership transferring to you on final payment, so the next time the board asks who owns the system, the answer is you.