Bolt.new migration, without losing your Bolt Database.
Bolt Database is a separate managed service from your exported code, and connecting a fresh Supabase project instead of claiming your existing one can cause data loss, by Bolt's own warning. We claim your data correctly, move your host, and cut your domain over on a written plan.
What is Bolt.new migration?
Bolt.new migration moves your app's code, database, and hosting off Bolt.new onto infrastructure you own. Bolt.new exports standard, portable React, Vite, or Next.js code through GitHub, so the frontend rarely causes problems.
The database is where migrations succeed or fail: an app already connected to external Supabase moves like any other Supabase project, while an app running on Bolt's own managed Bolt Database needs a specific claiming process, or a table-by-table export, to bring the data along safely.
- Claim, never connect
- Connecting a new database replaces the old one.
- GitHub is the history
- Bolt's own Version History stays behind.
- The domain stays
- The new host issues its own address.
- Secrets re-entered
- Nothing about environment variables carries over.
Three routes off Bolt.new, decided by your database setup.
Teams leave the platform through one of these, and which applies is rarely a preference.
| Route | What it delivers | Where it falls short |
|---|---|---|
| Already on external Supabase | A straightforward move, since the database already lives outside Bolt's own infrastructure. | Secrets and environment variables still need manual re-entry on the new host. |
| Bolt Database claim | Your existing rows brought over intact through Bolt's official claiming process. | Requires Supabase organization owner permissions to complete. |
| Migration + host change | Code, database, and hosting all move together, onto Railway, Vercel, or another host. | Your domain needs a deliberate DNS cutover, since it never travels automatically. |
What comes out of Bolt.new, and what needs a deliberate step.
Five pieces make up every Bolt.new app. Each moves differently.
| Piece | Comes out how | What to watch for |
|---|---|---|
| Code | Exports to GitHub, as standard React, Vite, or Next.js. | Only GitHub commit history travels; Bolt's own Version History stays behind. |
| Bolt Database | Claimed into your own Supabase organization, or exported table by table. | Connecting a new Supabase database first replaces the connection and risks data loss. |
| External Supabase | Already yours; just needs reconnecting at the new host. | Confirm the connection string and keys are set correctly on the new environment. |
| Secrets & environment variables | Not carried over automatically to a new host. | Every key needs re-entry, confirmed against your host's dashboard. |
| Domain | Stays with Bolt; the new host issues a new address. | DNS cutover needs its own planned step, not an afterthought. |
Why claiming beats connecting a new database.
The one irreversible mistake in a Bolt.new migration, and which route applies to you.
Bolt's own documentation warns that connecting a new database may cause data loss
Connecting a new Supabase database to a project that already has a Bolt Database replaces the existing connection. Claiming the current database into your Supabase organization instead preserves every row, so we always check which database your project actually runs before touching anything.
External Supabase, or Bolt Database?
You're on the easier route if your project connects to a Supabase project you set up yourself. You need the claim process if your project uses Bolt's own included database and you never connected an external one.
Why teams move off Bolt.new.
The platform that got your prototype running fast is not always where you want to run it long-term.
Your own Supabase org
Full dashboard and billing control, directly.
Any host you like
Anything that builds from GitHub, not just Bolt's hosting.
Your own policies
Scaling, backup and region set by you, not Bolt's defaults.
No platform-specific ties
Off features bound to Bolt’s own infrastructure.
A clean host change
Domain and hosting moved without disturbing data twice.
A clear answer for buyers
Where your infrastructure actually lives, in a sentence.
Migration work founders bring us.
We scope the migration around your actual database setup, not a generic checklist.
Migration assessment & fixed quote
A review confirming your database type, GitHub connection, and integrations, ending in a written plan.
Bolt Database claim
Your existing database claimed into a Supabase organization you own, with every row verified.
Code export & host provisioning
GitHub confirmed as source of truth, then your new host connected and configured.
Secrets & environment setup
Every key and environment variable re-entered and tested on the new environment.
Domain & DNS cutover
A planned switch from your Bolt address to your own domain, on the new host.
Verified handover
Every flow tested on the new stack, with documentation of what moved and how.
Signs you should migrate off Bolt.new.
Four situations send most founders to us.
- 01
You want your own Supabase organization
Direct billing, scaling, and region control matter more than Bolt's managed defaults.
- 02
You're changing hosts
Railway, Vercel, or AWS fits your team's workflow better than Bolt's own hosting.
- 03
You're on Bolt Database and worried about it
Nobody has confirmed the safe way to claim that data before making any other change.
- 04
You need a domain cutover done right
A launch or rebrand means the DNS switch has to happen without downtime.
Common migration mistakes we help you avoid.
These five mistakes account for most Bolt.new migrations that go wrong.
Connecting a new Supabase database first
CriticalThis replaces your existing Bolt Database connection and risks data loss. We claim the existing database before anything else touches it.
Assuming Version History travels
HighOnly GitHub commits carry a change history forward. We confirm GitHub sync before exporting.
Forgetting the domain stays behind
HighThe new host issues its own address. We plan DNS cutover as a dedicated step.
Attempting a claim without org-owner access
CriticalClaiming a Bolt Database requires Supabase organization owner permissions. We confirm access before starting.
Skipping secrets on the new host
MediumEnvironment variables never carry over automatically. We verify every key before testing anything else.
How we run your migration.
Six stages, from assessment to a verified handover. We keep you informed with full visibility throughout.
Migration assessment
We confirm your database type, GitHub connection, and integrations, then quote a fixed price.
2–4 days · AssessmentDatabase claim or connection
We claim your Bolt Database into your own Supabase organization, or confirm your existing external project.
3–7 days · DatabaseCode export & host setup
We confirm GitHub as source of truth and provision your chosen host.
2–5 days · ExportSecrets & environment configuration
We re-enter and test every key and environment variable on the new host.
2–4 days · SecretsStaging verification
We test every flow against the new database and host before touching production.
3–7 days · VerificationDomain cutover & handover
We switch DNS on a written plan, keep a rollback ready, and hand over documentation.
1–2 days · Go-liveBolt.new migration cost and timeline.
Three factors drive the price: whether you're claiming a Bolt Database or already on external Supabase, how many integrations you run, and whether the host is also changing. Supabase, hosting and domain costs are billed separately by those providers.
- Investment
- $2,500–$6,000
- Timeline
- 1–2 weeks
- Database
- Already outside Bolt's infrastructure
- Move
- Code export & host provisioning
- Secrets
- Configured & tested
- Investment
- $6,000–$14,000
- Timeline
- 2–4 weeks
- Database
- Claimed into your Supabase org
- Data
- Full verification
- Testing
- Integrations retested end to end
- Investment
- $14,000–$28,000+
- Timeline
- 4–8 weeks
- Scope
- Database claimed, hosting moved
- Domain
- DNS cutover managed
- Team
- Dedicated migration team
The tools behind your migration.
Bolt's own claiming tools, standard Supabase tooling, and hand verification everywhere else.
Supabase
Vercel
AWSWays to work with us.
Every migration starts with an assessment, so you know your tier before committing to anything.
Migration Assessment
A written plan and fixed quote based on your actual database setup.
Always the first stepFixed-Scope Migration
A defined project matched to your external-Supabase, claim, or host-change tier.
Best for a planned moveMigration + Audit
A migration paired with our AI App Audit, fixing security gaps during the move.
Best value on securityPost-Migration Retainer
Ongoing development on your new, independently owned stack.
Best after cutoverEvery migration comes complete.
No hidden gaps. Each migration includes everything you need to run independently afterward.
- Written plan
- A technical review with a fixed quote before any build begins.
- Safe database claim
- Your Bolt Database transferred without overwriting existing data.
- Code export
- GitHub confirmed as source of truth before anything else moves.
- Secrets configured
- Every key re-entered and tested on the new host.
- Domain cutover plan
- DNS switched deliberately, with a rollback ready.
- Staging tests
- Every flow verified before production is touched.
- Written handover
- Documentation of what moved and how it's configured.
- Full ownership
- Supabase organization and hosting under your own accounts.
Bolt.new migration across every product stage.
The assessment stays the same. The tier changes with your database setup and host choice.
Growth-Stage SaaS
Products ready to own their infrastructure directly.
Compliance-Bound Products
Apps needing a specific region or self-hosting setup.
Pre-Funding Startups
Teams preparing for technical diligence on infrastructure ownership.
Agencies Handing Off Client Apps
Client-owned infrastructure delivered cleanly at project close.
Design-Led Teams
Figma-to-code projects moving onto infrastructure they control.
Teams Changing Hosts
Products moving to Railway, Vercel, or AWS for their own reasons.
Non-Technical Founders
Teams who need a partner to manage the whole move safely.
Acquired Products
Newly acquired Bolt.new apps moving under the buyer's infrastructure.
Explore more Software Development services.
Bolt.new Migration pairs naturally with these services from Hoop Interactive.
Bolt.new Development
Building and extending on the Bolt.new platform.
ExploreBolt.new App Rescue
When the app is broken rather than ready to move.
ExploreBolt.new to Production
Launching an app that has not gone live yet.
ExploreLovable Migration
The same move, off Lovable Cloud.
ExploreBase44 Migration
The same move, off a non-exportable backend.
ExploreVibe Coded App Migration
Platform-agnostic migration across every AI builder.
ExploreAI App Production Readiness Audit
The security review worth folding into the move.
ExploreCloud Infrastructure Setup
The infrastructure a host change lands on.
ExploreBolt.new migration questions
The questions founders ask us most before starting a migration.
Bolt.new migration moves your app's code, database, and hosting off Bolt.new onto infrastructure you own. The work depends on which database your project uses: an app already connected to external Supabase moves easily, while an app on Bolt's own managed database needs a specific claiming process to bring the data with it.
No, not automatically. Bolt Database is a separate managed service from your exported code. To take the data with you, you either claim the Bolt Database into your own Supabase organization, or export each table individually as CSV or JSON files.
Claiming transfers your existing Bolt Database into a Supabase organization you own, keeping your data intact. Connecting a new Supabase database instead replaces the current database connection, which Bolt's own documentation warns may cause data loss, so the two options are not interchangeable.
No. Your published Bolt.new site, whether on a bolt.host address or a connected custom domain, does not travel with the exported code. The new host issues a new address, so we plan the DNS cutover as its own step before your old and new deployments swap places.
No. Only GitHub travels. Bolt's own Version History stays inside Bolt, so if you want a change history on your new host, your project needs to already be connected to GitHub before you export.
Bolt.new migration costs $2,500 to $28,000 or more, depending on your database setup. A migration for an app already on external Supabase costs $2,500 to $6,000, a Bolt Database claim and full migration costs $6,000 to $14,000, and a migration that also changes your host costs $14,000 to $28,000 or more.
A migration for an app on external Supabase takes 1 to 2 weeks, a Bolt Database claim and full migration takes 2 to 4 weeks, and a migration paired with a host change takes 4 to 8 weeks.
Yes. Bolt.new exports standard React, Vite, or Next.js code through GitHub, so it deploys to Railway, Vercel, Netlify, AWS, or any host that builds from a GitHub repository.
Bolt.new to Production launches an app that hasn't gone live yet, choosing a hosting path and hardening it before launch. Bolt.new Migration moves an app already running on Bolt.new's infrastructure onto a stack you own, whether or not it has launched.
We evaluate them case by case. Automated tools can speed up discovery and database transfer for straightforward projects, but Bolt Database claims, secrets, and domain cutover still need a deliberate, verified process.
Yes. Your Supabase organization, database, repository, and hosting account all sit under your own name, and we hand over documentation of what moved and how the new environment is configured.
No. Migrations run as fixed-scope projects. Any ongoing support afterward works month-to-month with no long-term lock-in.