Fact-checked against current official documentation and provider information. Editorial review is required before publication.
Last updated: September 14, 2026
Moving from shared hosting to a VPS changes more than the server size. Shared hosting hides the operating system, web stack, mail services and patching. On an unmanaged VPS, those become your responsibility.
A safe migration builds the destination in parallel, copies and verifies data, controls the final change window and keeps the old account available for rollback. Do not point DNS at an untested server.
Quick Answer
Inventory the existing site, lower DNS TTL in advance, create independent backups, build and secure the VPS, test the site through a temporary hostname or hosts-file entry, plan email separately, freeze writes, make a final database/file sync, switch DNS, monitor both systems and retain the old host until the rollback window closes.
| Phase | Main task | Exit condition |
|---|---|---|
| Discover | Inventory domains, databases, files, cron, DNS and mail | Nothing required by the site is unknown |
| Build | Harden VPS and install compatible stack | Destination survives update and reboot |
| Test | Restore copies and test privately | Pages, forms, jobs and admin functions work |
| Cut over | Final sync and DNS change | New writes reach the VPS |
| Stabilise | Monitor logs, TLS, mail and resources | No unresolved errors; rollback window ends |
Inventory the Existing Account
- Every domain, subdomain and redirect.
- Document root, file ownership and storage used.
- Database engine, version, size and credentials.
- PHP/runtime version, extensions and server rules.
- Cron jobs, queues, webhooks and background workers.
- DNS records, nameservers and TTL values.
- Mailboxes, forwarders, SMTP settings and deliverability records.
- TLS certificates and renewal process.
Prepare Backups and Rollback
Create a full file and database backup outside the shared account. Export DNS and mail settings. Verify archive checksums and restore the backup into a test directory or database before relying on it.
Keep the old hosting account unchanged through the cutover. Define the rollback trigger and method: restore the previous DNS answer, remove the write freeze and reconcile data created during the attempted cutover.
Build and Secure the VPS
Install a supported operating system and web stack, apply updates, create a non-root administrator, configure SSH keys and firewall rules, and set up monitoring and backups. Match application versions deliberately; a large jump in PHP or database version can turn a hosting migration into an application upgrade.
Configure virtual hosts, TLS, caching, upload limits, scheduled jobs and log rotation. Do not host public mail on the new VPS unless you have planned reputation, reverse DNS, spam filtering and backups.
Test Without Public DNS
Restore the files and database, then map the domain to the VPS in a local hosts file or use a protected staging hostname. Test navigation, logins, checkout, forms, uploads, media, scheduled tasks, outbound email and administration.
Check logs while testing. A page that looks correct can still generate permission warnings, failed cron jobs or mixed-content errors.
Cut Over With a Final Sync
- Lower TTL at least one old TTL period before the move.
- Announce a short write freeze for stores, forums or membership sites.
- Take a final database dump and copy changed files.
- Verify counts or checksums at the destination.
- Update DNS records or nameservers.
- Issue/verify TLS on the public hostname.
- Monitor both source and destination logs during propagation.
After the DNS Change
Watch application errors, CPU, memory, disk, database connections and certificate status. Search for hard-coded old paths or IPs. Verify mail authentication records and delivery if the mail system changed.
Do not cancel shared hosting immediately. Wait through the agreed stabilisation period, take a final archive and only then close the old account.
Frequently Asked Questions
Will changing nameservers cause downtime?
It can if the new DNS zone is incomplete or the destination is not ready. Copy every required record first and test the new server before switching.
Should email move to the VPS too?
Not automatically. Keeping mail with a specialised provider often reduces migration risk. If it moves, plan MX, SPF, DKIM, DMARC, reverse DNS, reputation and backups separately.
How long should I keep the old host?
Keep it through DNS propagation and a defined stability window. Dynamic sites also need a plan for writes that reach the old server during transition.
Conclusion
A shared-hosting-to-VPS migration succeeds when discovery and rollback are treated as seriously as copying files. Build in parallel, test privately, sync once more, cut over deliberately and monitor before cancelling anything.
