How a migration is verified.

Three checks decide whether a move is finished: a page-by-page visual comparison at three screen widths, a DNS and mail capture read from live DNS, and a restore drill that rebuilds the site from the backup alone.

Every number on this page came from a run on a real site, on the date stated. None of it is an estimate.

1. The pixel gate

Each page is loaded on the old site and the new one at 375, 768 and 1440 pixels wide, screenshotted, and compared pixel by pixel. Anything above a few per cent means something moved and gets fixed.

The point of comparing against the original rather than against a design is that the original is what the owner already approved. A rebuild from a screenshot can only ever approximate an animation-heavy page. Using the published build as the source makes the comparison a check on the copy, not on someone's memory of it.

On a second site, the clinic, the same gate ran across five pages. Four came in at or under 0.11% on every width; the home page — the one with the film and the 3D — came in at 2.54%, 2.21% and 1.37%, inside the 5% threshold. Page heights matched exactly, 9641 pixels against 9641, which is the check that says nothing shifted. Hover and scroll-reveal behaviours were compared separately: 53 interactions across five pages, zero mismatches.

2. The restore drill

A backup that has never been restored is a guess. So the archive alone is cloned into an empty folder, deployed to a disposable address, and pixel-compared against the live site.

Run on nbdigitaldentistry.com on 5 August 2026, from the archive on its own, as if on a brand-new machine. A site rebuilt from that archive is the live site. Alongside it, a per-file checksum manifest covers all 217 files, so a corrupted copy is detectable rather than discovered at the worst moment.

Every project gets the same three-place arrangement: a git repository on the machine, an offline archive, and a copy in private cloud storage. An archive sitting in a Documents folder is not a backup — it is the same disk.

3. The DNS and mail capture

Records are read from live DNS with dig, every type, before anything is touched. Registrar dashboards paginate and hide records, and the hidden ones are usually the email ones.

On one migration the registrar showed the obvious records on the first page of its DNS list and put SPF, DKIM and DMARC on the second. Copying what was visible would have left the domain unable to authenticate its own mail — which does not look like an outage, it looks like the business's email quietly landing in spam.

The second trap is proxying. Cloudflare's proxy carries HTTP and HTTPS only. On the clinic migration Cloudflare's automatic import set mail, smtp, imap and pop to proxied, which would have stopped every mail client connecting. Web records proxied, everything else DNS only — checked by hand, record by record, every time.

4. What gets measured after the switch

Weight, first paint, console errors, broken images, horizontal overflow on a phone, and whether every heavy asset is fetched once instead of three times. Measured on the live domain, not on a laptop.

Most of the weight saving is re-encoding, not deletion. On the clinic site one hero film went from 11.3 MB to 3.4 MB and three photographs went from 2.2 MB, 2.0 MB and 0.7 MB to 100 KB, 123 KB and 127 KB, each checked frame by frame or side by side first. About 10.2 MB came off a single page without anyone seeing a different pixel.

Two defects worth knowing about

Both were found by the gate rather than by a client, which is the entire argument for having a gate. Both are now fixed in the tooling, so they cannot happen on your site.

A third finding was investigated and thrown out: a scan reported six broken images on one page. All six returned correctly, and running the same scan against the original site flagged the same six. It was a fault in the harness, present on both sides. Recording that it was wrong matters as much as recording the ones that were right.