A migration can pass its first test and still be broken.
The classic version is a healthy homepage with missing CSS, JavaScript, fonts, or images. The page returns 200, the certificate is valid, and the first screen looks close enough. Then a closer look shows requests for static files failing underneath it.
Why the homepage is not enough
Static assets often live on a different path, storage volume, or deployment step than the application itself. A backend cutover can move the application successfully while leaving those files behind. Nothing in the homepage response guarantees that every referenced asset followed it.
We have seen this become a particularly misleading failure: the site looked available, but dozens of static files returned 404. That is exactly the kind of regression that slips past a smoke test because the smoke test checks the document, not the document's dependencies.
The check we run now
- Start with the canonical hostname. Verify TLS normally and follow redirects.
- Capture the asset URLs. Identify the CSS, JavaScript, font, image, and other requests the page needs.
- Request each asset over HTTPS. Check status, content type, and that it is the expected file.
- Repeat after the cutover. Compare the dependency set before and after the backend change.
- Check the edge. With Cloudflare, confirm cache behavior while validating the origin.
What makes this useful
This check is small enough to run before every migration and specific enough to catch a failure that broad monitoring misses. It gives the team a concrete diff: which URL failed and whether the problem is in the app, deployed files, hostname, or edge cache.
A backend cutover is complete when the page and the resources it depends on are reachable from the public hostname.