Columbia Games · WordPress / May 2026
Before an upgrade, test the backup instead of merely creating it
Ahead of major core and theme upgrades, the existence of a backup was not enough. Files and database had to be available together through a restore process we actually understood.
Situation
In legacy WordPress work, backup often becomes a binary checklist item: do we have one or not? But a backup can be incomplete, stale, corrupted or stored somewhere that is difficult to access during an incident. Before a major version change, rollback is real only when the restore path is known as well.
Approach
The upgrade plan treated the database, `wp-content` and environment-specific configuration separately. I checked backup size and contents, and the Dockerized local environment became a safe place to exercise restoration instead of merely describing it. That also gave us a more realistic estimate of recovery time.
Outcome
The larger June upgrades were backed by a tested recovery route rather than the vague comfort of 'a backup exists'. That made the upgrade both more confident and more controlled.