Proving a move is finished before you tell the client

A move is finished when you can demonstrate it, not when you have worked through the tasks. Those are different states, and clients get burned by the gap between them. Before you send the "we are live" message, convert every claim into a single observation that would fail loudly if the claim were false, then make that observation from somewhere that is not your own desk.

Turn each claim into one falsifiable observation

Your own machine is the worst instrument you own

Everything on your path remembers the old answer: the browser profile you built the site in, the operating system resolver, the office router, sometimes your provider's recursive resolver. A green result on that path proves something answered, not that the new server answered.

1. Pin the request instead of trusting name resolution. Fetching with the hostname mapped explicitly to the new address removes DNS from the experiment entirely, and repeating it against the old address tells you what visitors still stuck on the old record are seeing.
2. Repeat from a network you do not administer. A phone with wifi switched off is the cheapest independent vantage point that exists.
3. Write a marker file with a random string on the new server only, and check for its exact contents. Version numbers, footers and page titles are identical on both copies, which is precisely why they cannot tell them apart.
4. Read response headers, not rendered pages. Age, caching directives and proxy identifiers reveal whether an intermediary answered you; the semantics are documented on MDN.

Inventory, not spot checks

Clicking around the new site proves the pages you remember exist. The pages that break are the ones you forgot. Build the inventory from access logs covering at least ninety days, then union it with the old sitemap and a crawl of the old copy. These sources disagree, and the disagreement is the point: if logs give you 4,100 distinct paths and the sitemap lists 3,780, the 320 orphans are where the losses concentrate.

Replay the whole list against the new host and keep the status and final location for each path as a file. That file is your evidence. An empty diff, or one where every entry maps to a redirect you deliberately wrote, is the finished state.

The two failure modes that hide behind a successful move

Both come from the old server continuing to work. First, split mail delivery: the MX record points to the new host, but the old machine still believes it is authoritative for the domain, so anything sent from an account still hosted there is delivered locally and never arrives. Proof is a rejection from the old box, not a delivery to the new one.

Second, doubled scheduled jobs. If the old crontab is merely ignored rather than disabled, invoices, reminders and imports run twice for as long as that machine stays powered on. Verify by making a job write its own timestamped line, then confirming exactly one line appears per interval.

Backups deserve the same suspicion. A job reporting success proves the job ran. Restore one file and one database table into a scratch directory instead; that is the only observation that proves the archive contains what you think it does. The rest of the sequence sits in moving in, and anything that fails these checks belongs in diagnostics before the client hears from you.