My first extra check would be the write cutover. For a site accepting comments, form submissions or orders, a successful restore rehearsal can still leave the destination behind the live database.
One approach is a short, planned write freeze, a final database/uploads sync, validation, then the traffic switch. Keep the old origin from accepting writes while DNS caches expire, so you don't end up with two diverging databases. Once writes resume on the new host, rollback also needs a plan to preserve that new data.
I'd lower DNS-only record TTL in advance; already-cached records retain their previous TTL (Cloudflare explains this here: https://developers.cloudflare.com/dns/faq/).
Do you include a write-freeze/final-sync step for interactive sites?
My first extra check would be the write cutover. For a site accepting comments, form submissions or orders, a successful restore rehearsal can still leave the destination behind the live database.
One approach is a short, planned write freeze, a final database/uploads sync, validation, then the traffic switch. Keep the old origin from accepting writes while DNS caches expire, so you don't end up with two diverging databases. Once writes resume on the new host, rollback also needs a plan to preserve that new data.
I'd lower DNS-only record TTL in advance; already-cached records retain their previous TTL (Cloudflare explains this here: https://developers.cloudflare.com/dns/faq/).
Do you include a write-freeze/final-sync step for interactive sites?