TL;DR: Moving your dev environment to a new PC isn't just about pushing code to GitHub. You need to capture hidden
.gitand.vercelfolders, unpushed commits, local secrets, and scattered projects - then restore everything through verified archives and scripted tool installation. This guide walks through the full process: one backup, one cloud upload, one restore script.
Buying a new PC is exciting. Setting it up is not. The real pain starts when you realize half your projects live only on Vercel, three repositories have commits you never pushed, and you can't remember which folder holds that API key you need tomorrow.
Most migration guides tell you to push everything to GitHub first. That advice assumes a world where every project is committed, every remote is configured, and nothing lives in a half-finished state. Real projects don't work that way. Some exist only as deployments. Some have .env files you can't push. Some have a week of work sitting in unstaged changes.
This guide shows a different approach: back up the actual folder structure - including every hidden Git history folder and Vercel link folder - verify the archive, store it in the cloud, and restore everything on the new machine with a handful of commands. No guessing what you forgot. No week of "where did I keep that config?"
What Actually Needs to Move
Before running any commands, it helps to map what lives where and how it travels.
Your source code lives in something like C:\Users\alex\Projects. That's the obvious part. But inside each project folder sit two hidden directories most people forget: .git (your entire commit history, including unpushed work) and .vercel (the link between your local folder and the live deployment). If you copy only the visible files, you lose those connections.
Tools like Node.js, Git, and the Vercel CLI don't need to be copied. You reinstall them on the new PC with a single script. Same versions, clean installs, no leftover config conflicts.
API keys and secrets live in .env files inside each project. Those stay in the archive. You never push them to GitHub, so the archive is the only place they exist.
Dependencies like node_modules and build artifacts like .next don't travel at all. You rebuild them on the new machine with npm install. Copying them wastes time and cloud storage.
The key idea: a project folder that contains its .git and .vercel folders carries its own GitHub and Vercel connections. You don't need a separate list of repository URLs. You just need to copy the folders correctly, hidden contents and all.
Part 1: Prepare the Old PC
Create the Dev Kit Folder
Create one root folder for tooling. Call it C:\Dev. Inside, you'll store setup scripts, optional notes about your configuration, and a README so any future you - or any AI assistant - knows exactly how the machine is set up.
The structure looks like this:
plaintext
C:\Dev\
git\ (optional Git configs)
vercel\ (optional Vercel notes)
node\ (optional Node notes)
global-tools\
github.txt (username and email only, no secrets)
vercel.txt (notes only, no tokens)
projects\ (optional)
setup.ps1 (installs tools on the new PC)
README.md (explains the setup)
Security note: Never store passwords or API tokens in these text files. You'll log in again on the new PC. The text files exist only to remind you which email you used for GitHub or which Vercel team owns a project.
Write the Setup Script
This is the file that rebuilds your toolchain on the new PC. It checks whether each tool is already installed, skips it if so, and installs it if not. That makes the script safe to run twice.
On Windows with PowerShell, save this as C:\Dev\setup.ps1:
``powershell
setup.ps1 (run on the NEW PC)
$ErrorActionPreference = "Continue"
function Install-IfMissing($id, $cmd) {
if (Get-Command $cmd -ErrorAction SilentlyContinue) {
Write-Host "[skip] $cmd already installed"
} else {
winget install --id $id -e --accept-source-agreements --accept-package-agreements
}
}
Install-IfMissing "OpenJS.NodeJS.LTS" "node"
Install-IfMissing "Git.Git" "git"
Vercel CLI needs Node, so open a NEW terminal if npm isn't found yet
npm install -g vercel
node --version
git --version
vercel --version
``
On macOS or Linux, the equivalent setup script uses Homebrew:
``bash
!/bin/bash
setup.sh (run on the NEW machine)
command -v node >/dev/null 2>&1 || brew install node
command -v git >/dev/null 2>&1 || brew install git
npm install -g vercel
node --version
git --version
vercel --version
``
Put your copy of setup.ps1 (or setup.sh) in C:\Dev along with a short README that lists the folder layout and the steps in this guide. When you open the new PC in six months and can't remember how anything works, that README will save you.
Part 2: Back Up Your Projects
Preview What Will Be Copied
Always look before you copy. Robocopy on Windows has a list-only switch, /L, that copies nothing and just reports totals. The /XD option skips folders you can rebuild, like node_modules.
On Windows:
powershell
robocopy "C:\Users\alex\Projects" "D:\Preview" /E /XD node_modules .next .turbo .cache /XF *.log /L /NFL /NDL /NP
On macOS or Linux, use rsync with the --dry-run flag:
bash
rsync -av --dry-run --exclude='node_modules' --exclude='.next' --exclude='.turbo' --exclude='.cache' --exclude='*.log' ~/Projects/ /tmp/preview/
The summary at the bottom might look like this (demo numbers):
Total Copied Skipped Mismatch FAILED Extras
Dirs : 3210 3180 30 0 0 0
Files : 12480 12480 0 0 0 0
Bytes : 640.2 m 640.2 m 0 0 0 0
Write down the Files and Dirs totals. You'll use them to verify the backup in the next step. Don't worry if robocopy prints an error about the destination folder not existing during a preview. The totals are still valid.
12,480 files and 3,210 directories is a typical count for a developer with a few active projects. After excluding
node_modulesand build folders, the verified archive should contain files + folders - excluded folders (example: 12,480 + 3,210 - 30 = 15,660 items).
Why So Many Files?
Tens of thousands of small files sync to the cloud very slowly and can fail halfway. A typical node_modules folder contains 40,000+ tiny files. If you drag your Projects folder straight into OneDrive, the sync can stall for hours or error out silently, leaving you with an incomplete copy.
That's why we pack everything into one archive instead. One file uploads faster, verifies easier, and never loses track of what's copied.
Create One Archive
Windows 10 and 11 include the tar command. Make the archive in a normal local folder - not inside a cloud-synced folder.
On Windows:
powershell
mkdir C:\Dev\migration -Force
tar -czf "C:\Dev\migration\Projects.tar.gz" --exclude=node_modules --exclude=.next --exclude=.turbo --exclude=.cache -C "C:\Users\alex" Projects
"exit code: $LASTEXITCODE"
dir C:\Dev\migration
On macOS or Linux:
bash
mkdir -p ~/Dev/migration
tar -czf ~/Dev/migration/Projects.tar.gz --exclude=node_modules --exclude=.next --exclude=.turbo --exclude=.cache -C ~/ Projects
echo "exit code: $?"
ls -lh ~/Dev/migration
Wait for the prompt to return. The exit code must be 0. The file size will be a fraction of your total data - around 300 to 500 MB for the demo numbers above, depending on how much media or binary content you have.
Lesson learned the hard way: If you build the archive directly inside OneDrive or Google Drive, the sync client can lock the file while it's being written. The result is a truncated archive that looks fine until you try to read it. Build locally, verify, then copy.
Verify the Archive
This step reads the whole archive back without extracting it. It's the one most people skip, and it's the one that catches silent corruption.
On Windows:
powershell
tar -tzf "C:\Dev\migration\Projects.tar.gz" | Measure-Object -Line
On macOS or Linux:
bash
tar -tzf ~/Dev/migration/Projects.tar.gz | wc -l
The output is a line count. It should roughly equal files + folders - excluded folders from your preview step. For the demo totals of 12,480 files and 3,210 directories minus 30 skipped directories, you'd expect around 15,660 lines.
If the count is wildly different (say, 200 lines when you expected 15,000), the archive is corrupt or incomplete. Delete it and create it again - this time making sure no sync client is running.
If the count matches, you have a verified backup. Now you can safely move it to the cloud.
Part 3: Put It in the Cloud
Upload the Files
Copy C:\Dev\migration\Projects.tar.gz and the entire C:\Dev folder (which contains your setup script and README) into Google Drive, OneDrive, or Dropbox. Wait for the upload to finish. Check the file size in the cloud matches the size on disk.
Do not delete the local copy yet. Keep it on the old PC until you've successfully restored everything on the new one.
What About GitHub?
GitHub is great for version-controlled code. It's not a backup system. Projects with no remote, uncommitted work, .env files, and binary assets don't belong on GitHub. The archive method captures everything GitHub won't.
If you maintain a personal brand website with custom assets, design files, or CMS content, an archive-based backup ensures nothing is left behind. I cover more about structuring personal brand projects in my earlier guide to personal brand websites.
Part 4: Set Up the New PC
Download the Files
On the new PC, download C:\Dev and Projects.tar.gz from the cloud to a local folder - again, not directly into a cloud-synced folder. Something like C:\Temp works fine.
Install the Tools
Open PowerShell (or Terminal on macOS/Linux) as Administrator and run the setup script:
On Windows:
powershell
cd C:\Dev
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\setup.ps1
On macOS or Linux:
bash
cd ~/Dev
chmod +x setup.sh
./setup.sh
Wait for all three tools to install. The script will print version numbers at the end. If you see node v20.x.x, git version 2.x.x, and vercel 33.x.x, you're good.
Close the terminal and open a new one. (Some tools add to your PATH, and the new terminal picks up the updated PATH.)
Restore the Projects
Extract the archive into your user folder:
On Windows:
powershell
cd C:\Users\alex
tar -xzf "C:\Temp\Projects.tar.gz"
dir Projects
On macOS or Linux:
bash
cd ~/
tar -xzf /tmp/Projects.tar.gz
ls -la Projects
You should see all your project folders, each with a hidden .git and .vercel folder inside. Run dir -Force (Windows) or ls -la (macOS/Linux) inside one project to confirm the hidden folders are there.
Reinstall Dependencies
Now rebuild node_modules for each project. If you have many projects, write a quick loop:
On Windows:
powershell`shell
$projects = "shop-site", "blog-app", "portfolio"
foreach ($p in $projects) {
cd "C:\Users\alex\Projects\$p"
npm install
}
On macOS or Linux:
bash`
for p in shop-site blog-app portfolio; do
cd ~/Projects/$p && npm install
done
This can take a few minutes per project. When it finishes, you have working node_modules folders again.
Test the Connections
Pick one project and verify the GitHub and Vercel links still work.
Test GitHub:
bash
cd C:\Users\alex\Projects\shop-site
git remote -v
git status
You should see your GitHub remote URL and a clean status (or whatever uncommitted changes you had on the old PC). The .git folder carried over, so the connection is live.
Test Vercel:
bash
cd C:\Users\alex\Projects\shop-site
vercel whoami
The first time you run a Vercel command, the CLI will ask you to log in. Once you do, it reads the .vercel folder and reconnects to the live deployment. Run vercel ls to confirm it sees your project.
If you work on immersive website projects with custom WebGL, animation libraries, or heavy client-side logic, keeping a complete backup of your dependencies and build pipeline makes switching machines far less painful. I wrote more about maintaining complex front-end projects in my immersive website guide.
What Can Go Wrong
The archive is 0 bytes or fails to extract
This means the cloud sync client locked the file during creation. Build the archive in a local folder, verify it with tar -tzf, then copy it to the cloud.
npm install fails with permission errors
On Windows, run PowerShell as Administrator. On macOS/Linux, you might need to fix folder ownership with sudo chown -R $(whoami) ~/Projects.
Vercel CLI doesn't recognize the project
Check that the .vercel folder exists inside the project. If it's missing, the link is gone. You'll need to run vercel link and reconnect manually.
Git says "remote not found" even though .git exists
Check the remote URL with git remote -v. If it points to an old organization or a renamed repository, update it:
git remote set-url origin https://github.com/yourname/new-repo.git
The setup script does nothing
You might need to run Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass first (Windows) or chmod +x setup.sh (macOS/Linux) to allow script execution.
Why This Method Works
Standard advice assumes all your work is committed and pushed. Real projects don't follow that rule. You have experiments, client secrets, deployments that never touched GitHub, and commits you meant to clean up before pushing.
This approach captures the actual state of your machine. It doesn't ask you to organize, commit, or explain anything. It takes the folder as it is, verifies the copy, and restores it byte-for-byte on the other side.
The result: your new PC has the exact same projects, the exact same history, and the exact same deployment links as the old one. You didn't lose uncommitted work, didn't have to hunt for missing folders, and didn't spend a week reconfiguring tools.
One backup, one upload, one restore script. That's the whole system.
When setting up a new development environment, it's also worth reviewing your broader security practices. I maintain a checklist of software security best practices that covers environment variables, dependency auditing, and secret management - relevant whenever you're rebuilding a machine from scratch.
Make It Repeatable
The real value isn't just moving to one new PC. It's having a tested, documented process you can run again in two years when you upgrade, or when a hard drive fails, or when you need to set up a second machine for travel.
That's why the C:\Dev folder matters. It holds the setup script, the README, and any notes about your configuration. You can hand it to another developer, or to an AI assistant, or to future-you, and they'll know exactly how the machine is supposed to work.
Store the latest version of C:\Dev in your cloud drive. Update the README when you add a new tool. Keep one verified archive of your projects folder, and refresh it every few months.
When the next upgrade comes, you won't be starting from scratch. You'll open the README, run the script, extract the archive, and be back to work in an hour.
You can read more about my approach to systematic development workflows on my site, where I cover tooling, architecture, and the kind of repeatable processes that save time when things break.
Top comments (0)