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

The idea of moving your site off Bolt.new sounds like the kind of task that goes wrong at the worst moment, takes the site down, and loses an afternoon of work you cannot get back. It is worth saying clearly up front: it is not that. A website migration from Bolt.new to Vercel is a calm, reversible sequence of small steps, and done in the right order it carries no downtime and no risk to what you already have, because the old version keeps serving visitors until the new one is proven. By the end you own the code, the deployment, and the domain, and you have a setup that costs far less to keep improving. This guide walks the whole thing, plainly, in the order you should actually do it.

If you want the case for why this is worth doing at all, the benefits and the token economics live in our companion piece, leaving Bolt.new for Vercel. Here we focus on the how.

Before you start: a five-minute checklist

Gather these first and the rest goes smoothly:

A GitHub account. Free. This is where your code will live.
A Vercel account. Free to start, and the free tier comfortably hosts a typical business website.
Your secrets. Any API keys, database URLs, or service credentials your site uses. Have them somewhere safe and ready to paste.
Access to your domain's DNS. The login for wherever you bought your domain, so you can point it at Vercel when the time is right.
Node.js on your machine, or a developer beside you. You can do much of this in the browser, but having Node installed lets you confirm the site builds before you ship it.

Step 1: Get your code out of Bolt.new

Your project in Bolt is real, standard code, and there are two ways to take it with you. The cleaner path is to connect the project to GitHub and push it to a new repository, which gives you proper version history from the start. The alternative is to download the project as a folder and create the GitHub repository yourself. Either way the destination is the same: a GitHub repository that holds your project.

If you downloaded a folder, create the repository in a couple of commands:

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

Step 2: Run it locally and confirm it builds

This step is your safety net, so do not skip it. Open the project, install its dependencies, and make sure it runs and builds cleanly before Vercel ever sees it.

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

If npm run build finishes without errors, you are in good shape. If it complains, the message almost always points at a missing environment variable or a missing dependency, both of which are quick to fix and far better discovered here than in front of customers.

Step 3: Collect your environment variables

Most websites lean on a handful of secrets: an API key, a database connection string, perhaps keys for a service like Supabase. Inside Bolt these were set for you behind the scenes. Outside, you set them yourself, which is part of owning the project. Make a simple list of every key your site needs and its value. You will paste these into Vercel in the next step, and locally you keep them in a file named .env that is never committed to Git.

Step 4: Create the Vercel project and connect your repository

In Vercel, choose to add a new project and import the GitHub repository you just created. Vercel reads the project and, for the common stacks, recognizes what it is looking at on its own. This is the moment the move becomes real, and it is mostly a matter of confirming what Vercel already detected.

Step 5: Confirm the build settings

For a Vite site, the kind Bolt most often produces, the settings are simply:

Build command: npm run build
Output directory: dist

For a Next.js site, Vercel detects the framework and needs no output directory at all, since Next.js and Vercel are built by the same team. Then add the environment variables from Step 3 in the project settings, exactly as named, so the production site has the secrets it needs.

One detail catches single-page sites. If your site uses in-app routing and a visitor reloads a deep link such as /about, you want the server to hand back your app rather than a not-found page. A small vercel.json at the root takes care of it:

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

Step 6: Deploy and test on the temporary URL

Trigger the first deployment and Vercel gives you a temporary address, something ending in vercel.app. Treat this as your rehearsal stage. Click through every page, submit the forms, check that anything talking to an external service still works, and view it on your phone. Because your domain is not pointed here yet, your live site is completely untouched while you do all of this. Nothing your visitors see has changed.

Step 7: Connect your custom domain, with no downtime

When the temporary URL behaves exactly as you want, add your real domain in the project's domain settings. Vercel shows you the DNS records to set, and you add those at your domain provider. The switch happens at the DNS level, cleanly, and once it propagates your domain serves the new site. Because you only point the domain after you have proven the new deployment, there is no window where the site is broken. The move is, from a visitor's point of view, invisible.

Step 8: Protect your search rankings if the site already has traffic

If your site is new, you can skip this. If it already earns search traffic, give it the same care any migration deserves: keep your URLs the same where you can, redirect any that change to their closest match, carry over your titles and meta descriptions rather than letting defaults overwrite them, and submit your sitemap afterward. The discipline is identical to the one we lay out for store migrations in migrating without losing your SEO, and it is what separates a smooth move from a traffic dip.

Step 9: The workflow that takes over from here

This is the quiet reward. From now on, changing your site looks like this: create a branch, make the edit, and Vercel automatically builds a preview deployment with its own link so you can see the change live before it reaches anyone. Merge the branch and it goes to production. With a developer working in this loop using Claude to write and refine the code and Git to track every version, a new section or a fix is a few minutes of focused work and a push, not a draw against a token balance. Every change is reviewable, reversible, and yours.

The snags worth knowing about in advance

Almost every migration that stumbles does so on one of these, and all of them are avoidable:

A missing environment variable. The site builds locally but breaks on Vercel because a key was not added in the project settings. Re-check Step 3 against Step 5.
The wrong output directory. A blank page after deploy usually means the build command or output directory does not match the framework. For Vite it is dist.
Deep links returning not-found. The single-page rewrite in Step 5 fixes this.
A different Node version. If something builds for you but not for Vercel, pin the Node version in your package.json or the project settings so both agree.
Service keys that were Bolt's, not yours. Anything provisioned inside the builder needs your own credentials once you are outside it. Set up your own service accounts so nothing depends on the place you are leaving.

How we run these migrations

A migration is the foundation of everything that comes after it, so we treat it as a defined piece of work rather than a gamble.

We map it before we touch it. Discovery confirms the stack, lists every dependency and secret, and produces a short roadmap, so you know the shape of the move before it begins.
The migration is a fixed-scope first phase. 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. Only after that is solid do we discuss new features.
You see it working before the domain moves. We prove the new deployment on its temporary URL first, so the switch is the safe, boring step it should be.
You own all of it. Your repository, your Vercel project, your keys, your domain, your data, with direct access to the developer doing the work and no lock-in of any kind.

We do this on real production software, including the customs-invoice.com platform running on Vercel and full storefronts like LeO-Optic, and the same ownership-first approach underpins our eCommerce work as WooSmiths. If you would rather skip the snags entirely, send me a link to your Bolt.new project and I will move it onto Vercel cleanly, with your domain intact and nothing lost.