Legacy PHP modernizationwhile the app keeps running
For businesses running an old PHP app that nobody wants to touch: an unsupported version, no tests, and the original developer long gone. I’ve written PHP since 2013, back when a lot of today’s legacy code was new.
Plain PHP in 2013, CodeIgniter in 2015, Laravel today. I can read the era your app was written in.
How legacy PHP modernization works
Legacy PHP modernization means moving an old app to a supported PHP version and a structure your team can change safely. I start by adding tests around the parts that earn money, then upgrade in small steps: the PHP version, the dependencies, and, if it pays off, a gradual move to Laravel. The current app keeps serving users while each step ships.
Often the reason to upgrade is a new front end. Once the app is on current PHP, it can serve a clean API, as I describe in PHP API development for Next.js.
When to upgrade an old PHP app
Time to upgrade
- The app runs on a PHP version that no longer gets security fixes
- Your host wants you to upgrade PHP and the app breaks when you try
- Every small change breaks something else, and there are no tests
- You want an API or a Next.js front end, and the old code is in the way
Probably leave it alone
- The app is small, stable, patched, and nobody needs to change it
- You need a full rewrite by a fixed date with no room to test
What you get
A supported PHP version
Security fixes from PHP itself again, and no surprise breakage when your host drops the old version.
Tests around what earns money
Checkout, login, or whatever matters most gets tests first, so later changes stop breaking it quietly.
A gradual PHP to Laravel migration
Routes move to Laravel one at a time next to the old code, so there is never a big-bang rewrite.
Code your team can change
Composer for dependencies, a clear folder structure, and notes, so the next developer can work without fear.
Tools I use for PHP upgrades
How the upgrade runs
Audit
Read the code and list the PHP version, dependencies, and risky parts.
Safety net
Add tests and error logging around the flows that matter most.
Upgrade in steps
Move the PHP version and libraries in small releases you can roll back.
Refactor or migrate
Where it pays off, move parts to Laravel one route at a time.
Legacy PHP modernization FAQ
How much does legacy PHP modernization cost?+
It depends on how big and how old the codebase is, so I read it before quoting. You get a plan that splits the work into steps, each with its own quote, so you can stop after any step and still have a working app.
Should we modernize the old PHP app or rewrite it from scratch?+
Usually modernize. The old code holds years of business rules that a rewrite has to rediscover, often through bugs in production. A rewrite makes sense when the app is small or truly cannot be upgraded, and I will tell you if yours is one of those.
Will the app go down during the upgrade?+
Each step is tested on a staging copy and released as a deploy you can roll back, so users keep working. If a database change needs a short maintenance window, it is in the plan and we pick the time together.
Do we have to move to Laravel?+
No. Many apps only need a supported PHP version, Composer, and tests. A PHP to Laravel migration makes sense when you plan a lot of new features. If you do move, it happens route by route next to the old code.
Who maintains the app after the upgrade?+
You own the code. After the upgrade it has tests, a documented setup, and a supported PHP version, so your team or any PHP developer can take over. I can stay on for further steps if you want.
Scared to touch your old PHP app?
Send me the repo or tell me what it runs on. I’ll list the biggest risks and what I’d upgrade first, before you commit to anything.