Move a business website from shared hosting to a VPS without downtime

Shared hosting is a sensible place to start a business website: it is cheap, managed, and good enough while traffic is small. The problems arrive quietly. Pages slow down at busy times, a neighbour on the same server causes trouble, you cannot install the runtime or extension your site now needs, and backups and access controls are whatever the host gives you. A VPS fixes those limits, but the move itself is where sites break — usually not in the copying, but in the cutover.

Know when you have outgrown shared hosting

The signals are operational, not theoretical. You have outgrown the account when two or three of these are true at the same time:

• Response times degrade under modest load, and you cannot see why from the control panel.
• The host sends resource-limit warnings, or throttles the site at busy times.
• You have no SSH access when you need to diagnose something quickly.
• You cannot run scheduled jobs, a queue worker, or the PHP or Node version your site now needs.
• Backups, access controls, and security settings are whatever the host gives you, with no way to change them.

If none of those are true, staying put is also a valid engineering decision. Migrate when the limits cost you time or customers, not because a VPS sounds more serious.

Prepare the VPS before you touch DNS

Build the destination completely while the live site stays where it is. Match the stack the site expects — web server, language runtime and version, database version, extensions — then add what shared hosting hid from you: a firewall with only the ports you need, automatic security updates, a non-root deploy user, TLS certificates, log rotation, and backups that run before anyone asks for them. This is the same discipline we apply on our own cloud and DevOps work: the server should be boring, documented, and reproducible before it serves a single visitor. For a small team this is platform engineering in miniature — a short runbook and a server you can rebuild beat a clever server nobody dares to touch.

Copy in the right order: files, database, configuration

Copy the site files first, then a database dump, then the environment-specific configuration — database credentials, API keys, mail settings — which should never travel inside a code repository. A plain file sync is enough for most sites:

rsync -avz --progress /var/www/html/ deploy@new-server:/var/www/html/
mysqldump --single-transaction --routines your_database > site-backup.sql

Bring the site up on the VPS under a temporary hostname or a local hosts-file override and test it there. Any difference in behaviour is a stack mismatch to fix now, while the public site is still untouched. If the migration also involves a schema change, plan it separately and deploy it the way you would any zero-downtime database change: expand first, migrate, then contract.

Cut over with DNS timing, not hope

Twenty-four to forty-eight hours before the move, lower the DNS TTL for the domain to 300 seconds so the cutover propagates in minutes instead of hours. Freeze content edits on the old site, take a final database sync so orders, inquiries, and form submissions created since the first copy are not lost, then change the A record to the VPS address. Afterwards, confirm from outside your own network that the domain really answers from the new server:

dig +short yourdomain.com
curl -I https://yourdomain.com

Watch both servers during propagation: some visitors will reach the old host for a short window, which is exactly why the content freeze and the final sync matter.

Verify like a user, not like a server

A green status page on the server proves very little. Load the site the way a customer does: the home page, the heaviest inner pages, the contact or inquiry form end to end, any login, any checkout or booking flow, and email delivery from the site's forms. Then check the operational details a customer would hit next:

• Scheduled jobs (cron) ran on the new server, and their output went where it should.
• Uploaded files are present, writable by the web server, and still uploading correctly.
• Response times are actually better than the old host — compare them against the performance budgets around user-visible work you expect the site to hold.
• Logs and observability work from the first hour, so the first real error is visible instead of silent.

A deployment is only done when it proves what it ships — the same standard applies to a migration.

Keep the old host as your rollback

Do not cancel the shared hosting the day the DNS flips. Keep the old account intact for at least a few days: if something subtle surfaces — a missed cron job, a mail record, a forgotten subdomain — you can point DNS back in minutes or lift the missing piece across. When the new server has carried real traffic cleanly for a week, raise the TTL back up, take a final backup of the old account, and then close it.

Done in this order, a hosting migration is an afternoon of preparation and a few minutes of cutover, with no window where customers see a broken site. If you would rather hand the whole move — server build, sync, cutover, and verification — to someone who does it as a service, talk to us about your site.