How to Migrate Your Website to a VPS: A Step-by-Step Guide

A website migration is safe when you build the new server completely, verify it before any DNS change, lower the TTL in advance, and keep the old host running for a week afterwards. Done in that order, the cutover itself is a two-minute DNS edit with no downtime. Done in the wrong order, it is a bad evening.

Two days before: lower your DNS TTL

This is the step people skip and regret. DNS records carry a time-to-live telling resolvers how long to cache them — commonly 3 600 or 86 400 seconds. If you change your A record with a 24-hour TTL, some visitors keep reaching the old server for a full day.

; set this at least 48 hours before cutover
example.com.  300  IN  A  203.0.113.10

Drop it to 300 seconds two days ahead, so the old value has expired everywhere by the time you switch. Raise it back afterwards.

Step 1: inventory what you are actually moving

Migrations fail on the thing nobody wrote down. Before touching anything, list:

• Web files, and their ownership and permissions
• Databases, with their versions — a dump from MySQL 8 does not necessarily load into MariaDB
• Cron jobs (crontab -l for every user, plus /etc/cron.d)
• Language runtime versions and installed extensions
• TLS certificates, or the plan to reissue them
• Email — if mail is on the same host, moving it is a separate project (see email hosting explained)
• Environment variables and API credentials
• Anything hardcoded to the old IP address

Step 2: build the new server completely

Deploy the VPS, then harden it before it serves anything: key-only SSH, a default-deny firewall, automatic security updates. The hardening checklist and the firewall guide take about half an hour between them.

Then install the stack and match the versions to what you are leaving. A PHP or PostgreSQL version bump during a migration means two variables changed at once, and if something breaks you will not know which. Move first, upgrade second.

Step 3: copy the data

# files — rsync is resumable and preserves ownership and timestamps
rsync -avzP --exclude='cache/' --exclude='*.log' \
  root@old-server:/var/www/ /var/www/

# database
ssh root@old-server "mysqldump --single-transaction --routines --triggers app" \
  | mysql app

# postgres
ssh root@old-server "sudo -u postgres pg_dump -Fc app" > app.dump
pg_restore -d app app.dump

Run the file sync twice: once now, and once again immediately before cutover. The second pass only transfers what changed, so it takes seconds rather than hours, and it captures everything written while you were working.

Step 4: test before anyone else can

Point your own machine at the new server without changing public DNS, by editing your hosts file:

# /etc/hosts  (C:\Windows\System32\drivers\etc\hosts on Windows)
203.0.113.10  example.com www.example.com

Now browse the real domain against the new server. Check the pages, log in, submit a form, complete a checkout, upload a file, run the search. Check the logs for errors nobody would notice from the front end. Confirm cron jobs run. This is where migrations are actually won.

Step 5: certificates

Issue the certificate before cutover using DNS validation, so it is already valid when traffic arrives:

sudo certbot certonly --manual --preferred-challenges dns \
  -d example.com -d www.example.com

HTTP validation cannot work until DNS points at the new server, which means a window where the site is live without TLS. DNS validation removes that window entirely.

Step 6: cut over

1. Put the old site into read-only or maintenance mode if it accepts writes.
2. Run the final rsync and a fresh database dump.
3. Update the A and AAAA records to the new IP.
4. Watch both servers' access logs — you will see traffic drain from one and arrive at the other over the next few minutes.
5. Once the new server is taking everything, take the old one out of maintenance mode and leave it running.

Step 7: the week after

• Keep the old server for seven days. It is the cheapest insurance available, and it is the only real rollback you have.
• Raise the DNS TTL back to its normal value.
• Watch error logs and response times daily. Problems that only appear under real traffic appear in the first 48 hours.
• Verify backups run on the new machine — see automating backups. A fresh server with no backup job is one bad day from a very expensive lesson.
• Check search visibility. If URLs changed, 301 redirect the old ones; if they did not, nothing should move.

Common mistakes

Mistake	Consequence
Changing DNS before testing	Users see a broken site while you debug
Not lowering TTL first	Split traffic for up to 24 hours; writes land on both servers
Upgrading versions during the move	Two variables changed; no way to isolate a failure
Cancelling the old host immediately	No rollback, and no reference for what you forgot
Forgetting cron jobs	Silent — nothing breaks visibly, work simply stops happening
Wrong file ownership after rsync as root	Uploads fail, caches cannot be written

Frequently asked questions

How long does a migration take?

A small site is an afternoon. The variable is not data size, it is how much of the old configuration was undocumented.

Will migrating hurt my search rankings?

Not if URLs stay the same and downtime is zero, which is the point of this sequence. A faster, closer server usually helps.

Can I migrate without any downtime?

Yes for read-heavy sites, using the low-TTL and dual-running approach above. Sites accepting writes need a brief read-only window, or a plan for reconciling writes that landed on the old server.

What if something goes wrong after cutover?

Point DNS back at the old server, which is still running. That is the entire reason for step 7.

Where to land

If you are coming from shared hosting, the signs you have outgrown it covers why, and choosing the right VPS plan covers sizing. Our KVM plans deploy in under a minute across twelve locations — and because they bill hourly, running the new server alongside the old one for a week costs a few euros.