It usually starts the same way. A system that the business depends on every day was built years ago by a developer or agency who is no longer around. There was no handover. It still works, mostly, but it is getting slower, the hosting company is warning about the PHP version, and nobody wants to touch the code in case something breaks.
We have been picking up systems like this for 20 years, including our own. This article is what we have learned about rescuing a legacy PHP system: how to tell how much trouble it is in, how to decide between fixing, upgrading and rebuilding, and how to make the change without putting the business at risk.
Signs your system needs rescuing
Old code is not a problem in itself. Plenty of older systems are quietly doing their job. It becomes a problem when some of these start to appear:
- It is getting slower, especially as you add more data or more users.
- It runs on an unsupported version of PHP or of its framework, so it no longer gets security fixes, and your hosting provider is pushing you to upgrade.
- Nobody understands it. The knowledge left with the person who built it, and there is no documentation.
- Changes are frightening. Small requests take a long time, or fixing one thing breaks another.
- People work around it, with spreadsheets, re-keying and manual checks filling the gaps.
If two or three of those sound familiar, it is worth acting before something forces your hand.
First, stabilise
Before deciding anything big, get the system into a state where it can be worked on safely. That means making sure you have access to everything (code, server, database, domain), that there are working backups, and that the code is under version control. Then fix whatever is actively broken.
This stage also tells you what you actually have. Legacy systems often contain years of business rules that nobody wrote down: how prices are calculated, which customers see what, what happens at the end of the month. Those rules are usually the most valuable part of the system, and any plan has to keep them.
Fix, upgrade or rebuild?
Once you can see what you have, there are broadly three options.
Fix and maintain. If the code is basically sound, the most cost-effective answer is often to fix the problems, bring it up to date, and keep it running. Not every old system needs replacing.
Upgrade. If it runs on a framework or PHP version that can still be upgraded, moving it forward step by step can buy many more years of life without a rewrite.
Rebuild. Sometimes upgrading isn't practical. When we picked up the Royal College of Obstetricians and Gynaecologists' CPD platform, it was built on a version of Drupal that was near the end of its life, and the way the site logic used the database meant normal page loads triggered large numbers of database queries. Upgrading would not have fixed that. So we rebuilt the platform in custom code, while keeping the same underlying data.
The right answer depends on the code, the data and the business, which is why it is worth an independent review before committing to a large project.
Keep the data and the business logic
A rebuild does not have to mean starting again. With the RCOG platform, the principle was simple: preserve the important data and business logic, but rebuild the delivery layer so it is faster, more robust and easier to support. That meant importing and normalising the existing data and reorganising it where needed, so members' years of training records came across intact.
The result was significantly faster than the old platform. So much faster, in fact, that the client initially thought something might be wrong. It went on to support the College's members for many years, extending the life of a critical application by roughly ten years.
Keep the front end familiar
One decision on that project saved a surprising amount of work: we kept the front end of the site the same. Because members saw the same pages, there was no need to explain the change to them, no retraining, and none of the discussion a visible redesign would have caused. All of the improvement happened underneath.
It is tempting to redesign everything at once. But changing what users see and what runs underneath at the same time doubles the risk. Fix the foundations first, and improve the interface afterwards if it needs it.
Avoid the big-bang switch-over
The riskiest way to replace a system is to build the new one in parallel for months and then switch everything over in one weekend. Nothing can be checked against real use until the switch, and every problem appears at once, in production.
When we modernised our own helpdesk, which runs on an in-house PHP framework we had maintained since long before Laravel existed, we used a different approach, often called a strangler-fig migration:
- We set up Laravel alongside the old application, sharing the same database.
- We moved the permission rules first, so both systems enforced exactly the same access control.
- We converted the system one screen at a time. Both versions stayed live, so we could compare old and new side by side against real data, and roll back a single page without touching anything else.
- Once every screen had a new equivalent, we pointed all traffic at Laravel and retired the old code.
There was no downtime, no lost features and no cutover weekend, and the support team kept using the system every day while it happened. You can read the full helpdesk case study.
Make sure it doesn't happen again
Most legacy rescues have the same root cause: the knowledge of how the system works was lost when a supplier or developer left. RCOG came to us because their previous technical lead was no longer available, and the most valuable thing we could offer them after the rebuild was continuity. We stayed with the system for about a decade.
A few things help a system age well:
- Build on a standard, widely understood framework. That is one reason we use Laravel: any competent PHP developer can pick it up, so you are never tied to one person or one company.
- Keep it up to date little and often, rather than letting years of upgrades pile up.
- Write down the business rules as they are discovered.
- Work with people who will stay. Long relationships are worth more than any single project.
Need help with an old system?
If you are relying on a PHP system that nobody quite understands any more, we can help you work out whether to fix, upgrade or rebuild it, and then do the work without putting your business at risk. Find out more about our legacy system support, or get in touch.