8 Signs Your Legacy PHP System Needs Modernization

Your legacy PHP system needs modernizing when keeping it as it is costs more, in delays, risk and manual workarounds, than fixing it. Most legacy PHP modernization projects start with business symptoms rather than code: nobody wants to touch the system, small changes take weeks, and the server runs a PHP version that no longer gets security patches. The good news is that it rarely means throwing everything away.

Full disclosure: I'm a freelance Laravel developer based in Denmark, and modernization work is part of how I make a living. That's exactly why this post also covers when to leave an old system alone.

The short answer

Start with this rule of thumb: if your system runs PHP 8.1 or older, or still stores passwords and builds database queries the way it did a decade ago, plan the work now. Otherwise, count how many of the signs below you recognize. One sign is normal for any system that has been around for a while. Three or more means someone should look under the hood before the problem picks the timing for you.

If you're not sure what ongoing upkeep should look like in the first place, my complete guide to web application maintenance covers the basics.

Signs you'll notice in the business

You don't need to read a line of PHP to spot the first four. They show up in planning meetings, in estimates and in how your team talks about the system.

1. Everyone avoids touching it

Listen for phrases like "let's not risk it" or "it works, so leave it". When your team leaves a known bug in place because the fix might break something else, the system has become fragile. The usual cause is years of growth without automated tests, so nobody can see what a change will affect.

That fear has a cost. Improvements wait, staff invent workarounds, and when a change finally becomes unavoidable, it happens in a hurry. A useful question: when did the system last get an improvement that wasn't forced by a bug?

2. Small changes take weeks, not hours

Adding a field to a form, a column to an export or a new discount rule should take a few hours. When simple requests keep turning into multi-week estimates, the logic is usually scattered across the codebase. The same rule might be copied into ten places, and all ten have to be found and tested.

This is technical debt in its most visible form: shortcuts that were quick at the time and now charge interest on every change. The developer usually isn't the slow part. The code is.

3. One person holds all the knowledge

A lot of legacy PHP systems were built by a single developer who kept the whole thing in their head. That works until they change jobs, retire or simply take a long summer holiday.

Ask yourself: if your developer left tomorrow, how long would it take someone new to make a safe change? If the honest answer is months, or you don't know, that dependency is a business risk on its own. An independent code review is a relatively cheap way to find out where you stand.

4. You work around the system instead of with it

Your customers expect to pay with a local payment method such as iDEAL or Vipps MobilePay, sign in with their Microsoft or Google account, or see their data in an app. Your accounting software has an API, and sales want data in the CRM. When the answer from your system is no, or "possible, but expensive", the gap gets filled with CSV exports, manual data entry and double work.

That manual work rarely appears in a budget, but you pay for it every month. A modern foundation with a proper API turns integrations like these into routine tasks instead of special projects.

Signs in the code and on the server

The next four need someone to look at the code or the server. You don't have to do that yourself, but whoever maintains the system should be able to answer them without much digging.

5. You're running an unsupported PHP version

Each PHP release gets two years of active support followed by two years of security fixes only. According to the official list of supported PHP versions, PHP 8.1 and everything older is end of life, and PHP 8.2 gets its last security fixes on December 31, 2026. If you're still on PHP 7.4, you haven't had a security update since November 2022.

That doesn't mean you'll be breached tomorrow. It means newly discovered vulnerabilities won't be fixed for your version, modern packages drop support for it, and fewer hosting providers are willing to run it. If your host has started sending end-of-life notices, take them seriously, and if you're on PHP 8.2, plan the upgrade now rather than in January. Already on Laravel? Check which Laravel versions still get security fixes as well, because the framework runs on its own clock.

6. It's built on a homegrown or abandoned framework

Plenty of systems from the 2000s and early 2010s run on a homegrown framework or an old major version of one that nobody maintains anymore. Third-party libraries are often copied straight into the project instead of being managed with Composer, the standard PHP tool for handling packages and versions.

Age isn't the problem. The problem is that you own all of it, including the parts the rest of the world solved years ago: authentication, form validation, email, queues and permissions. And every new developer starts from zero, because there's no documentation, no courses and no community to ask.

7. Deployments are a gamble

If updates go live by uploading files over FTP straight to the production server, with no staging environment and no automated tests, every release is a roll of the dice. Customers find the bugs, and there's no simple way back to the previous version.

Often the code isn't in a Git repository either, or the version in the repository isn't the one actually running. This is the cheapest part of a modernization to fix and the one that buys the most peace of mind right away, which is why it comes early in the steps below.

8. Security still runs on habits from another era

Old PHP code reflects the era it was written in. Common findings include passwords hashed with md5 or sha1 instead of a modern algorithm, SQL queries built by pasting user input straight into the query string (an open door for SQL injection), and forms without protection against cross-site request forgery.

For a European business handling personal data, this is also a compliance issue. Article 32 of the GDPR requires security measures appropriate to the risk, taking the state of the art into account, and known, unfixed weaknesses in a system full of customer data are hard to defend. If you supply software or services to organizations covered by NIS2, expect more questions about how you patch and maintain your systems; I've covered what NIS2 means for software suppliers separately. None of this is legal advice, but it's a strong argument when you need budget approved.

Upgrade, modernize or rewrite?

When a system is old enough, starting over is tempting. It's rarely the best option. Full rewrites take longer than anyone plans for, the business still needs new features in the meantime, and the old system contains years of rules and edge cases nobody wrote down. Martin Fowler calls the alternative the strangler fig pattern: build the new system alongside the old one and move features across one at a time until nothing of the old one is left.

Why Laravel is usually the destination

I usually recommend Laravel because it's still PHP. Your server, your database and much of your business logic carry over, and nobody has to learn a new language. You also get authentication, queues, email, testing tools and permissions out of the box, plus a new major version every year with a published two-year window for security fixes. I've written more about why Laravel is my default choice for web apps.

A step-by-step path to Laravel

This is roughly how I approach a gradual modernization. The order matters more than the speed, because each step makes the next one safe.

Make change safe first

1. Map what you have. List the PHP version, packages, database, integrations and scheduled jobs (cron), and find out which parts people actually use. You'll often find features nobody needs anymore, and those don't have to be migrated.
2. Put a safety net in place. Move the code into Git, set up automated backups and a staging environment, and replace FTP uploads with a deployment process you can roll back.
3. Pin down current behavior with tests. Before changing anything, I write tests that describe what the system does today in its most important flows, such as login, orders and invoicing. The goal isn't to approve the old logic, but to notice if it changes by accident.
4. Upgrade PHP. Get to a version that still receives security fixes. Rector can automate many of the mechanical changes, but the result still needs review and testing. Note that Laravel 13 requires PHP 8.3 or newer.

Move across piece by piece

5. Put Laravel in front. A new Laravel app receives every request and passes anything it doesn't handle yet to the old code. Both can share the same database. The hardest part is usually sharing logins, so users don't notice the switch.
6. Migrate one feature at a time. Start where you need changes anyway or where bugs cluster, and build all new features in Laravel only. That way the modernization pays off as you go, not only at the end.
7. Switch off the old code and keep the new one current. Once the last piece has moved, delete the legacy code. Then make sure you don't end up here again by keeping the framework and dependencies up to date.

When to leave your legacy system alone

Not every old system needs modernizing, and I'd rather tell you that than sell you a project you don't need. Waiting can be the right call when:

• The system is internal only, sits behind a login or VPN, holds no sensitive data and rarely changes.
• It's being retired within a year or so anyway, for example because you're moving to an off-the-shelf product.
• What it does can be bought. Booking tools, simple CRMs and online stores are often cheaper to buy than to modernize.
• Nobody on your side has time to answer questions. A modernization needs someone who can explain what the system should do and why it behaves the way it does.

Even then, cover the basics: backups, code in Git and a supported PHP version if at all possible. And if your system isn't written in PHP, or you need a full team for several years, a solo freelancer like me probably isn't the right fit.

Next steps

You don't need a plan before talking to a developer, but you'll get a far better answer if you have these ready:

With that in hand, a developer can tell you whether to upgrade in place, migrate gradually or leave things be for now. For larger projects I start with a paid, fixed-price discovery phase, so you know the plan and the price before committing to more, and you own the code from day one. I'm based in Denmark (CET), so my working day overlaps with business hours across the UK and the rest of Europe. You can see how I work on my Laravel development and modernization page.

Frequently asked questions

How much does legacy PHP modernization cost?+

It depends mostly on the size of the system, the number of integrations and how much of the logic is documented or covered by tests. Upgrading the PHP version of a small internal tool is a very different job from gradually migrating a large customer platform. That's why a serious developer rarely quotes a fixed price without seeing the code. A short, paid discovery phase is the cheapest route to a reliable number.

Can we keep using the system while it's being modernized?+

Yes, and that's the whole point of a gradual approach. Your team keeps working in the same system while features move across one by one behind the scenes. There may be short, planned cutovers, for example when logins move, but those can usually happen outside business hours. A full rewrite, by contrast, depends on one big switchover, and that's where most of the risk sits.

Should we move to Laravel or stay on plain PHP?+

Staying on plain PHP is fine if the system is small, stable and rarely changes. Upgrading the PHP version and tidying up is often enough. If you'll keep developing it for years, I recommend a framework, because you stop maintaining authentication, security and infrastructure code yourself. Laravel is my choice, but Symfony is also a solid, well-maintained foundation.

Is PHP still a good choice in 2026?+

Yes. PHP ships a new version every year, most recently PHP 8.5 in November 2025, and each version gets four years of support in total. Modern PHP has a proper type system, good performance and a large package ecosystem. The problem with legacy systems is rarely the language itself, but that the version and the code stopped moving. Modernizing usually means catching up with current PHP, not leaving it.

What if the original developer is no longer around?+

Secure access first. Hosting, domain, database, code repository and any third-party accounts should be registered to your company, not to a former contractor. Then have a new developer audit the code and the server. That audit gives you a basis for deciding whether to upgrade, migrate or replace the system, and it shows you where the biggest risks are.