VPS migration checklist: move a website with near-zero downtime (2026)

A clean migration usually fails for boring reasons. You forgot to lower DNS TTL. Cron ran on both servers. PHP didn’t match. Or mail kept landing on the old box.

This VPS migration checklist is the hosting-focused playbook for 2026. It covers what to inventory, what to copy, what to freeze, and how to cut over with a rollback you can execute under pressure.

The goal isn’t mythical “zero downtime.” It’s near-zero downtime you can defend. Most visitors never notice, and if something breaks you can revert within minutes.

Pick the right migration approach before you touch DNS

Different stacks fail in different places. Pick the approach first. Then design the cutover around the real risk.

• Simple content site (WordPress, brochure, small WooCommerce): build in parallel on the new VPS, copy files + database, then cut over DNS. Lowest day-of risk.
• Busy dynamic site (membership, WooCommerce, frequent writes): you need a write-freeze window or database replication. If you can’t stop writes, the database becomes your downtime bottleneck.
• Multiple sites + email on the same server: treat web and mail as separate projects. Move web first, then migrate mail once the site is stable.

If you’re unsure how big the destination should be, size for peak load plus headroom. Don’t size for weekly averages.

HostMyCode’s capacity planning guide helps you avoid moving onto another underpowered VPS: Linux VPS capacity planning in 2026.

Pre-migration inventory: the stuff you forget until it’s broken

Do the inventory before you provision anything. It’s faster than reverse-engineering the old server mid-cutover.

• Domains and DNS: zone records, TTL values, nameservers, subdomains, and any CDN/WAF settings.
• Web stack: Nginx/Apache/LiteSpeed versions, PHP version(s), PHP-FPM pool settings, Node/Python services, systemd units.
• Certificates: where TLS certs live, ACME client used, renewal hooks, and whether you use wildcard DNS-01.
• Databases: MySQL/MariaDB/PostgreSQL versions, users, grants, scheduled jobs, and backup tooling.
• Email: MX records, mailboxes, aliases, SPF/DKIM/DMARC, outbound relay settings, and deliverability monitoring.
• Scheduled tasks: crontab entries, systemd timers, queue workers (WP cron alternatives, Laravel queues, etc.).
• Integrations: payment gateways, webhooks, allowlists, license servers, S3 endpoints, OAuth callbacks.

Keep the inventory in one place. Use a text file in a private repo, or a note in your password manager.

During cutover, you want one source of truth. You don’t want a scavenger hunt through old tickets.

Provision the destination VPS with predictable defaults

Don’t migrate onto a “pet server” image you’ve tweaked for years. For moves, boring and repeatable beats clever.

For hands-on control, use a VPS where you pick the OS and stack from scratch. A HostMyCode VPS fits well when you want root access, clean builds, and a clear performance baseline.

If you’d rather offload patching and routine operations, managed VPS hosting is a safer option for production sites with tight business hours.

Recommended server baselines for 2026 migrations (web workloads):

• Ubuntu 24.04 LTS for broad package support and current OpenSSL/OpenSSH defaults.
• Debian 12 when you want minimalism and stable packages with fewer surprises.
• AlmaLinux 9 / Rocky Linux 9 if you’re in the RHEL ecosystem or use cPanel/WHM commonly.

Set up monitoring before you move traffic. Otherwise you’ll discover CPU steal, disk latency, or memory pressure after the DNS flip.

For a practical baseline, see: Linux VPS performance monitoring in 2026.

Lower DNS TTL early (and know what it actually changes)

TTL doesn’t “speed up DNS” everywhere. It limits how long recursive resolvers cache your record after they re-query.

That’s still enough to shrink the cutover tail from hours to minutes.

24–48 hours before migration day:

• Lower the TTL for A/AAAA records you will change (typically 300 seconds).
• Lower TTL for www, api, and any other hot hostnames.
• Leave MX TTL alone unless you’re moving mail on the same day.

Quick check (from your workstation):

dig +noall +answer example.com A

You should see the TTL value drop to your target.

If you’re also moving nameservers at the registrar level, treat that as a separate change. Nameserver swaps often have longer, messier propagation.

Data migration: copy twice, cut once

The smoothest moves use two passes. Do a bulk sync ahead of time. Then do a short final sync during the freeze window.

Web files (static + uploads)

For typical web roots like /var/www or /home/user/public_html, rsync remains the reliable option. Preserve permissions and timestamps.

rsync -aHAX --numeric-ids --delete \
  -e "ssh -p 22" \
  /var/www/ root@NEW_SERVER:/var/www/

Pitfall: if you’re switching control panels (or moving from no panel to cPanel), numeric IDs may map differently.

In that case, drop --numeric-ids and fix ownership explicitly on the destination.

Databases (MySQL/MariaDB)

For most WordPress and PHP apps, a logical dump is predictable and portable. Do an early dump/import to prove the process.

Then take a final dump during the freeze.

mysqldump --single-transaction --routines --triggers \
  --default-character-set=utf8mb4 DBNAME \
  | gzip > db.sql.gz

Import on the destination:

zcat db.sql.gz | mysql DBNAME

For high-write sites, replication is often safer than extending the freeze window.

If you need a stronger DR mindset across servers, this is a useful reference: Production database backup strategies in 2026.

WordPress specifics (don’t skip these)

• Confirm wp-config.php salts/keys copy correctly.
• Verify siteurl and home values (especially if you tested on a temporary domain).
• Move wp-content/uploads and any cache directories your setup depends on.
• Rebuild permalinks after cutover if you change Nginx/Apache rules.

If speed is the main reason you’re migrating, keep performance changes intentional. Swapping stacks mid-move is how you end up debugging 502s at midnight.

For a WordPress performance baseline in 2026, see: WordPress hosting performance optimization in 2026.

SSL and HTTPS: plan the cutover so browsers don’t complain

You have two safe options:

• Re-issue certificates on the new server using Let’s Encrypt (recommended). It’s clean, and renewals stay straightforward.
• Copy existing certificates if you use a commercial cert with a fixed chain and private key you must preserve.

On Nginx-based setups, you’ll typically touch files in /etc/nginx/sites-available/ and certs under /etc/letsencrypt/ (Let’s Encrypt).

If you want a reference for TLS termination and proxying, this guide is a solid template: Nginx SSL reverse proxy with Let’s Encrypt.

Pitfall: if your origin IP changes and you rely on HTTP-01 challenges, confirm port 80 is reachable on the new VPS before requesting certificates.

If ACME can’t validate, you’ll burn time during the cutover.

Email and DNS hygiene: protect deliverability during and after the move

A lot of “website migrations” turn into accidental mail migrations because the DNS zone is shared.

Treat mail as its own system with its own failure modes.

If you are not moving email:

• Do not change MX records.
• Keep SPF aligned with your sender (e.g., Google Workspace, Microsoft 365, or your existing mail host).
• Confirm your web server’s IP isn’t listed in SPF unless it actually sends mail.

If you are moving email to the new server, plan for:

• SPF update to include the new outbound IP (or better: send through a relay that stays constant).
• DKIM key migration or regeneration, plus publishing the new TXT record.
• DMARC policy continuity (p=none/quarantine/reject) and a mailbox for aggregate reports.
• Reverse DNS (PTR) aligned with your hostname for outbound mail reputation.

Rule of thumb: if email revenue matters, don’t change your outbound IP and mail stack on the same day as the web cutover.

Stagger the risk.

Freeze window: what to stop so you don’t duplicate work or corrupt data

The freeze window is the short period where you stop writes on the old server, run the final sync, and then flip traffic.

Keep it short. Keep it written down.

At minimum, during the freeze:

• Disable app-level writes (maintenance mode, “coming soon”, or read-only toggle if your app supports it).
• Stop queue workers and background jobs on the old server.
• Disable crons that send emails, charge cards, or process orders.

Concrete examples:

• WordPress: enable a maintenance plugin, or restrict writes via admin policy; if you run real cron, disable the system cron line temporarily.
• systemd timers: systemctl list-timers, then systemctl stop NAME.timer for anything that writes.
• Crontab: comment out jobs in /etc/crontab and user crontabs (crontab -e) and keep a copy of the original.

Make this a checklist you can execute even when you’re tired and time is tight.

Cutover sequence: a safe order that minimizes surprises

Cutover is a short chain of steps. Keep the sequence consistent.

Consistency makes it easier to repeat and easier to roll back.

1. Final sync: rsync the web root again; take the final database dump and import.
2. Start services on the new VPS: Nginx/Apache, PHP-FPM, database (if local), caching services, queue workers (keep workers paused until validation).
3. Smoke test via hosts file: point your workstation to the new IP without changing public DNS.
4. Change DNS A/AAAA: update records to the new VPS IP.
5. Enable jobs on the new VPS: cron, timers, queue workers.
6. Monitor: error logs, response codes, and order/email flow.

Hosts file example (temporary):

# /etc/hosts (Linux/macOS) or C:\Windows\System32\drivers\etc\hosts
203.0.113.10 example.com www.example.com

This is where you catch missing PHP extensions, incorrect permissions, or broken rewrites before real users hit them.

Validation checklist: what to verify in the first 60 minutes

Don’t just click around and hope. Verify the paths that affect revenue, sign-ins, and SEO first.

• HTTP status: homepage and key landing pages return 200, not 301 loops or 403/404.
• Admin login: WordPress /wp-admin works, and you can save a post (after unfreezing).
• Checkout / forms: test card (sandbox if possible), contact forms, password reset emails.
• Media: random images and PDFs load; permissions are correct.
• Critical headers: HSTS, redirects, and canonical host (www vs apex) behave as expected.
• Robots and sitemap: robots.txt is correct; sitemap resolves.
• Logs: tail Nginx/Apache error logs and PHP-FPM logs for recurring errors.

Quick log checks (common paths):

tail -n 100 /var/log/nginx/error.log
journalctl -u php8.3-fpm -n 100 --no-pager

If you want a clearer long-term picture of what changed after the move, central log shipping helps.

This rsyslog-based approach is lightweight and practical: Linux VPS log shipping with rsyslog.

Rollback plan: decide what “back out” means before you migrate

A rollback plan isn’t “we’ll fix it fast.” It’s a trigger, a time limit, and a simple set of steps you can follow.

Define:

• Rollback trigger: e.g., checkout failures, persistent 5xx, login broken, missing orders.
• Rollback timebox: e.g., if not stable in 20 minutes, revert DNS.
• Rollback mechanism: DNS A/AAAA back to old IP (fastest) or CDN origin swap.

After you change DNS, keep the old server running for at least 48–72 hours.

Even with a reduced TTL, some clients will cling to cached answers longer than you’d expect.

If you can snapshot both servers right before cutover, do it. Snapshots aren’t a long-term backup strategy, but they’re excellent for quick recovery and fast diffing.

HostMyCode lays out a good operational pattern here: Linux VPS snapshot backups.

After the migration: cleanup that prevents next week’s outage

The move isn’t “done” when the homepage loads. The cleanup is what keeps the new VPS stable next week.

• Raise TTL back to a reasonable value (often 3600–14400 seconds) once stable.
• Confirm backups run on the new VPS and that restores are tested.
• Update firewall rules and allowlists (payment gateways, remote admin IPs, API providers).
• Re-enable security tooling (WAF rules, rate limits, Fail2Ban if you use it).
• Decommission carefully: keep old server for a few days, then wipe disks before termination.

Review your resource graphs after the cutover. If load average is down but latency is up, look at disk I/O and PHP-FPM tuning.

The usual wins are unglamorous: right-size PHP-FPM children, enable OPcache, and set correct cache headers.

Summary: a VPS migration checklist that matches real production constraints

This VPS migration checklist is mostly about sequencing. Inventory first. Build a predictable destination. Lower TTL early. Copy data twice.

Then freeze writes briefly, cut over, and keep validation and rollback ready. Do that and near-zero downtime becomes repeatable, not luck.

If you want a stable place to land after the move, start with HostMyCode VPS for full control, or use managed VPS hosting if you’d rather have experienced hands covering patching, monitoring, and production hygiene. Either way, you’re building on HostMyCode’s promise: Affordable & Reliable Hosting.

FAQ

How long should I keep the old VPS running after DNS cutover?

Plan for 48–72 hours. Even with a 300-second TTL, some resolvers and client networks won’t re-query quickly. Keeping the old server online also gives you an easy rollback path.

Can I migrate a WooCommerce site with zero downtime?

True zero downtime is hard because orders are constant writes. You can get near-zero downtime by scheduling a short write-freeze window, doing a final database sync, then cutting over DNS.

What’s the safest way to test the new VPS before changing DNS?

Edit your local hosts file to point the domain to the new IP, then browse and run checkout/form tests. This validates TLS, rewrites, and PHP behavior without exposing the new server publicly.

Should I copy SSL certificates or re-issue them?

Re-issue on the new server if you use Let’s Encrypt. It keeps renewals simple and reduces key-handling mistakes. Copy only when you must keep an existing commercial cert and private key.

What’s the most common migration mistake?

Forgetting non-obvious “writers”: cron jobs, queue workers, and webhook processors. They can create duplicate emails, duplicate charges, or mismatched data if they run on both servers during cutover.