Skip to main content
DCHost / Practical guide

VPS and VDS migration: data, DNS and rollback checklist

By the end: You will have a sequence for moving to the new server and a plan to protect data if something goes wrong. The old server is the current live environment; the new server is your prepared destination.

Moving a server involves more than copying files to a new IP address. Databases, background jobs, outgoing email, TLS, credentials and external IP allowlists must also work in the new environment. This guide helps you plan an application migration from a Linux VPS, VDS or dedicated server.

If you are moving a ready-made cPanel account, start with the website migration guide. The commands below require dig and curl on your computer. They do not include application-specific file or database transfer commands.

Visual guideThe server migration sequence

Access, data and application checks matter as well as copying files.

  1. Plan and back up

    List dependencies and prepare a separate copy you can restore.

  2. Test the destination

    Test the new server and application before changing public DNS.

  3. Sync the final data

    Control writes, transfer the final records and compare them.

  4. DNS and verification

    Change the destination; monitor both environments and where new records are written.

Keep the old service until the new application and backup routine are verified.

1. Record the current environment and recovery path​

Start one migration note containing:

  1. Old server IP and new server IP.
  2. Domains, applications and databases to move.
  3. Location of the latest backup and the person restoring it.
  4. Person responsible for DNS and the maintenance time.

Check: You need access to the old server, new server and DNS management. Resolve missing access before migration day.

Start with domains, A/AAAA records and TTL values. List the operating system, runtimes, database version, installed services, scheduled jobs, data size and licenses. Record SMTP, payment, webhook and API dependencies, including IP allowlists. You need permission to change DNS and access to the old server.

Create a current backup stored separately from the server and prepare a restore plan. Keep the old service until the migration is verified. Moving servers does not require changing your domain registrar.

2. Prepare the new server before changing DNS​

Goal: Prepare and test the new server while visitors still use the old one. The curl command below runs on your computer; it does not change public DNS.

Set up compatible operating system and application components. Transfer files, databases and required configuration while preserving appropriate permissions. Do not leave backups or database dumps in a public web directory. Prevent uncontrolled email, payment and scheduled processing on the new environment: running the same task on two servers can cause duplicate notifications or transactions.

Replace example.com and 203.0.113.10 with your own domain and destination IP. Run this command on your computer to send only this HTTPS request to the chosen IP without changing public DNS:

curl --resolve example.com:443:203.0.113.10 -I https://example.com/

This checks the TLS connection and HTTP headers using the correct hostname. The certificate must be valid for that hostname; do not use -k to bypass certificate errors. Prepare the certificate using a suitable validation method, or use a protected staging environment.

Successful response headers do not prove that login or ordering works: test the application's essential flows separately using a browser preview. Applications that do not support HEAD requests need that limitation taken into account.

Command partMeaning
--resolve example.com:443:203.0.113.10Uses the new IP for this request to the domain
443The HTTPS port
-IRequests HTTP headers instead of the page body
https://example.com/The test address; replace with your domain

Check: Inspect the expected HTTP response without certificate errors. A 200 response or expected redirect is useful evidence, but does not verify every application function.

3. Keep writes in one place during the final transfer​

Visual guideKeep new writes in one place

Decide explicitly which environment can accept new data during the move.

  • Old server

    Stop new writes for the final transfer. Preserve the old copy for recovery.

  • New server

    Enable writes after verifying the final data. Monitor new orders and records.

Changing DNS back does not move new records to the old server; preserve them separately during rollback.

What are “writes”? Actions that add or change data, such as orders, signups, comments and uploads. Prevent them from being split across both servers during the move.

  1. Stop new writes on the old environment in a controlled way.
  2. Transfer the final data.
  3. Compare record counts and important records.
  4. Enable writes only in the chosen new environment.

Queues and scheduled tasks can change data too; include them in the same plan.

For applications accepting orders, signups or uploads, plan a short maintenance window or an application-appropriate synchronization procedure. Writes to both the old and new databases can create records that are difficult to reconcile later.

After stopping new writes on the old system, transfer the final data and compare record counts and critical records. Decide where queues and scheduled jobs should run. Establish when to enable writes on the new system and how to preserve any new records if you need to roll back.

4. Change DNS and monitor both environments​

Small glossary: A specifies IPv4, AAAA specifies IPv6, and MX specifies mail servers. TTL controls how long a record can be cached.

Make changes in the authoritative DNS management service. The dig commands below only query results from your computer; they do not change records.

If lowering TTL, do so early enough for the existing TTL to expire; changing it does not immediately flush old caches. Check the website's A record and any AAAA record. An outdated AAAA record can send some visitors to an old IPv6 destination.

Preserve MX, SPF, DKIM and DMARC records if email remains with a separate service. If changing nameservers, prepare the whole DNS zone rather than just the website record. After the change, run on your computer:

dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig example.com MX +noall +answer

These results show what your selected DNS resolver returns, not what everyone worldwide sees. Check authoritative DNS answers and access from other networks too. Watch access and error logs on both the old and new servers.

Check: A/AAAA should match the planned web destination, and MX the intended email service. No AAAA answer may be correct when you do not use IPv6. Verify what uses old records before removing them.

5. Verify the completed migration​

Run checks in order:

  1. HTTPS and administrator sign-in.
  2. Uploads and forms.
  3. Email and safe payment testing.
  4. Records in the new database.
  5. Scheduled jobs and the new backup routine.

Completion rule: Keep the old server until essential operations and data consistency are verified.

Check HTTPS, administrator login, uploads, forms, email delivery, the payment integration's test flow and scheduled tasks. Use application test modes or controlled accounts for sensitive actions. Confirm that writes reach the new database. Keep old copies until the new backup routine works.

If a problem occurs, switching DNS back may not be enough: orders and records created on the new server must be preserved. First control writes, assess differences between environments and follow the data rollback plan. DNS caching means rollback is not instantaneous either.