How to migrate from shared hosting to a VPS in 2026

Most guides on this topic are really ads for one host’s one-click migrator. They walk you through their panel, skip the parts that actually break, and stop before the risky bit. We move sites between hosts for a living, so here is the version that covers where migrations go wrong, which is almost never the files.

First, are you sure you need a VPS

Shared hosting gets a bad reputation it half deserves. If your site is slow because it is a bloated WordPress install with twenty plugins, a VPS will not fix that. It will just give you a slow site with root access. Move to a VPS when you have hit a real limit: the host is throttling your CPU, you need a PHP version or extension they refuse to install, you are running something that is not a website such as a queue worker or a small API, or your traffic is genuinely steady and you have outgrown the resource ceiling. Those are good reasons. “I read shared hosting is bad” is not.

What actually moves, and what breaks

A website is four things: files, a database, DNS, and email. Copying the files and database is the easy eighty percent, and every tutorial covers it. The twenty percent that causes downtime is DNS and email, and that is the part you have to plan.

For the files, archive the whole web root, move it, unpack it. For the database, export with mysqldump, import on the new box, and update the connection credentials in your config. On WordPress that is wp-config.php. On OpenCart it is config.php and admin/config.php, both of which hard-code server paths. Get those paths wrong and you get a white screen, which is the single most common “the migration broke my site” ticket we see.

The DNS cutover is the whole game

Here is the move that separates a clean migration from a day of downtime. A day before you switch anything, lower your DNS TTL to 300 seconds. TTL is how long the world caches your old IP address. If it is set to the common 86400, a full day, then after you flip to the new server some visitors keep hitting the old one for up to 24 hours. Lower it first, wait for the old TTL to expire, then migrate. Now your cutover propagates in minutes.

And test before you point the domain at anything. Every operating system has a hosts file that lets your own machine resolve the domain to the new server’s IP while the rest of the world still sees the old one. Add that line, load the site, click around, place a test order, submit the contact form. You are looking at the real site on the new server with zero risk to live visitors. Only when it passes do you change the DNS record.

Email is where people lose data

If your email lives on the same shared host, meaning mailboxes at your domain rather than Google Workspace, the DNS change moves your mail with it, and any message that arrives during the gap can land on the old server where you will never see it again. Decide the email plan before you start. Either move the mailboxes and their contents on purpose, or move email off the web host entirely to a dedicated provider, which is what we usually recommend anyway. We have watched a migration go “perfectly” and then a client realize three days later that a week of customer email was sitting on a server they had already cancelled. Back the mail up first.

A migration that does not go down

Put it together and the no-downtime version looks like this. Lower TTL a day early. Build the VPS, copy files and database across. Test through your hosts file until the site genuinely works. Sort out email. Then flip DNS, keep the old host running for a week instead of cancelling it the same day, and watch the new server’s logs for anything that 404s or errors. Cancel the old plan only after a full quiet week. The whole thing is an afternoon of work and a week of patience.

The part nobody tells you about owning a server

A VPS is not managed for you. If it ever falls over, our server crash post-mortem traces the cause from the logs. The day the migration finishes, you own the security updates, the firewall, the backups, and the 2am reboot when something hangs. That is the real cost of moving off shared hosting, and it is worth knowing before you commit. If you want the control without becoming a part-time sysadmin, that is what our managed server support covers, and we will run the move itself: the planned, tested, no-downtime kind above is our migration pack. If an earlier migration already went sideways and left you with a half-broken site, server restoration is the cleanup. For the WordPress-specific version of all this, we wrote up how we migrate WordPress sites separately. Before you migrate, make sure you can actually restore a backup, not just create one — we timed the common methods so you know what a real restore costs.

Move for a real reason, lower the TTL, test through your hosts file, and treat email as the dangerous part. Do those four things and the scary migration becomes a quiet one.

Once you are on the VPS, keep an eye out for the five signs it needs a security audit so a fresh server does not quietly drift into trouble.

Before you move real traffic onto it, it is worth a pass to harden the new server so it starts locked down rather than wide open.

Before you migrate, settle whether to run the VPS unmanaged or pay for managed, because that choice drives most of the ongoing cost.

Landing on the right box is half the decision. If you are weighing hosts, our comparison of Hetzner and DigitalOcean for WordPress breaks down price, bandwidth, and who actually runs the server. Coming off a managed platform instead of shared hosting? The steps differ, and we lay them out in our guide to leaving WP Engine.