The Magento upgrade that took a B2B site offline for 4 days

The client called us on day two of the outage. They’d attempted a Magento 2.4.5 → 2.4.7 upgrade in-place on production, without a proper staging run, on the Friday before a major sale.

What we found

The upgrade had partially completed. The database schema was in a hybrid state — some tables updated for 2.4.7, some still on 2.4.5 structure. The cache was corrupted. Several third-party extensions were incompatible with the new version and throwing fatal errors on checkout.

The store was completely non-functional. 404 on every product page, 500 on checkout, admin panel partially accessible.

The recovery

Day one: we rolled back to the last full backup (18 hours old — they’d been running on autopilot backups, not pre-upgrade snapshots) and got the store back online on 2.4.5. Revenue loss was severe but stopped.

Day two: we audited every third-party extension for 2.4.7 compatibility. Three were blocking: a custom shipping calculator, a B2B quote module, and a legacy loyalty integration. Two had compatible versions from the vendor; one needed a custom patch.

Days three through seven: built a proper staging environment mirroring production, ran the upgrade in staging, identified and resolved every conflict, ran UAT with the client’s team.

Day eight: zero-downtime cutover using read-replica strategy — synced data to staging environment, pointed DNS, migrated remaining delta in a 12-minute window at 2am local time.

The aftermath

The upgrade was successful. We also set them up with automated pre-upgrade snapshot backups, a proper staging pipeline, and a policy that no production changes happen without a staging run first.

Total downtime including the original botched attempt: 4 days. Estimated revenue loss: ~$85k. Not recoverable, but the store is now running on a modern, maintained version of Magento with a sane deployment process.