What "migrating" can mean
When someone tells us they want to migrate off Bolt, we have learnt to ask which of four things they mean, because each leads somewhere different.
The first is moving the hosting. The app keeps its code and its data and simply runs somewhere else. This is the smallest move, and for a static front end it can be an afternoon.
The second is moving the backend: the database, the user accounts, the uploaded files, the functions that run on a schedule. This is where the real work lives, and it is the one most people mean.
The third is owning the process: being able to change the app without Bolt's editor, through a repository, a review and a deployment you can explain to someone else. This can be done while the app still runs on Bolt, and it is often the right first step.
The fourth is a rebuild. Sometimes the generated code has drifted so far from what the business needs that starting again, with the old app as a very precise specification, costs less than untangling it. A few builders offer no code export at all, which makes this the only route.
Which of these is yours? It is worth answering before reading on, because the cost and the timeline differ by an order of magnitude between the first and the fourth.
Why building on Bolt was a reasonable call
A year or two ago the choice was between a builder that could produce a working app in a weekend and a development quote that started at five figures and ended months later. Picking the weekend was sensible. The app exists, it has users, and those users have taught you things about the business that no specification would have. That knowledge is worth more than the code, which can be rebuilt.
The feeling that comes with outgrowing a builder tends to be a kind of embarrassment, as if the right move had been obvious all along. From where we sit it looks like a good decision that has done its job, which is what early decisions tend to do.
What usually moves cleanly
The code is the easy part. On most builders, Bolt among them, the front end can be synced to a repository or downloaded, and what you get is an ordinary web project in a mainstream framework. A developer can usually have it running on a laptop within the hour. The database schema usually comes along as migration files, which are the recipe for recreating the tables rather than the tables themselves.
The design can stay where it is. One approach we use often is to keep the builder as the design surface, so the people who made the app keep making its screens the way they are used to, while the backend becomes something you own. The builder's backend is replaced by a mock inside the editor and by the real thing in production.
What needs its own plan
State is the hard part, and three kinds of state in particular. User accounts come first: if people sign in with a password, the hashes live in the builder's authentication service, and whether they can move without everyone resetting their password depends on the platform and on that service. Uploaded files come second: they sit in a storage bucket that no code export touches. Secrets come third: the API keys for email, payments and AI models are kept out of every export on purpose, which is correct, and which means someone has to collect them.
Then there is everything Bolt connected for you. A webhook from a payment provider points at a URL on Bolt's domain. A scheduled job runs on Bolt's scheduler. Each of these is small on its own and easy to miss as a group. We keep a one-page list for every migration, and it is usually longer than the client expected and shorter than they feared.
The questions worth asking before launch day
Security is the part that generated apps tend to get wrong in the same few ways. An automated scan of about a thousand AI-generated apps across Lovable, Bolt, Replit, Vercel and others, published by Stefan Lederer of securityscanner.dev in April 2026, reported that 183 of its 190 critical findings were misconfigured row-level security on Supabase databases, which in practice means any signed-in user can read other users' rows. The same scan flagged 38 apps with API keys sitting in the JavaScript bundle, and a few API endpoints with no authentication at all. One scan is one scan, and the figures will have moved since it ran. The pattern, though, matches what we find when we open a generated codebase for the first time.
Three checks cover most of it, and none of them needs a migration to run: searching the loaded JavaScript for the word "key" in the browser's developer tools on the live app, signing in as one user and trying to fetch another user's record by changing an ID in the address bar, and listing every API route the app has and asking, for each one, who is allowed to call it. If those three come back clean, the app is in better shape than most. If they come back with findings, it is better to know while the app is still on Bolt than on the first morning it is on infrastructure you are responsible for.
What leaves Bolt with you
Bolt, made by StackBlitz, gives you two ways out, and in our experience most teams end up using both. From the project menu you can export the whole project and download it as a zip, which is the quickest way to see what you actually have. You can also connect the project to a GitHub repository, after which Bolt and the repository stay in sync in both directions. The sync is worth understanding before you rely on it: Bolt checks GitHub every 30 seconds for changes made outside Bolt and pulls them in, and in the rare case that both sides change at nearly the same moment, Bolt shows a conflict message, pulls in the newer GitHub version and asks whether to apply your last Bolt change on top of it or keep GitHub's version as it is. If a developer is going to work in the repository while someone keeps prompting in Bolt, it helps to agree who edits what.
What comes out is a normal web project. If Bolt generated backend logic for you, it is in the export too, usually as a small Node server with API routes for each feature, and a database layer talking to Supabase or to Bolt's own cloud database. Mobile projects come out as Expo apps.
Two things do not travel. Secrets are kept out of the export and out of GitHub on purpose, so your Supabase URL and keys, and any OpenAI or payment keys, have to be written into a local environment file by hand. And the data itself lives wherever the database was: in your own Supabase project, where it already belongs to you, or in Bolt Cloud, which needs an export of its own before the Bolt subscription ends.
The practical sequence we would suggest is the one Bolt's own structure implies: connect GitHub first, confirm the repository builds on a laptop with the secrets filled in, and only then decide where the database should live next.
How we tend to approach it
Our default, when a client wants to own the result, is a Go backend on PostgreSQL, deployed to a cloud region in Singapore, with the builder kept as the place the front end is designed. Go and Postgres are boring in the best sense: most developers you hire later will know them, and both are easy for an AI assistant to read and change, which matters more now than it did two years ago. The front end keeps a mock data mode so the builder's editor still works, and a real mode that talks to the new API. The cutover happens once the real mode has run alongside the old backend for long enough that nobody is nervous.
We still get the timing wrong on one part more than any other: user authentication. Moving accounts is rarely hard technically, and it is almost always the step that produces the support emails. We now plan for a week of those where we used to plan for a day.
A scene, to make it concrete
Picture a nine-person logistics firm in Jurong. The operations lead built a delivery-tracking app on Bolt over two weekends, and the drivers have used it every day for eight months. The trigger for the conversation is a tender: a prospective customer's security questionnaire asks where the data is stored and who has access to it. The honest answer involves a vendor's data centre in another country and an admin login shared by three people. The app is doing its job, and the questionnaire now needs an answer the current setup cannot give.
In that situation the migration is mostly the second kind: move the data and the accounts to a database in Singapore, put the API behind a login with roles, and leave the screens exactly where they are. The drivers would not notice anything, and the questionnaire would get a different answer. The firm is hypothetical; the shape of the situation is one we have met more than once.
Questions to take into your next conversation
- What changed, specifically, that made leaving Bolt feel necessary this month and not six months ago?
- Which part of the app do you change most often, and who changes it?
- Where does the data live right now, and who could answer that without checking?
- If Bolt's editor disappeared tomorrow, what would you miss most?
- Who will get the alert when the app is down at two in the morning?
If it would help to think these through with someone outside the team, we offer a short discovery call for exactly this, and we are glad to say if staying put is the better answer.
Leaving a different builder? Emergent · Lovable · Replit · Riff · Zite