Columbia Games · WordPress / March 2026 12.
The first step with an old WordPress site: create a reproducible snapshot
The Columbia Games WordPress code moved into its own repository in March. The first goal was not upgrading it, but establishing exactly what we were changing and what counted as the baseline.
Situation
On a WordPress installation that has been running for years, the server often becomes the documentation: plugins, uploads, configuration and small fixes live there without a reliable history. If modernization starts with immediate upgrades, it becomes much harder to explain which change caused which behaviour.
Approach
I first organized the project into a version-controlled form. Files that belonged in the repository were separated from environment data, uploads and secrets. The initial commit was not meant to look elegant; it existed to create a reviewable baseline against which later Docker, core, theme and plugin changes could be measured.
Outcome
From that point, WordPress was no longer just a live server state but an engineerable system with history. The Docker environment, core upgrades and plugin maintenance that followed all built on the same baseline, so later diffs and their reasons stayed understandable.