Post-migration checklist

Quick answer: After the DNS switch: verify the domain resolves to the new IP, click through the live site, confirm SSL and redirects, watch server logs and resource usage for 24–48 hours, re-enable backups and monitoring on the new server, and only then — after several clean days — cancel the old hosting.

Overview

The migration is not finished when DNS flips; it is finished when the new server has proven itself under real traffic and the safety nets (backups, monitoring, cron) are running on the new machine. This checklist closes the loop that migration day opens.

Before you start

• DNS switched to the new server and the old one still running as fallback.
• Access to logs on both servers.

Step-by-step guide

1. Confirm resolution: dig +short example.com from several networks (or an online checker) shows the new IP.
2. Click through the live site: key pages, forms, login, search, checkout — now over real DNS, not hosts file.
3. Verify SSL and redirects: HTTPS lock, HTTP→HTTPS redirect, www/non-www canonical.
4. Watch the logs: new server's error log should stay quiet; old server's access log should decay toward zero over 24–48 h.
5. Re-arm the safety nets: backups now target the new server, monitoring/uptime checks point at the new IP, cron jobs run on the new machine only.
6. Check email flow if mail moved: send and receive on each domain; verify SPF/DKIM/PTR for the new IP.
7. Update references: payment webhooks, external APIs with IP allowlists, CDN origins.
8. After several clean days: take a final archive of the old server, then cancel the old service.

Common issues

• Duplicate cron: jobs still running on the old server cause double emails and stale writes — disable them at cutover.
• Backups still pointed at the old box: the classic silent failure; confirm the first post-migration backup actually ran and restores.
• Cancelling the old host in 24 hours: too soon — DNS stragglers and forgotten data have a way of appearing on day three.

When to contact support

If errors appear only under real traffic (load spikes, odd bots, geo-specific issues), open a ticket with log excerpts — the new server's behavior under production load is something we can tune with you.

Frequently asked questions

How do I confirm DNS has fully propagated?

Query several public resolvers with dig or an online propagation checker and watch the old server access log decay to zero — both should agree within 24 to 48 hours.

When is it safe to cancel the old hosting?

After several days of clean logs on the new server, a verified first backup taken from the new machine, and a final archive of the old server stored somewhere safe.

What silently breaks most often after a migration?

Backups still pointed at the old server and duplicate cron jobs running on both machines. Check both explicitly on day one — neither announces itself when wrong.

Related articles

• Migration checklist
• Common migration issues
• How to roll back a migration
• How to avoid downtime during migration

Need a hand with your move? Contact Cloud2Y support →