Move to a new VPS or server
Moving to a new server is a rebuild: harden it, move apps, data, secrets and scheduled jobs, update everything that knows the old IP, and decommission the old one safely.
Official sources last reviewed · How we review
Build your personalized plan
A few questions, revealed as they become relevant. Your answers stay in this browser.
Start with the basics
We never ask for phone numbers, card numbers, passwords or codes. Names of providers or nicknames are enough.
Your plan so far
13things this change touches
- critical4
- high6
- moderate3
- low0
Updates as you answer. Every item will explain why it’s there.
What could break
In a typical server plan, these are the most serious things to get right.
Snapshot the old server and take app-level backups
Critical · Data & files
If the old server fails mid-move, you may have nothing portable to restore from.
Docker and Compose stacks and their volumes
Critical · Data & files
Containers start on the new server with empty volumes, losing uploads, databases or configuration.
Dump and restore databases
Critical · Data & files
A corrupt or partial database on the new server, discovered later.
Secrets and .env files
Critical · Website & DNS
Apps start but fail to connect to services, or sessions and tokens break if signing secrets change.
IP allowlists at other services
Critical · Integrations & APIs
Your app runs but can't reach its database, payments or partners from the new IP.
Test against the new IP before switching
Critical · Website & DNS
Problems only appear once all traffic has moved.
Lower TTLs, then update A and AAAA records
Critical · Website & DNS
A stale AAAA record keeps sending IPv6 visitors to the old server, and long TTLs stretch the switch over hours.
Document how the old server is set up
High · Website & DNS
The new server is missing something the old one quietly did, and you find out when it breaks.
Provision and harden the new server
High · Website & DNS
Password logins and open ports get probed within minutes, and an unpatched server is an easy target.
Cron jobs and systemd timers
High · Integrations & APIs
Jobs silently stop, or run on both servers during the overlap and duplicate emails, charges or imports.
Before and after the change
Before you change it
- Snapshot the old server and take app-level backups
- Document how the old server is set up
- Provider account: two-factor, billing and alerts
- Provision and harden the new server
- Docker and Compose stacks and their volumes
- Dump and restore databases
- Secrets and .env files
- Cron jobs and systemd timers
- Reverse proxy and TLS certificates
- IP allowlists at other services
- CI/CD deploy targets and SSH host keys
- Test against the new IP before switching
After the change
- Stop writes and do a final data sync
- Lower TTLs, then update A and AAAA records
- Backups on the new server
- Monitoring, alerts and log shipping
- Verify services, jobs and renewals after the switch
- Decommission and wipe the old server
- Stop billing for leftovers
Your own plan adds or removes items based on your answers, and explains why each one is there.
The safe order
Doing things in the right sequence is what keeps you from getting locked out halfway through.
Before the change
Step 1: Back up and document the old server
Take a snapshot plus portable backups, and write down how the server is set up.
- Snapshot the old server and take app-level backups (critical risk)
- Document how the old server is set up (high risk)
Step 2: Build and harden the new server
Secure the account and the server before any data lands on it.
- Provider account: two-factor, billing and alerts (moderate risk)
- Provision and harden the new server (high risk)
Step 3: Move apps, data, secrets and scheduled jobs
Restore data and config, recreate jobs, and get certificates ready.
- Docker and Compose stacks and their volumes (critical risk)
- Dump and restore databases (critical risk)
- Secrets and .env files (critical risk)
- Cron jobs and systemd timers (high risk)
- and 1 more
Step 4: Update allowlists, mail and deploy targets
Make sure everything that knows the old server's IP or host key knows the new one.
- IP allowlists at other services (critical risk)
- CI/CD deploy targets and SSH host keys (high risk)
Step 5: Test against the new IP before switching
Use `curl --resolve` or a hosts-file entry with your real hostnames.
- Test against the new IP before switching (critical risk)
During the change
Step 6: Switch traffic
Stop writes, do a final sync, then move DNS or the CDN origin.
- Stop writes and do a final data sync (high risk)
- Lower TTLs, then update A and AAAA records (critical risk)
Immediately after
Step 7: Turn on backups and monitoring
Recreate the safety nets on the new server.
- Backups on the new server (high risk)
- Monitoring, alerts and log shipping (moderate risk)
Verify
Step 8: Verify everything on the new server
Check services, scheduled jobs and certificate renewals with real traffic.
- Verify services, jobs and renewals after the switch (high risk)
Clean up
Step 9: Decommission the old server
After an overlap, wipe it, revoke its access and stop the billing.
- Decommission and wipe the old server (high risk)
- Stop billing for leftovers (moderate risk)
Why this change needs a plan
Moving to a new server is a rebuild: provision and harden it, move apps, data, secrets and scheduled jobs, test against the new IP, switch DNS and decommission the old one.
What could break: anything that knows the old IP address (allowlists, VPN clients, deploy pipelines), scheduled jobs that live outside your app, reverse DNS and outbound mail, and data written after your last copy. The old server's snapshots and volumes can also keep billing after it's gone.
Why it matters
Servers hold data and quietly run jobs nobody thinks about until they stop. A careful move keeps services up, data intact and the old server from becoming a forgotten security risk.
What makes it risky
Risk is highest when databases or volumes hold live data, when other services allowlist the server's IP, and when the server sends email.
Common mistakes
- Forgetting cron jobs and systemd timers that aren't part of the app's code.
- Updating the A record but leaving an old AAAA record that sends IPv6 visitors to the old server.
- Not updating IP allowlists, CI/CD deploy targets and known SSH host keys.
- Deleting the old server while its snapshots, volumes and reserved IPs keep billing.
- Copying a running database's data files instead of using a proper dump.
Frequently asked questions
Can I copy the whole server image to a new provider?
Sometimes, but rarely cleanly: images often depend on the provider's kernel, drivers and network setup. Rebuilding on a fresh, hardened server and restoring data from portable backups is usually more reliable and gives you a cleaner system.
How do I move a server without downtime?
Build and test the new server while the old one keeps running, lower DNS TTLs a day ahead, then do a short write freeze and final data sync at the switch. Downtime is usually limited to that final sync.
Why do I see 'REMOTE HOST IDENTIFICATION HAS CHANGED' after moving?
The new server has a different SSH host key from the old one at the same address. Check the new key's fingerprint in the provider's console, then remove the old entry from known_hosts (for example with `ssh-keygen -R hostname`) on your machine and in CI.
Why can't my new server send email?
Some providers block outbound port 25 by default on new servers, and mail from an IP without reverse DNS is often rejected. Check the provider's policy, set reverse DNS, update SPF, or send through an authenticated relay or email service.
When should I delete the old server?
Once DNS has moved, its access logs show no real traffic for several days, scheduled jobs are running on the new server, and you have a final backup stored elsewhere.