Guide VPS & Servers

How to move from shared hosting to a VPS

Building the new server first and testing it privately before you touch DNS is what keeps this move from causing any visible downtime.

Updated 10 min read Intermediate

Moving from shared hosting to a VPS is a bigger job than a typical hosting-to-hosting migration, because you are not just copying files — you are building the server environment those files depend on from nothing. The good news is that done in the right order, none of it needs to cause visible downtime, because you build and test the new server privately before anything public changes.

1. Decide before you migrate: how much are you taking on?

Shared hosting's control panel was quietly handling security patching, service configuration, and often backups on your behalf. An unmanaged VPS hands all of that to you. Before you begin, be honest about whether that is a job you want — see what a VPS is and managed versus unmanaged VPS. If the answer is no, a managed plan gets you the resources of a VPS without that specific trade-off.

2. Set up and secure the new server first

Provision the VPS and work through the baseline setup before touching your site: update the system, create a sudo user, switch SSH to key-based login, and enable a firewall. The full sequence is in how to set up a new VPS from scratch — do not skip this because you are in a hurry to get the site moved, since it is far easier to do properly before anything live depends on the server.

3. Install the stack your site actually needs

Identify what your current shared hosting plan provides — PHP version, database engine, any specific extensions your application requires — and install the equivalent on the VPS. For a typical PHP site, that means installing a LAMP stack: Apache or Nginx, MariaDB or MySQL, and PHP with the extensions your application lists as required.

Match versions where it matters

A significant PHP or database version difference between your old shared hosting and the new VPS can surface compatibility issues that have nothing to do with the move itself. Check what your application actually requires and supports before assuming "newer is always fine".

4. Copy the files and database across

Export your database from the shared hosting control panel, and download your site's files — most panels offer this through their file manager or FTP access. Then transfer both to the VPS:

scp -r local-site-files/ yourname@203.0.113.10:/var/www/example.com/
mysql -u appuser -p appdb < database-export.sql

Full detail on the transfer tools themselves is in transferring files to a server with SCP and SFTP, and the general shape of a hosting migration — including handling email separately from the website — is covered in migrating a website to new hosting, much of which applies here too.

5. Configure the web server for the domain

Set up an Nginx server block or Apache virtual host for the domain, pointing at the files you just copied across — see hosting a domain on your VPS for the specifics of both.

6. Test privately before changing anything public

This is the step that makes the whole migration safe. Before touching DNS, preview the site as it will look on the new server by editing your own computer's hosts file — not the server's — to point the domain at the new VPS's IP address, for your machine only:

# Linux / macOS: /etc/hosts
# Windows: C:\Windows\System32\drivers\etc\hosts

203.0.113.10   example.com   www.example.com

Visit the site in a browser afterwards and it will load from the new VPS, while every other visitor in the world still reaches the old shared hosting account completely unaffected — nothing about this step is visible to anyone but you. Click through the site thoroughly: check forms submit, check the database is populated correctly, check any file uploads or user-generated content came across intact.

Remove the hosts file entry once you are done testing

Leaving it in place means your own machine will keep showing the new server even after you have switched DNS for everyone else, which can make you think a subsequent, unrelated problem is DNS-related when it is not. Delete the line once testing is complete.

7. Switch DNS once you are satisfied

Update the domain's A record to point at the new VPS's IP address. This step is identical to pointing any domain at any new hosting, so pointing a domain to your hosting covers it if any part is unfamiliar. Lower the record's TTL a day in advance if you can plan that far ahead — it makes the actual cutover much faster.

8. Keep the old hosting running until you are sure

Do not cancel the shared hosting account the moment you change DNS. Records take time to spread, and keeping the old site live and untouched in the meantime means any visitor still reaching it during that window sees a working site rather than nothing at all. Once you have confirmed traffic has fully moved — checking access logs on the new server is the most reliable way — the old account can be safely cancelled.

From here, the ongoing responsibilities of running a VPS begin: keeping it patched (how to keep a Linux server patched) and backed up (setting up automatic backups) on an ongoing basis, which shared hosting was previously doing for you.

Related reading