How to Migrate a Website From Bolt.new to Vercel

To move a website from Bolt.new to Vercel without breaking anything, you work in one direction: code first, domain last. Export the project into a GitHub repository, prove it builds on your own machine, create a Vercel project pointed at that repository, paste in your environment variables, deploy to the temporary vercel.app address, and only when that rehearsal passes every check do you point your real domain at it. Done in that order the move carries no downtime, because the old site keeps serving visitors the entire time, and no lost work, because the code Bolt generated is ordinary code that travels with you. This is the execution manual: the exact sequence, the two or three settings that trip people up, and how to keep your search rankings intact while you switch.

If you are still deciding whether to leave the builder at all, the signals, the limits you are running into, and the case for owning your own codebase live in the companion piece, leaving Bolt.new for Vercel. Everything below assumes that decision is already made and you simply want the move done cleanly.

The short version

Go code first, domain last. Get the project into GitHub and onto Vercel's temporary URL before you touch DNS. The domain is the final switch, not the first.
Prove the build twice. Once on your machine, once on Vercel's preview address. A migration only becomes risky when you skip the rehearsal and let customers be your test.
Secrets do not travel by themselves. Bolt set your keys behind the scenes; outside it you list them and paste them in yourself. A forgotten key is the number-one cause of a site that builds but misbehaves.
The domain cutover is a DNS change, not a leap. You point records at Vercel only after the temporary site is perfect, so there is never a moment your visitors see something broken.
Traffic needs the same care as a house move. If the site already ranks, keep URLs stable, redirect the ones that change, and carry your titles over so Google follows you to the new address.
After the move, editing gets cheaper and safer. Every change becomes a branch, a preview link, and a merge, reviewable and reversible, instead of a draw against a token balance.

What do you need before you start?

Gather these five things before you touch anything, and the whole migration becomes an hour of calm clicking rather than a scramble for logins you cannot find:

A GitHub account. Free, and the permanent home for your code from here on. This is the thing that turns a project you rent into files you keep.
A Vercel account. Also free to open. You will connect it to GitHub a few minutes from now.
Every secret the site uses. API keys, database connection strings, and any service credentials, collected somewhere safe so you can paste them without hunting mid-migration.
Access to your domain's DNS. The login for wherever you bought the domain, since the last step edits its records to point at Vercel.
Node.js installed, or a developer beside you. A lot of this works in the browser, but a local Node install lets you confirm the site builds before the public ever sees it, and that one habit prevents most failed moves.

Tick all five off before Step 1. When a migration stalls, the cause is almost always one of these discovered missing halfway through, at the least convenient possible moment.

How do you move a Bolt.new project to Vercel, step by step?

Eight moves, in order. None is difficult on its own; the whole safety of the process comes from keeping them in this sequence and not jumping ahead to the domain.

Export your code to GitHub. A Bolt project is real, standard code, and there are two ways to take it with you. The cleaner path connects the project to GitHub and pushes it to a new repository, which hands you proper version history from the first commit. The alternative downloads the project as a folder and you create the repository yourself. Either way the destination is identical: a GitHub repository holding your project. If you took the folder route, three commands do it:

cd your-project
git init
git add .
git commit -m "Initial import from Bolt.new"
git branch -M main
git remote add origin https://github.com/your-name/your-site.git
git push -u origin main

Build it on your own machine. This is your safety net, so treat it as mandatory. Install the dependencies, run it locally to click through, then run the production build, which is the real exam:

npm install
npm run dev      # opens the site locally so you can click through it
npm run build    # the real test: does it build for production

A clean npm run build means you are in good shape. If it complains, the message almost always points at a missing dependency or an absent secret, both quick to fix and far better found here than in front of a customer.

Inventory your environment variables. Most sites lean on a small handful of secrets: an API key, a database URL, perhaps credentials for a service like Supabase. Inside Bolt these were wired up invisibly. Outside it, you own them, which means writing down each key and its value in a list you will use twice in the steps ahead. Locally these live in a .env file that never gets committed to Git.
Create a Vercel project from the repository. In Vercel, add a new project and import the GitHub repository you just pushed. For the common stacks, Vercel reads the code and recognizes the framework on its own, so this step is mostly confirming what it already detected rather than configuring from scratch.
Match the build settings to your framework. For a Vite site, the kind Bolt most often produces, the build command is npm run build and the output directory is dist. For a Next.js site, Vercel detects the framework and asks for no output directory, since the two are made by the same company. One detail catches single-page sites: if a visitor reloads a deep link like /about, you want the server to return your app instead of a not-found page. A tiny vercel.json at the project root handles it, and Vercel's own rewrites documentation covers the general pattern:

{
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}

Add your secrets to the Vercel project. Take the list from Step 3 and enter each key into the project's environment-variable settings, named exactly as the code expects. Case and spelling matter here; a key entered as API_KEY when the code reads VITE_API_KEY is invisible to the app and produces a build that runs but quietly fails to do its job.
Deploy to the temporary URL and rehearse. Trigger the first deployment and Vercel hands you a temporary address ending in vercel.app. Treat it as a full dress rehearsal on a real stage. Click through every page, submit each form, confirm that anything talking to an outside service still answers, and open it on your phone. Because your domain is not pointed here yet, your live site stays completely untouched while you poke at this one.
Point your domain at Vercel, last. When the temporary URL behaves exactly the way you want, add your real domain in the project's domain settings. Vercel shows you the DNS records to set, and you enter them at your domain provider. The switch happens cleanly at the DNS level, and once it propagates your domain serves the new site. Because you flip this only after the deployment is proven, there is never a window where the site is broken. From a visitor's chair, nothing happened.

What should you check before flipping the domain?

Step 8 is irreversible in the sense that it changes what the public sees, so hold a short green-light review first. Every box below should be ticked on the temporary URL before you touch DNS:

Every page loads, including the deep links you reach by typing a path directly rather than clicking to it.
Every form submits and its result lands where it should, an email arrives, a record is created, a confirmation shows.
External services respond in production, not just locally: payment test calls, database reads and writes, any third-party API.
The phone view is clean, because a meaningful share of your visitors will only ever see that one.
No console errors on a normal walk through the site, which usually surface a secret you missed in Step 6.

If all five hold, the domain switch is the boring, safe step it should be. If any one wobbles, fix it while the live site is still calmly serving from Bolt, which is exactly the freedom this order buys you.

How do you protect your Google rankings during the move?

If the site is brand new with no search traffic yet, skip this section with a clear conscience. If it already earns visits from Google, the move deserves the same discipline as changing a shopfront's address: you tell everyone where you went. Keep your URLs identical wherever you can, because a URL that does not change needs no forwarding at all. For any address that must change, set a permanent redirect from the old path to its closest new match, so both people and search engines land where they expected. Carry your existing page titles and meta descriptions across rather than letting framework defaults overwrite them, and submit your sitemap afterward so Google recrawls the new home quickly. Google's own site move guidance lays out the redirect and sitemap steps in detail, and it is worth ten minutes.

The discipline here is identical to the one we walk through for store migrations in moving without losing your SEO, and the fuller playbook, including how long to leave redirects in place, is collected in our guide to migrating a platform without losing search rankings. The difference between a smooth move and a traffic dip is almost never the hosting; it is whether anyone bothered to forward the addresses.

What does maintaining the site look like after the move?

This is the quiet reward, and it changes the economics of every future edit. From here on, changing your site follows one loop: create a branch, make the edit, and Vercel automatically builds a preview deployment with its own private link, so you see the exact change live before a single visitor does. Approve it, merge the branch, and it ships to production. With a developer working in that loop, using Claude to write and refine the code and Git to record every version, a new section or a bug fix is a few minutes of focused work and a push, not a negotiation with a meter. Every change is reviewable before it lands, reversible after it lands, and permanently yours.

That property, cheap and safe iteration, is what keeps a site from silently rotting, and it is the practical antidote to the slow accumulation we describe in technical debt, explained for owners. When a fix costs minutes instead of tokens and can be rolled back in seconds, small problems get fixed while they are small.

Common pitfalls

Most migrations that stumble trip over the same short list, and every item is avoidable with a little foresight rather than luck:

A secret left behind in Bolt. The build is green locally but the live site misbehaves because a key never made it into Vercel's settings. Cross-check Step 3 against Step 6, key by key.
The wrong output directory. A blank white page after deploy usually means the build command or output folder does not match the framework. For a Vite project it is dist; for Next.js, leave it to auto-detect.
Deep links returning not-found. The single-page rewrite in Step 5 exists precisely to catch this, and it is the most common thing people forget.
A mismatched Node version. If the project builds for you but fails on Vercel, pin the Node version in package.json or the project settings so both environments agree.
Service accounts that were Bolt's, not yours. Anything provisioned inside the builder needs your own credentials once you are outside it. Register your own service accounts so nothing you now depend on still lives in the place you just left.

Here is how these compound when the order gets rushed, details changed to protect the business. A small studio moved their booking site off the builder over a weekend and, eager to be done, pointed the domain at Vercel before finishing the rehearsal. Two things had slipped through. A payment key was still the builder's sandbox credential rather than their own live one, so for most of a Saturday the "book now" button accepted clicks and quietly did nothing, and nobody noticed until a regular customer phoned to ask why their card had not been charged. Separately, the new deployment had let default titles overwrite the hand-written ones, and a couple of their better-ranking pages slipped in Google over the following week. Neither problem was hard to fix; both were trivial to prevent. Had they held the green-light review before the DNS switch and forwarded their titles as part of the move, the whole weekend would have been uneventful, which is exactly what a migration should be. The lesson is the one baked into the sequence above: prove it on the temporary URL, then move the domain, never the other way around.

How we run these migrations

A migration is the foundation everything later stands on, so we treat it as a defined piece of work rather than a hopeful weekend. Discovery comes first: we confirm the stack, list every dependency and secret, and produce a short roadmap, so the shape of the move is known before it starts. The migration itself is a fixed-scope first phase with one agreed outcome, your code in your GitHub repository, building and deploying on your Vercel account, on your domain, behaving exactly as it does today, and only once that is solid do we talk about anything new. You watch it working on the temporary URL before the domain ever moves, and you own all of it: the repository, the Vercel project, the keys, the domain, the data, with direct access to the developer doing the work. It is the same milestone-by-milestone approach we lay out in how we build custom software, step by step.

We do this on live production software, including the customs-invoice.com platform running on Vercel and full storefronts like LeO-Optic. If you would rather hand the whole sequence to someone who has run it many times, send me a link to your Bolt.new project and I will move it onto Vercel cleanly, domain intact, nothing lost.

FAQ

Is it hard to migrate a website from Bolt.new to Vercel?

For a typical Vite or Next.js site it is a short, mechanical job rather than a technical ordeal, because the two ends are designed to fit together and Vercel auto-detects most frameworks. The parts that need attention are administrative more than they are difficult: collecting your secrets, matching one or two build settings, and adding a rewrite rule for deep links. Someone comfortable with a terminal can complete a straightforward move in an afternoon, and the only genuinely delicate moment, the domain cutover, is made safe simply by leaving it until last.

Will my website go down during the migration?

No, provided you follow the code-first, domain-last order. Your existing site keeps serving every visitor from Bolt for the entire process, because nothing about your traffic changes until the final DNS step. You build, deploy, and test the new version on a separate temporary address that the public never sees, and you only redirect your domain once that version has passed every check. There is no interval where both are broken, and if anything looks wrong before the switch, you simply fix it while the old site carries on undisturbed.

Will I lose my work or my design by leaving Bolt.new?

You keep all of it. The code Bolt generated is standard code you already own, so exporting it to GitHub copies the project verbatim, layout, components, styles, and logic included. Nothing about the interface your visitors see needs to change; the migration alters where the code lives and how you deploy it, not what it looks like or does. The one thing you actively gain rather than lose is control: version history, your own accounts, and the freedom to hand the project to any developer.

How long does a Bolt.new to Vercel migration take?

A clean migration of a normal marketing or booking site is usually an afternoon's work, sometimes less. The time goes into the careful parts rather than the export itself: gathering credentials, walking every page and form on the temporary URL, and waiting on DNS to propagate after the domain switch, which can take anywhere from minutes to a few hours depending on your provider. Complications that stretch the timeline are almost always undocumented secrets or an unusual build setup, both of which surface during the local build in Step 2 if you do not skip it.

Will migrating to Vercel hurt my search rankings?

Only if you move carelessly, and the fix is entirely within your control. Rankings suffer when URLs change without redirects or when page titles get silently overwritten by defaults, so a disciplined move keeps addresses stable, forwards any that must change with permanent redirects, preserves your titles and descriptions, and resubmits the sitemap. Handled that way, Google follows you to the new home and the ranking impact is negligible. The step-by-step forwarding procedure is the same one in our SEO migration guide, and it is worth following to the letter if the site already earns traffic.

Can I keep improving the site myself after moving to Vercel?

Yes, and it becomes considerably easier than it was inside the builder. Once the code is in Git and deploying through Vercel, each change is a branch that produces its own preview link for you to review, then a merge that ships it live, with the option to roll back in seconds if something is off. A developer working with Claude and Git can turn edits around quickly, and because version control is free and unlimited, experimenting no longer costs anything per attempt. The decision-level reasons this workflow saves money are covered in the companion piece on leaving the builder.

How to Migrate a Website from Bolt.new to Vercel: A Simple, Safe Guide