How to migrate a website to a VPS without losing data
A safe migration is a controlled change of environment: inventory, backup, testing, final synchronisation, DNS cutover and rollback. This sequence works for a database-backed site with external integrations.
Choose a migration strategy
A static site needs little more than a file copy and DNS change. A dynamic site keeps accepting orders, accounts and uploads while you migrate. If you dump the database in the morning and switch DNS at night, the newest records remain on the old server.
| Scenario | Downtime | Approach |
|---|---|---|
| Static site | Almost none | Copy, test, DNS |
| Blog with rare changes | A few minutes | Final dump during short maintenance |
| Online shop | Keep it minimal | Initial copy plus final orders and files sync |
| High-traffic service | May be unacceptable | Replication or staged cutover |
For an ordinary site, a clear short maintenance window is safer than an untested promise of zero downtime. Keep the old server available for comparison and rollback.
Step 1: inventory every dependency
- Domains, subdomains and every DNS record.
- Files, database, uploads and their growth rate.
- OS, web server, runtime, extensions and database versions.
- Cron jobs, queues, workers, systemd units or Compose files.
- SMTP, SPF, DKIM, DMARC and form recipients.
- Secrets, API keys, webhooks, storage and IP allowlists.
- Backup location, decryption key and restoration procedure.
Record CPU, RAM, storage and traffic during a normal business week. This gives you a defensible baseline for the new plan; see our VPS selection guide and CPU and RAM sizing table.
Step 2: create a verifiable backup
Take an application-consistent database dump and a separate copy of files. Store them outside the old server. Inspect the archive, confirm uploads and required tables are present, and ideally restore it in a temporary environment. A backup that has never been restored is still only an assumption.
Step 3: prepare the new VPS
Install a supported OS, create a sudo administrator, test SSH-key access, update packages and configure a deny-by-default firewall. Deploy compatible versions of the web server, language runtime and database. Migrate first and upgrade major software versions later, one at a time; simultaneous changes make failures difficult to isolate.
Create service users and database accounts with minimum permissions. Keep the database private. For specific stacks, use our WordPress VPS guide or Docker VPS guide.
Step 4: copy files and data
Perform the large initial file transfer while the old site is live, preserving structure and verifying ownership afterwards. Import the database with the correct encoding, collation and time zone. Avoid blind search-and-replace in binary dumps: some CMS platforms serialise values and require their own migration tool.
Transfer secrets over a protected channel and rotate them when practical. Add the new server address to external allowlists before removing the old one.
Step 5: test before changing DNS
Map the production hostname to the new IP locally using the hosts file. This tests the real Host header, cookies, HTTPS and routes more faithfully than a random temporary domain.
- Open representative pages and the 404 page.
- Test login, search, forms, uploads and registration.
- Complete a test order or other critical transaction.
- Check cron and workers run on only one host.
- Verify outbound mail, webhooks and error logs.
- Create and restore a backup on the new VPS.
Step 6: final sync and DNS cutover
Lower the relevant DNS TTL in advance. During the agreed window, stop writes or enable maintenance mode, take the final database dump and synchronise changed files. Stop scheduled work on the old host, start it on the new one and update A and AAAA records. If a CDN is used, change its origin too.
Resolvers will briefly send visitors to both addresses. Keep the old instance read-only and watch logs on both sides. Do not allow two independent writable databases.
Step 7: verify after the switch
- Multiple networks resolve the new IPv4 and IPv6.
- TLS covers every hostname and redirects are not looping.
- Forms, orders, mail, webhooks, cron and workers function.
- Canonical URLs, robots directives and sitemap remain correct.
- External monitoring and alerts target the new host.
- CPU, memory, latency, free space and 5xx rates are healthy.
Retain the old service for several days according to project risk. Delete it only after checking new data and an off-site backup.
Frequently asked questions
How long does a migration take?
A prepared small site can move in hours. Large data volumes and major version changes need a separate test cycle; verification usually takes longer than copying.
Do I need to move the TLS certificate?
Often it is simpler to issue a new certificate on the new host. Protect private keys if an existing certificate must be transferred.
When can I cancel the old server?
After DNS propagation, business-function checks, data reconciliation and a successful external backup. Important projects should keep a few days of margin.