Moving off no-code without stopping the business
What we learned from the migrations we ran this year
In this guide
- 01 · Decide part by part, not all at once
- 02 · Signs it's time
- 03 · The rule we set before launch: nothing should feel different
- 04 · Run the new next to the old
- 05 · Data you can trust
- 06 · Speed is part of the scope
- 07 · Test from where your users are
- 08 · Define "delivered", and what comes after
- One-page checklist
Who this is for. You built something on Xano, WeWeb, Bubble or with an AI coding tool. People use it. It works, mostly, but it's starting to feel like the tool is deciding what you can do next. This guide is what we'd tell you on a call, written down: how to decide what to move, how to move it while the business keeps running, and what tends to break along the way.
It's not a pitch for leaving no-code. Every one of the products we migrated this year reached real users on no-code first. That part worked.
01Decide part by part, not all at once
The most common mistake is treating a migration as one big move. It almost never needs to be.
Start with the part you change every week. That's usually the first part to feel the ceiling: it's where waiting on the visual editor costs you the most. In one of our migrations, the front end moved to code and the backend stayed in Xano, because it was doing its job.
Sometimes the answer is to integrate, not migrate. We worked with a business running two old systems nobody wanted to touch. The obvious plan was to replace both. What we did was connect only the part that hurt (invoicing) to their accounting system, and leave the rest alone.
No-code is a stage. One client moved from an old monolithic system to no-code tools, and months later moved again, to custom code, when no-code became the bottleneck. Neither move was a mistake. Each one bought the time the business needed at that moment.
Questions to answer before deciding:
- Which part of the product do you change every week?
- Which part, if it broke tomorrow, would stop the business?
- What would you need to rebuild if you left the platform: the data, the logic, or both?
Where does your app stand? Take the 2-minute test · or get this guide as a PDF
02Signs it's time
These are the signals we see over and over. One of them is a reason to look closer. Three of them is a reason to decide.
The product stops following the business. In our recent migrations this was the main reason to move, more than performance: with code, an agent writing it and one of us reviewing it, a change started shipping faster than the same change in the visual editor.
On one project, before adding more users, the app had to get faster. Speed wasn't a technical detail, it was the thing blocking adoption.
Records drift out of sync, totals don't match, someone fixes things by hand every week.
This is the one sign that can't wait.
Not being able to leave is the real lock-in, more than the price.
Where does your app stand? Take the 2-minute test · or get this guide as a PDF
03The rule we set before launch: nothing should feel different
When we rebuilt a bookings platform from scratch, the rule before launch was that nothing should feel different to the people using it. Same links, same steps, same way of working. We told the client the new system was not a sandbox: treat it with the same care as the current one.
A rewrite works when users don't notice it. The result we were after wasn't technical either: after the first full holiday season on the new system, the person who runs operations wrote to us that it was one of the first holidays ever where no group turned up at the wrong venue.
What this means in practice:
- Keep the URLs, the order of the steps and the names of things the same, even if you'd design them differently today.
- Change the inside first. Change the outside later, on purpose, as a separate project.
- Define the result in the business's terms before you start ("no group at the wrong venue"), not in technical ones.
Where does your app stand? Take the 2-minute test · or get this guide as a PDF
04Run the new next to the old
We never switch a system in production in one go. The pattern we use, conservative on purpose:
- 01Shadow
The new system calculates everything, but nothing it produces is used yet. It runs next to the old one.
- 02Witness cases
Pick two or three real cases you know well and compare the new results against the old system, by hand.
- 03Small switch
Let the new system write for real, but only for those few cases.
- 04Everything
Only then move the rest.
For a new module in another project, the pilot ran in parallel with the manual process for weeks before we cut over. Nothing changed downstream while both ran.
It feels slower. It's the reason the business can keep working while it moves.
Where does your app stand? Take the 2-minute test · or get this guide as a PDF
05Data you can trust
Assume the feed will miss things. On one launch, an inventory provider's webhook kept firing, but every stock movement came in with the location empty. We held the launch. Since then, the feeds in that system have two paths: the webhook as the fast one, and a scheduled job that asks the source directly and picks up whatever the webhook missed. Shopify recommends the same thing in its own docs: reconciliation jobs running next to webhooks.
Keep something to rebuild from. While the provider fixed their side, we kept going with a snapshot of every SKU, so there was always a known-good state.
Don't trust names. A replenishment scan once treated any location with a Z in its name as bulk storage. The warehouse used Z names for real pick locations too, and close to a thousand products started generating tasks they shouldn't. Rules based on naming conventions break the day someone uses the name differently. Store the meaning as data, not in the name.
Where does your app stand? Take the 2-minute test · or get this guide as a PDF
06Speed is part of the scope
For a tool a team opens all day, speed decides whether they actually use it. We treat it as a requirement next to the features, not something to fix later.
records on one task board in production, tested with a million without lag
- the list loads as you scroll instead of all at once,
- the queries the team runs most are cached,
- search runs on indexed fields,
- changes show up for everyone in real time, without a reload.
On a visual tool, these are often the things you can't control. That's frequently the moment a migration starts making sense.
Where does your app stand? Take the 2-minute test · or get this guide as a PDF
07Test from where your users are
One bug only happened in Australia. The date library decided "what day is it" using the timezone of the browser, so with Sydney's daylight saving a 10:15 session landed on the previous day, and the confirmation failed silently. For weeks we couldn't reproduce it from Argentina: the logs were clean.
What we do now:
- Decide which timezone owns each date (the business's, not the browser's) and store it that way.
- Test the flows that matter from the users' timezone and locale, not just yours.
- Make failures loud. A silent rejection costs more than an error message.
Where does your app stand? Take the 2-minute test · or get this guide as a PDF
08Define "delivered", and what comes after
Write down where the setup ends. On one project, every small request after launch turned into a negotiation, because nowhere did it say where the setup ended and new work began. We added one line to the agreement: the service is up and running within 72 hours, and changes after that are quoted separately. Those conversations mostly stopped.
Plan who changes things after launch. With code and an AI agent, a founder can make small changes themselves. We set this up for one client: every change they ask for goes into its own copy of the app, never straight to the one their users are on, and nothing reaches users until one of us has reviewed it. Writing the change got cheap. The review before anything goes live is what still needs us.
Where does your app stand? Take the 2-minute test · or get this guide as a PDF
One-page checklist
About us
We're Buildora Labs, a product studio for founders. We help you decide what to rebuild and what to leave alone, and we move a live business onto it without making anyone stop working. Fixed price for a defined result, never by the hour.
If you'd like a second pair of eyes on your stack, book a 15-minute call.
— Gonzalo Rodríguez, Buildora Labs
Take it with you
The full guide and the one-page checklist as a PDF, in your inbox. Gonzalo sends it himself; one click to unsubscribe.