MaintenanceMethodBusiness softwareBudget
Legacy PHP modernization: upgrade, refactor or rewrite your ageing PHP application
11 min read
To modernize a legacy PHP application, first get it back onto a supported PHP version, then choose between three paths: keep it as it is once upgraded, refactor it gradually into a modern framework, or rewrite it module by module. A big-bang rewrite is almost always the riskiest option. The right choice depends on how valuable the existing code is, whether tests exist and what changes are coming, not on how old the application is.
Most content on this topic is written for developers (which function changed between versions) or by agencies selling a rebuild. This guide is for the business owner who pays for the application, keeps hearing "we can't touch that anymore", and has to decide what to do.
Why so many PHP applications age badly
PHP runs a large share of the web: according to W3Techs (data as of 6 November 2026), it powers 69.1% of websites whose server-side language is known. Among those, 26.1% still run PHP 7 and 7.6% run PHP 5, two lines the PHP project no longer maintains.
Business applications written in PHP tend to share a history: built ten or fifteen years ago, sometimes by a single developer, with no framework or one that has since been abandoned, then extended year after year. They work, they carry the business, and nobody dares change them anymore.
The language itself is not the problem. PHP 8 is fast, typed and well tooled, and maintained frameworks around it are mature. What hurts is the distance between the code you have and the PHP ecosystem as it is today, and that distance grows every year nobody touches the application.
Warning signs
- Your PHP version is out of support. According to the official php.net schedule, only the 8.2 to 8.5 branches still receive security fixes in November 2026, and 8.2 stops receiving them after 31 December 2026. The end-of-life page dates the end of PHP 5.6 to 31 December 2018, PHP 7.4 to 28 November 2022 and PHP 8.1 to 31 December 2025.
- Your hosting provider announces it is dropping your version. This is often the real trigger, with a deadline you do not control.
- Libraries are frozen. Composer refuses to update them, or there is no Composer at all because third-party code was copied into the project by hand.
- Every fix breaks something else. There are no automated tests, and acceptance testing happens in production.
- Only one person understands the code, or nobody does.
These are the visible symptoms of technical debt, explained in plain terms in technical debt for business owners.
The four options
| Option | What you do | Best for | Main risk |
|---|---|---|---|
| Version upgrade | Move to a supported PHP version without changing the design | Decent code, security is the main concern | Functional debt stays untouched |
| Gradual refactoring | Restructure the code in small steps, often into a framework | Valuable business logic in messy code | A long project with no visible end |
| Module-by-module rewrite | Replace the application piece by piece while the old one runs | Architecture and screens need redoing | Managing the period of coexistence |
| Replacement | Move to an off-the-shelf product | The need has become standard | Losing what made you different |
Version upgrade
This is the first step in nearly every case, because it removes the most urgent risk. It is best done one version at a time, following the migration guides php.net publishes for each branch, with the help of tools: Rector automatically rewrites part of the code for a newer version, and PHPStan uses static analysis to flag errors the upgrade will trigger. These tools speed the work up; they do not replace tests or human review.
Gradual refactoring
The application stays in service while it is restructured in small steps: business logic pulled out of page scripts, database access isolated, a maintained framework (Symfony and Laravel are the most common) introduced for new features first, then for old ones. This path preserves years of proven business rules. It takes discipline: every step shipped and tested, and an end goal with a date.
Module-by-module rewrite
When the architecture and the screens need redoing, you replace the application piece by piece: a new module takes over one function, the old application keeps serving the rest, and you repeat until nothing of the old system is left. This is the strangler fig pattern, covered in our step-by-step legacy modernization guide. It avoids the single weekend when everything switches at once.
Replacement
If your need has become standard (simple invoicing, contact management, appointment booking), an off-the-shelf product may serve you better than a home-grown application you have to maintain. The reasoning is the same as in our build vs buy guide.
What an upgrade typically breaks
Without going into code, these are the areas that take real work when an old application moves to a newer PHP version. Your provider's estimate should mention them:
- functions removed from the language, notably the old MySQL extension, everywhere in code written in the 2000s, which has to be replaced throughout;
- a stricter language: errors that used to be silently ignored now stop execution, and old bugs often hide exactly there;
- libraries with no compatible version, which must be swapped for a maintained equivalent, sometimes with a change in behaviour;
- character encoding, when the application and the database never agreed on one and accented names start to break;
- the environment: web server, database engine and scheduled jobs often have to move at the same time.
An estimate that mentions none of these is probably underestimating the job.
How to choose: five questions
- Is the business logic correct? If calculations, rules and edge cases are reliable, they are worth a lot: lean towards upgrading or refactoring.
- Are there tests? Without them, every change is a gamble. Writing tests that pin down current behaviour is often the best first investment.
- Do the screens still work for people? If the application cannot be used on mobile, or new hires find it baffling, the interface at least needs rebuilding.
- What changes are coming? A client portal, an ERP connection, an API for partners: the longer the list, the sooner a modern architecture pays for itself.
- Who will maintain it afterwards? The chosen stack must be one the person or team in charge actually masters.
A software audit answers the first three questions in a few days, before you commit to anything.
What drives the cost
The price of modernizing a PHP application depends less on the language than on four factors: code size, lack of tests, the number of abandoned dependencies to replace, and the gap between the current and target versions. A PHP 5 application with no framework costs more to bring up to date than a PHP 7.4 application on a framework that is still maintained. For the cost items specific to a rebuild and how to read a quote, see our breakdown of software modernization cost.
The contract model matters too: a well-scoped upgrade suits a fixed price, while long refactoring work is better split into stages priced one at a time. Our comparison of fixed price vs time and materials goes into the trade-offs.
Common mistakes
- Starting from scratch in one go. A full rewrite built alongside the live system always misses rules that only the old code knew, and the business waits for months.
- Jumping several versions without a safety net. Going from PHP 5 to PHP 8 in one step, with no tests, multiplies silent errors.
- Modernizing the code but not the hosting. A server that is itself end-of-life cancels out the benefit; this is often the moment to migrate the application to the cloud.
- Forgetting the database. Encoding, engine version, hand-written queries: the database ages along with the code.
- Documenting nothing. Every rule rediscovered during modernization must be written down, or the debt builds up again.
Staying safe during the transition
While the application still runs on an unsupported version, reduce its exposure: restrict access to the users who need it, enforce stronger authentication, test your backups, keep login logs. None of this is a lasting fix, but it lowers the risk during the weeks or months of work. The basics are listed in our security essentials for business applications. If the application was abandoned by its developer, start by recovering the code and credentials, as described in our guide to rescuing a software project.
When not to modernize
Not every application deserves the effort. If the tool serves a handful of people internally, is not reachable from the internet, and will be replaced by an off-the-shelf product within the year, minimal hardening and an exit plan are enough. Likewise, an application nobody really uses anymore can simply be archived: data exported, server switched off.
Where to start
- Check the PHP version and the framework version, if any. Your host or developer can tell you in a minute.
- Recover the complete source code, the database and all credentials. Rights to that code depend on your original contract, and are defined case by case; check it, and see who owns custom software source code.
- Get an audit of the code, dependencies and tests.
- Deal with security first through a version upgrade.
- Then decide on the rest, and if the screens are going to change, see them before you pay: we build a free visual prototype of the future application, presented on a video call within 5 business days, as explained in see your software before you pay.