VPS Snaps

Switching Providers

Move the site. Leave the old server untouched.

Pick the new server. VPS Snaps checks both, takes a fresh backup, restores it there, and counts what arrived against what left. Your old server is only ever read.

Back up your first server free, forever. No credit card required.

We only use your email to create your account. See our Privacy Policy.

Five steps, in this order

A move is the backup and restore machinery pointed at a new server, with the checks around it that turn “restore a backup somewhere” into “move a site”.

The old server is only ever read. Everything is written to the new one, so a move that fails at any step leaves the live site exactly as it was. That is what makes it safe to try.

Included on the Standard, Pro and Agency plans — the plans with database backups, since a move carries the site’s database. Compare plans

  1. Step 1

    Check both servers

    Read-only, on both machines, and repeated by the move itself before it touches anything. Every problem comes back with what to do about it.

  2. Step 2

    Create the database on the new server

    Same name, same user, same password as on the old one — so the site’s own config file keeps working without an edit. An existing user’s password is never changed; it may belong to something else on that server.

  3. Step 3

    Back up the database, then the files

    A fresh backup, taken the way every scheduled backup is. The database goes first: an upload that lands in between ends up as a file nothing points to, rather than a page pointing at a file that isn’t there.

  4. Step 4

    Restore onto the new server

    Files are only created, never overwritten — a file already sitting where the backup would write stops the restore before anything is written. The database gets a safety copy first.

  5. Step 5

    Compare what arrived with what left

    Files and database tables are counted on both servers and shown side by side. A restore that reports success with nothing on the new server is treated as the failure it is.

What it checks before anything moves

The classic way for a move to fail is an hour into it: the wrong database version, a folder that wasn’t empty, a user that couldn’t log in. These run first, and each one says what to do.

Both servers answer over SSH
The old one because the fresh backup is taken from it; the new one because everything lands there.
The site’s folder on the new server is empty
A stock Apache install leaves an index.html in /var/www/html. The check finds it and names it.
The database server is installed, and its version
Same or newer passes. An older PostgreSQL or MySQL, or MySQL to MariaDB, is flagged before you start, not an hour in.
The database and its user
Already there and working, or created for you. If they can’t be created, you get the exact statements to run yourself.
Room on the new server
Free space against the size of the site’s last backups and what they expand to.
Where the database lives
A database on another host — a managed one, say — stays put. Only the files move, and the check says so.

Why people move

The backups you already have are most of a move. These are the three times people reach for it.

You found a cheaper host

Any server VPS Snaps can reach over SSH is a destination — it doesn’t need a provider integration or even an API. The old host doesn’t need one either.

You’re upgrading the operating system

The safe way to a fresh Ubuntu is a fresh server, not an in-place upgrade. Build the new one, move the site across, and keep the old one until you’re sure.

You’re rebalancing client sites

Move one application at a time between the servers in your workspace — each site keeps its own backups and its own history.

Hosts with no snapshot API at all, like SSD Nodes and InterServer, work on either end of a move — it needs SSH, not an integration.

What you still do

A move carries the site — its files and its database. These live around it, and they are where migrations actually go wrong, so they’re listed after every move rather than left for you to discover.

Web server configuration

Your nginx or Apache site lives outside the application’s folder. Set it up on the new server, pointing at the same folder.

DNS

Point your domain at the new server. Lowering the record’s TTL a day ahead makes the switch take minutes rather than hours.

HTTPS

Issue a certificate on the new server once the domain points there.

Anything that runs, not sits

Cron entries, queue workers, a Ghost or Node process. They live outside the site’s folder and have to be set up again.

Mail

If the old server sent or received email, that configuration stays behind.

Snapshots, Docker volumes, MongoDB

Provider snapshots stay with their provider, and this move handles files plus PostgreSQL, MySQL or MariaDB — not Docker volumes or MongoDB.

And once the domain points at the new server, one button moves the site’s backups there — not before, because until then the old server is still the live site and the one that needs backing up.

FAQs

Can’t find the answer you’re looking for? Reach out to our support team.

Does moving a site change anything on my old server?

No. The old server is only read: a fresh backup is taken from it, exactly as a scheduled backup would be, and nothing on it is written, stopped or deleted. If the move fails at any point, the site you started with is exactly as it was and still serving.

What happens if the move fails halfway?

It stops and tells you which step failed and why. The old server was never changed. On the new server, nothing that was already there is lost: files are never overwritten, and the database is backed up before it is written. Files the move had already created are left in place for you to look at or delete.

Will my site go down?

Not because of the move — the old server keeps serving throughout, and the new one isn’t live until you point your domain at it. What to plan for is the switch: anything the old site records after its backup starts — orders, comments, uploads — isn’t on the new server. For a busy site, put it in maintenance mode before you start, and point the domain across once the move finishes.

Does the new server need the same database version?

Not necessarily, and you’re told before anything starts. Same or newer passes. An older PostgreSQL or MySQL, or MySQL to MariaDB, is flagged, because a dump from a newer version can use syntax an older one doesn’t know. A PostgreSQL restore runs in a single transaction, so if it does fail, it changes nothing.

What about a managed database, like RDS?

It stays where it is. When a site’s database lives on another host, the move leaves it alone and moves only the files, and the site on the new server keeps using the same database. Make sure that database accepts connections from the new server’s address.

What do I need on the new server first?

SSH access for VPS Snaps, a web server, and the database server — ideally the same versions as the old one. VPS Snaps creates the database and its user itself, with the same name, user and password as before, so the site’s config file works unchanged. The site’s folder has to be empty, and the check will tell you if it isn’t.

Which plans include it?

Standard, Pro and Agency. Moving a site means moving its database, and database backups start on Standard, so that’s where moving starts too. A move that is running or finished stays open to you whatever your plan later becomes, so you can always see how it went and switch its backups over.

Can I move a site to a different domain at the same time?

Not with this — it moves the same site to a new server. A WordPress site changing its address needs the URLs inside its database rewritten, which the VPS Snaps WordPress plugin’s own restore does.

Built on the backups you already run

A move is these pieces, used in order. Each works on its own every day, before and after you switch.

Application backups

Where every move starts: a scan finds WordPress, Laravel, Craft CMS and Ghost installs and pairs a file job with a database job for each.

Read more

Database backups

pg_dump and mysqldump over SSH, on your schedule — the same backups a move takes, running every day before and after it.

Read more

Cloud providers

Snapshot integrations for seven clouds, for when you want the whole machine back rather than the site on it.

Read more

Change hosts without gambling the site that’s live.

Connect both servers over SSH, detect the site, and let the checks tell you what to fix before anything moves.

No credit card required. Cancel anytime.