The safest Linux VPS migration is a rehearsed, side-by-side cutover: inventory the old server, build and secure the replacement, copy files in stages, move the database with database-aware tools, test the new address privately, freeze writes for a final sync, then change DNS and keep the old VPS ready for rollback. A short maintenance window is achievable, but its length depends on database size, write volume, replication, application behavior, and DNS caching.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What a VPS migration actually involves
You are moving more than a web directory. A production VPS usually contains application code, persistent uploads, database records, scheduled jobs, queue workers, mail settings, TLS certificates, firewall rules, users, SSH keys, secrets, monitoring agents, and third-party callbacks. Missing one dependency can leave the homepage working while logins, payments, uploads, webhooks, or background jobs fail.
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
Use a parallel build rather than modifying the existing machine in place. The old VPS remains the known-good system while the new VPS is assembled, tested, and placed behind the same application configuration. DNS becomes the traffic switch, and the old host remains available until the rollback period has passed.
Choose the replacement VPS before copying anything
Size the destination for current usage plus growth, not merely the old plan’s advertised limits. Compare the following characteristics for the region and operating system you intend to use:
| Decision area | What to verify | Why it affects migration |
|---|---|---|
| Operating system and runtime | Distribution release, kernel expectations, web server, language runtime, PHP-FPM or equivalent pools, container engine, and database versions | Matching major versions reduces compatibility surprises; newer versions should be tested before production traffic arrives. |
| Capacity and headroom | CPU cores, RAM, disk size, inode capacity, and expected growth in the next 12–24 months | The destination must hold the live dataset, temporary dump files, logs, and safety margin during the cutover. |
| Storage performance | SSD or NVMe class, I/O limits, and whether database workloads are supported | Slow or throttled storage can make a final dump, queue processing, or recovery take much longer than on the old host. |
| Network and region | Datacenter location, latency to users and dependencies, IPv4 and IPv6 availability, bandwidth policy, and reverse-DNS controls | Changing region or address family can affect latency, allowlists, mail reputation, and webhook delivery. |
| Security controls | Private networking, stateful firewall, SSH key support, security groups, and console or rescue access | Out-of-band access is valuable when a firewall or SSH change locks you out. |
| Backups and snapshots | Snapshot behavior, retention, restore procedure, and whether backups are stored off the VPS | A snapshot is not a substitute for an application-consistent database backup, but it shortens recovery from a failed build. |
| Monitoring and support | External health checks, alerting, support response, and any migration assistance included in the service | You need to detect failures from outside the new machine and obtain help if networking or storage behaves unexpectedly. |
| Reversibility and cost | Ability to retain the old VPS, attach extra storage, reserve addresses, and cancel without destroying data | A simple rollback is more important than a small initial price difference. |
Record the selected operating-system image, kernel, public addresses, hostname, and planned maintenance window in a change document. Do not place passwords, private keys, API tokens, or other secrets in that document; use the existing secret-management process.
Inventory the old Linux server first
Take the inventory while the old VPS is still healthy. Capture outputs in a restricted location and note which items are managed manually, by configuration management, or by a hosting control panel.
- Operating-system release and architecture.
- CPU, memory, disk and inode usage, mount points, RAID or attached volumes, and filesystem types.
- Listening ports, public and private interfaces, firewall rules, and any IP allowlists.
- Enabled systemd services, container stacks, socket units, and service dependencies.
- Cron entries for every relevant user, system-wide cron files, and systemd timers.
- Web-server virtual hosts, document roots, rewrite rules, upstreams, and upload locations.
- TLS certificate names, renewal jobs, private-key locations, and certificate-chain requirements.
- Application runtimes, environment variables, configuration files, service accounts, and file ownership.
- Database engines, versions, database names, roles, extensions, scheduled jobs, and connection limits.
- Persistent uploads, generated assets, queues, search indexes, mail spools, and any data outside the main document root.
- SSH users, authorized keys, sudo rules, deployment keys, monitoring agents, backup jobs, and third-party callbacks.
These commands provide a starting point; run them with appropriate privileges and save their output securely:
cat /etc/os-release
ss -tulpn
systemctl list-unit-files --state=enabled
crontab -l
df -h
df -iAlso inspect per-user crontabs, /etc/cron.*, systemd timers, container manifests, and the DNS zone. Make a dependency map: for example, a web service may depend on PHP-FPM, a local Redis instance, a database, a queue worker, and an outbound SMTP relay. The map determines the order in which services must be restored.
Lower DNS TTL 12–24 hours before cutover
Change the TTL on every A and AAAA record that will move, including relevant subdomains. A commonly recommended preparation value is 300 seconds (five minutes), applied 12–24 hours before the switch. This gives recursive resolvers time to expire records cached under the previous, longer TTL.
TTL is not a command to every resolver. Some resolvers, browser caches, local networks, and application clients may retain an address longer, and changing the authoritative record does not update all users instantly. Keep the old VPS reachable throughout the propagation period. After the new host has handled normal traffic and rollback is no longer needed, restore your normal TTL rather than leaving an unnecessarily short value in place.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Build and harden the new VPS
Install a clean, supported operating-system image unless you have a documented reason to preserve the old image. Apply updates before exposing application services. Set the correct timezone and time synchronization, because inaccurate clocks break TLS validation, scheduled tasks, logs, and database replication.
- Create a non-root administrative path. Add an administrator, install its SSH public key, grant only the required sudo access, and test a second session before changing root-login policy.
- Update the base system. Install security updates, the migration tools (including
rsync), required language runtimes, database packages, and monitoring agents. - Configure the firewall. Permit SSH only from approved networks where possible. Open HTTP and HTTPS, database ports only on private networks or trusted source addresses, and any application-specific ports required by the dependency map.
- Set identity and time. Choose a unique hostname, configure DNS or
/etc/hostsconsistently, enable NTP, and verify that logs use the intended timezone. - Prepare storage. Mount data volumes at the paths expected by the application, confirm ownership and boot-time mounts, and reserve free space for database dumps, temporary files, and logs.
- Enable backups and external monitoring. Test that a backup can be restored and that an HTTP, TCP, or synthetic check runs from outside the VPS.
Keep major operating-system, web-runtime, database, and container versions aligned where practical. If you must upgrade during the move, treat that as a separate change: test the upgrade on the new host before adding DNS to the equation.
Copy files with staged rsync passes
Use SSH-key authentication and rsync for application code, uploads, static assets, reviewed configuration, and other persistent files. Do not copy live database storage directories, sockets, caches, PID files, or temporary data.
sudo rsync -aHAX --numeric-ids --info=progress2
root@OLD_SERVER_IP:/var/www/ /var/www/The archive flags preserve permissions, links, timestamps, and (where supported) extended attributes and ACLs; --numeric-ids avoids translating ownership by username between hosts. Adapt the source, destination, and account to your layout. A safer first pass can use an explicit exclusion file:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →sudo rsync -aHAX --numeric-ids --info=progress2
--exclude='cache/'
--exclude='tmp/'
--exclude='*.sock'
root@OLD_SERVER_IP:/srv/app/ /srv/app/Run the first pass well before the maintenance window. Repeat it after testing and again during the final cutover; subsequent passes transfer only changed files. Review ownership with namei -l, stat, and the service account definitions. If an application writes outside its documented directory, include that path explicitly rather than assuming the document root contains everything.
Move the database with database-aware tools
Never rsync a live database’s data directory while the database is accepting writes. Storage files can be internally inconsistent, and copying them between different database versions or filesystem states can prevent startup or silently lose transactions.
PostgreSQL logical dump
A custom-format dump can be transferred and restored on the destination:
# old VPS
sudo -u postgres pg_dump -Fc appdb > /tmp/appdb.dump
scp /tmp/appdb.dump root@NEW_SERVER_IP:/tmp/
# new VPS
sudo -u postgres createdb appdb
sudo -u postgres pg_restore --clean --if-exists -d appdb /tmp/appdb.dumpAlso migrate roles, grants, extensions, and connection settings. Test a restore before the production window; a dump that exists is not proof that the application can authenticate to it.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteMySQL or MariaDB
For a database that can remain available during the dump, use a consistent transaction snapshot such as:
mysqldump --single-transaction --routines --triggers appdb > /tmp/appdb.sqlTransfer the dump securely, create the destination database and accounts, import it, and verify character sets, collations, stored routines, triggers, and event schedules. Engines or tables that cannot be captured consistently with a transaction snapshot require a maintenance window or native replication.
Busy databases and replication
If writes continue after the first dump, later writes must reach the destination. Schedule a controlled read-only period for the final dump, or configure database-native replication and perform a planned promotion. Record the replication position or last transaction, monitor lag, and rehearse promotion. The final procedure must make it impossible for the old and new applications to accept conflicting writes.
Recreate application services, jobs, mail, and TLS
Install and configure the web server, runtime pools, process supervisors, queue workers, and systemd units from the dependency map. Recreate environment variables and secret references from the approved secret store rather than pasting credentials into shell history or migration notes.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Match virtual-host names, document roots, upstream sockets, redirect rules, upload limits, and timeout settings.
- Restore cron jobs and systemd timers, then disable them until the cutover so scheduled work cannot run on both hosts.
- Configure queue consumers and scheduled workers with a clear owner. During the final switch, workers must run on only one VPS.
- Recreate outbound mail transport, SPF/DKIM-related settings, SMTP credentials, and firewall egress rules. Send a controlled test message.
- Re-issue TLS certificates when that is safer than copying private keys. Confirm the complete certificate chain, renewal automation, and the certificate names needed by every virtual host.
- Update webhook endpoints, payment or API allowlists, monitoring targets, and callback signatures that depend on the server address.
After each service starts, inspect its logs and status instead of assuming that a successful process start means the application is healthy.
Test the new VPS privately before changing public DNS
Use a workstation hosts-file entry or curl --resolve to send requests to the new address while public DNS still points to the old host:
curl --resolve example.com:443:NEW_SERVER_IP https://example.com/Test both anonymous and authenticated paths. The checklist should include:
- Homepage, redirects, canonical host handling, static assets, and large uploads.
- Login, session persistence, password reset, database reads and writes, and representative transactions.
- Queue insertion and consumption, scheduled jobs, image or video processing, and any workers that use external APIs.
- Outbound email, inbound mail if hosted locally, webhooks, callback verification, and third-party IP allowlists.
- TLS chain, HTTP/2 or HTTP/3 behavior if enabled, IPv4 and IPv6 responses, and firewall exposure from an external network.
- Application, web-server, database, and kernel logs; disk, memory, CPU, connection, and queue metrics.
- Backup execution and restoration of at least one representative file and database backup.
Exercise a representative workload rather than checking only a static page. If the application writes files, confirm they appear with the expected owner and survive a service restart. If it sends jobs, verify that a job is not processed twice.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Execute the final cutover
Announce the maintenance window, prepare a backout decision, and keep administrators connected to both VPSs. A typical sequence is:
- Enable maintenance or read-only mode on the old application. Reject new writes and display a clear status message. Stop public traffic only after active requests have drained, if your application supports graceful draining.
- Stop old workers and schedulers. Disable queue consumers, cron-triggered jobs, and timers so work cannot execute concurrently on both systems.
- Run the final file synchronization. Repeat the reviewed
rsynccommand, including uploads and generated assets created since the previous pass. - Complete the final database move. Create the final logical dump and restore it, or finish the planned replication cutover. Verify row counts, the latest transaction, roles, and application connectivity.
- Start the destination in dependency order. Bring up the database, cache or message broker, application runtime, web server, and finally the workers and schedulers.
- Run smoke tests against the new address. Check a login, a representative write, an upload, a queue job, a health endpoint, and a controlled email before opening traffic.
- Change DNS. Update the A and AAAA records and any moved subdomains to the new address. Record the exact time and previous values for rollback.
- Keep the old host safe. Leave the old application in a controlled state until traffic, logs, and metrics confirm that the new host is serving correctly.
Do not remove the maintenance lock merely because DNS was edited. Some users will continue reaching the old address while caches expire; decide whether the old host should remain read-only, proxy to the new host, or display maintenance during that interval.
Monitor propagation and keep rollback available
Watch both VPSs and query DNS from several networks. Monitor access and error rates, application latency, database connections, queue depth, mail delivery, disk growth, and authentication failures. Compare expected traffic on the new address with residual traffic on the old one.
Define rollback criteria before the change, such as failed writes, unrecoverable queue duplication, missing data, broken TLS, or sustained error rates above your normal threshold. If a criterion is met:
- Put the new application in maintenance or read-only mode and stop its workers.
- Restore the DNS A and AAAA records to the old address.
- Resume the old services only after confirming that no writes were accepted exclusively by the new host, or reconcile those writes deliberately.
- Document the failure, preserve logs, and correct the destination before attempting another cutover.
Keep the old VPS intact until the replacement has handled representative traffic and at least one verified backup has completed. Do not rely on DNS TTL as a guarantee that every client has switched.
Post-migration verification and decommissioning
After the rollback window, restore the normal DNS TTL. Revoke temporary SSH keys, API tokens, database accounts, firewall allowances, and provider access used only for migration. Confirm that external backups, monitoring, certificate renewal, scheduled jobs, and incident contacts reference the new host.
Take a fresh documented backup of the destination and perform a restore test. Capture the final inventory, DNS values, service versions, mount points, and recovery steps. Only then shut down and delete the old VPS according to your retention policy. Keep any required logs or backup artifacts for the period required by your operational or regulatory obligations.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchCommon failure modes and fixes
| Symptom | Likely cause | Correction |
|---|---|---|
| Homepage loads but login fails | Missing secret, wrong session key, database role, or cookie domain | Compare environment settings, recreate the role or secret reference, and test an authenticated request privately. |
| Uploads disappear after migration | Upload directory was omitted, mounted at a different path, or owned by the wrong account | Locate every persistent upload path, run a targeted rsync, fix ownership, and test a new upload plus a restart. |
| 502 or gateway errors | Runtime socket path, service user, firewall, or upstream address differs | Check web-server and runtime logs, confirm the socket exists, verify permissions, and test the upstream locally. |
| Jobs run twice | Workers or timers remained active on both VPSs | Stop the old consumers, inspect the queue for duplicate claims, and use idempotent job handling where possible. |
| Database is missing recent records | Final writes occurred after the initial dump | Use a write freeze for the final dump or complete replication; do not treat the first dump as current. |
| Some users still see the old site | Resolver, browser, or local-network caching | Keep the old host safe, query multiple resolvers, and wait for caches instead of repeatedly changing records. |
| TLS warning appears | Certificate lacks a hostname, chain is incomplete, or IPv6 reaches an unconfigured service | Validate every hostname over IPv4 and IPv6, install the full chain, and renew or re-issue the certificate. |
| SSH access is lost | Firewall, key permissions, sshd configuration, or wrong address | Use the provider console or rescue access, restore a tested administrative path, then tighten policy gradually. |
How long should the cutover take?
There is no universal downtime figure. File volume, database size, write rate, replication lag, application behavior, and resolver caching determine the real window. A well-rehearsed migration can reduce the write freeze to the time required for the final synchronization and validation, while an untested or very large database may require a longer maintenance period. Measure your initial rsync and test restore times; use those observations to schedule the window rather than promising a fixed duration.
The repeatable migration pattern
The durable method is simple to state but strict in execution: inventory first, lower DNS TTL in advance, build a hardened destination, transfer files repeatedly, move the database with a consistent logical or replication method, test privately, freeze writes, synchronize one final time, switch DNS, monitor both hosts, and retain a verified rollback path. Treat the rehearsal and rollback decision as part of the migration itself, not as optional paperwork.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
