A lot of businesses still run on PHP applications that are ten years old or more. They work. They make money. And every change takes longer than it should, because nobody quite trusts the code any more.
The obvious answer seems to be “let’s rewrite it”. We understand the appeal, but we rarely recommend it for an important system. Rewrites take longer than planned, the old system keeps changing while you build the new one, and the business waits a long time to see any benefit. Improving the app step by step usually gets you further, sooner, with far less risk. This is how we go about it.
Build a safety net first
Before we change anything big, we make it safe to change things at all:
- Get the code into version control if it isn’t already, and automate deployments
- Add error logging and monitoring so problems are visible
- Write tests around the flows that matter most, even if they start as rough end-to-end checks
- Make sure backups exist, and that restoring one actually works
None of this is exciting, but it lowers the risk of everything that follows.
Upgrade PHP and the framework
An outdated PHP version is a security risk and a performance drag, and it locks you out of modern libraries. Upgrading PHP, the framework and the key dependencies, one step at a time, is often the single most valuable thing you can do. Automated tools handle a lot of the mechanical changes, and the tests from the previous step catch anything that breaks.
Add structure gradually
Older PHP apps often mix database queries, business rules and HTML in the same file. You don’t have to untangle it all at once.
We usually bring in a modern framework like Symfony or Laravel alongside the existing code and route new features through it. Composer takes over dependency management. Business logic moves out of templates and into small services that can be tested. Duplicate code gets merged as we touch each area.
Every one of those changes is small enough to release on its own, and the app keeps running the whole time.
Replace pieces, not the whole thing
Sometimes one part really does need rebuilding: a checkout nobody dares touch, a reporting module that takes minutes to load, an admin panel from another era. When that happens, we replace just that piece. We put a clear boundary around it, build the new version behind that boundary, and switch traffic over once it’s ready.
Over time more of the system moves to the new structure and the old code shrinks. Developers call this the “strangler” pattern, because the new system slowly grows around the old one until the old one can be switched off.
Keep shipping
The biggest benefit is that the business never has to pause. New features keep going out, often faster than before, while the codebase quietly gets better underneath. You see progress every few weeks, not at the end of a year-long project that might slip.
A full rewrite is sometimes the right call. It should just be a deliberate decision made for a specific reason, and not the default reaction to old code.
