The Challenges of Maintaining Legacy PHP Applications
Assess runtime support, hidden dependencies and recovery risks before changing an established PHP business application.
Inventory the system before upgrading it
Before we recommend an upgrade, we need to understand what the application keeps running. List the PHP runtime, framework, extensions, background jobs and external services, then check their current official support documentation. Include scheduled exports and command-line scripts alongside the public website. A working login page tells you little about whether the overnight export still completes.
For each part, note what business task depends on it and how you would notice a failure. An export that feeds another team’s daily work deserves a place in the upgrade plan even if customers never see it. Keep unanswered questions visible: an integration with an unclear purpose needs investigation before anyone removes or replaces it.
Capture behaviour that matters to operations
Ask the people who use the application to demonstrate a complete workflow, including corrections and exceptions. We want to see what they do when a payment arrives with the wrong reference or an approval needs to be changed. Those steps can reveal essential rules that the documentation misses.
For example, use a synthetic payment and two synthetic invoices to walk through a payment allocation, then correct the allocation. Write down which invoice should show the payment after the correction and what the user expects to see when they reopen the record. That gives the team a concrete behaviour to protect with regression coverage before replacing a component. It also gives operational staff something recognisable to check after the change.
Keep that representative synthetic dataset with the checks. The team can repeat the investigation without copying live personal information into a development environment. Start with the workflows whose failure would interrupt daily work, rather than trying to document every screen before making progress.
Plan deployment and rollback together
Decide how to recover before scheduling the release. Rolling back the code may not reverse a database schema change or a message already sent. Rehearse recovery, separate backward-compatible changes where possible, and agree how writes will be handled during cutover.
Use the same workflow from your regression checks to make the recovery discussion specific. If staff correct a payment allocation after deployment and the release then needs to be reversed, what happens to that correction? Agree how the team will identify and handle those intervening changes. A successful rollback needs to account for the work people have done as well as the code being restored.
The first release can address a smaller risk without replacing the whole application. Put unresolved dependencies in the maintenance plan, with the business tasks they affect, so the next decision starts from what is still unknown.
Apply this to your brief
Bring a walkthrough of the current workflow, a representative synthetic example and the decision you need to make: whether to maintain the application, upgrade a component or investigate replacement. Include any known runtime or dependency details and the background tasks your staff rely on. We can use those specifics to identify what needs checking before a change is scoped.
Explore Willan’s consulting approach, review development services or discuss your project.
Planning guidance from Webvelopment Editorial. Confirm platform requirements and project assumptions before committing budget.
Keep the right things connected.
Technology and Digital Strategy Consulting
Work through technology decisions with Willan Theunissen: discovery, architecture reviews, marketing technology and digital capability planning.
Bespoke Development
Plan business software around the work people need to do: choose an application, eCommerce change, PHP update or integration, with a clear first release.
Digital Project Discovery & Technical Scoping Estimator
Offer paid discovery when requirements are too uncertain for fixed build pricing.
Start a conversation
Tell us what you are working towards. We’ll help you find a practical next step.