VPS migration checklist: backups, DNS, TLS and rollback
A practical migration sequence for a self-hosted application: inventory, consistent backups, a tested destination, controlled writes, DNS cutover and a restore path.
At a glance
A controlled VPS migration inventories services and data, creates a consistent backup, verifies a restored destination, tests hostname and TLS routing, coordinates final writes and DNS, and preserves a data-aware rollback. No checklist alone guarantees zero downtime.
Inventory the application before moving it
List the services, versions, ports, scheduled tasks, databases, uploaded files and configuration needed for the application to work. Identify where writes happen and which external services it depends on. A copied web directory is not a complete migration when the data lives elsewhere.
Record current DNS names, active IPv4 and IPv6 records, certificate renewal methods and a recovery access path. Keep secrets in your private deployment tooling. Do not put passwords, private keys or database dumps into a public document root or a shared migration checklist.
Create a consistent backup and prove that it restores
Use the database-supported backup mechanism rather than copying arbitrary files while writes continue. For SQLite, the Online Backup API creates a consistent database snapshot. In WAL mode, the WAL file participates in persistent database state, so copying only the main database file can omit committed changes.
A consistent database backup is not automatically consistent with separately stored uploads, queues or files. Coordinate their capture with your application. Restore into a separate test location and verify records, file references and application behavior before treating the backup as usable.
Prepare the destination before changing DNS
Create the intended users, permissions, runtime versions, services and application directories on the new server. Restore the test backup into its destination data location, outside the public web root where appropriate. Check ownership and access using the service account that will actually run the application.
Preserve unrelated sites on a shared server. Use a dedicated document root, virtual host and runtime, validate the web-server configuration and prepare a rollback that restores only the files and configuration owned by this change.
Test the real hostname and certificate on the new server
A browser request to a bare IP address does not reproduce hostname-based routing or certificate validation. curl --resolve lets a test use the intended hostname and a chosen destination IP while retaining the normal hostname and TLS checks. Check the HTTP status and expected application content as well. The example uses documentation-only values; replace them with your own verified domain and destination.
A valid certificate and an allowed network path must already exist for that test to pass. Never disable certificate verification to call the migration ready. DNS-based ACME validation can validate a domain without changing its web-server address; HTTP-based validation has different reachability requirements. Test renewal separately from initial issuance.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Choose a write-control and final-sync plan
Schedule a short maintenance period or another application-appropriate consistency mechanism. Stop or redirect the writers you identified, take the final consistent database backup, synchronize the corresponding mutable files and verify the result. Queue workers, webhooks and cron tasks can write even when the public interface looks quiet.
Use a dry run before a file synchronization. Do not add deletion flags or copy entire system directories as a shortcut. Keep the old service recoverable until you have checked the new application and established which location is authoritative for writes.
Change DNS, then observe both address families
Update the records required for the service and account for existing resolver caches. Check the authoritative answers and several normal client paths. If an obsolete AAAA record remains active, IPv6 clients can continue reaching the old server while IPv4 clients reach the new one.
Test sign-in, reads, writes, uploads, background jobs and external callbacks on the new service. Avoid running two independent writable copies of the same application during the transition. Keep a clear rule for handling traffic that still reaches the old destination.
Make rollback a data decision as well as a DNS decision
Define the failure conditions that trigger a rollback and who controls the cutover. Reverting DNS alone is not enough after new writes have reached the destination: you must preserve or reconcile that data before returning to an older copy.
Keep the source and backups for an appropriate recovery period. Remove old access and decommission resources only after the destination, backups, renewal and monitoring have been checked. Retention and deletion should follow the actual service policy, not a generic fixed number of hours.