When WordPress 7.0 went live at 17:00 UTC on 20 May, we already knew what the upgrade would look like on this platform. We'd run every beta and every release candidate through to RC5 on two of our own production-mirror sites: staging.test365i.co.uk and www.test365i.co.uk, in the 24 hours before launch. PHP 8.5.6. Elementor 4. JetEngine. Smart Filters. StackCache. The AI Client and three provider plugins. Every combination clean.
So when launch hit, I made a call most managed-WordPress hosts wouldn't make. No platform-level hold. No staged rollout. No "we'll let you upgrade in two weeks" email. WordPress core's own auto-update mechanism handled the cohort.
Several hundred sites on our platform moved from 6.9.x to 7.0 in the hours after release. We watched the helpdesk. Watched the cache logs. Watched for the DataViews compatibility regression we'd flagged in our launch-day report.
By the morning of 25 May, five days after release, zero support tickets related to the upgrade, zero rollbacks, zero white-screen-of-death reports. The platform was already tuned for it because we'd tested it before it shipped.
This wasn't the call for every site. WooCommerce stores with a dozen-plus extensions still get staged first. Extension compatibility lags core releases by weeks, and that's the edge case worth holding for.
The reason customers pay for managed hosting is so they don't have to think about WordPress 7. Several hundred of them didn't.