The site ran on a PHP version that no longer gets security fixes, with plugins that break on anything newer. Upgrading blind risks the live site. Not upgrading is the slower risk.
A WordPress site on an end-of-life PHP version, upgraded only after the whole thing had been proven on a copy, and its pages rebuilt to show a track record.
A full local copy of the site ran on each candidate PHP version, with the front end and the admin exercised on all of them.
The aim was credibility with people deciding whether the business is real, so the evidence moved to the front.
Work happens on a copy, then moves to live through a staging step that matches the real server.
The problems that decided how this was built. They are the reason it works the way it does rather than the obvious way.
Several plugins had no upgrade path to current PHP, and a routine update would overwrite any patch applied.
Each fix was kept as a patch file with its reason, and the obsolete plugin was removed rather than propped up.
A short, documented list of what to re-check after any plugin update.
We don’t publish screenshots, logos or client names for this work. Much of it runs inside a business and handles sensitive data, so we describe what was built rather than who it was built for. We’re happy to walk through the detail on a call.
Every build on this page started as a workflow that off-the-shelf software nearly handled. Tell us where the gap is and we’ll scope what it takes to close it.