UpgradeLegacy PHP / Laravel
What this package is
This package is for systems still running versions that are past end of life, which is a more dangerous position than most people realise. Once nobody is issuing patches, every vulnerability published after that date stays with you permanently with no way to close it, and those publications are public reading for anyone.
I upgrade one step at a time rather than jumping several versions and hoping. Each step carries tests proving the system still behaves as it did. Along the way the security holes get closed, deployment moves to an automated process so nothing is uploaded by hand again, and the test suite is widened to cover the important parts of the system rather than only what was changed.
The work ends with a session teaching your team the new process, recorded so they can watch it again. Anything nobody on the team can operate eventually reverts to how it was done before.
See it working
| From | PHP 7.2 · Laravel 6 |
|---|---|
| To | PHP 8.3 · Laravel 12 |
| Switchover | Sunday night · under 25 minutes of downtime |
| Method | One step at a time |
01 Step-by-step upgrade plan
Crossing several versions at once means that if something breaks, you do not know which step caused it and have to unpick all of them. This plan is four steps. Each one carries tests confirming the system still behaves the same before moving on, and each one can be rolled back.
02 The steps, and what each one closes
- Step 1PHP 7.2 → 7.4
Closes 3 high-severity issues carried by the old version · tests 34/34 - Step 2Laravel 6 → 9
Replaces 2 abandoned libraries · tests 34/34 - Step 3PHP 7.4 → 8.3
Closes 5 medium-severity issues · tests 41/41 - Step 4Laravel 9 → 12
Deployment moved to an automated process · tests 41/41
03 Watched closely
| Tax invoice plugin | Unmaintained for 3 years, replaced at step 2 |
| Reports written in raw SQL | Bypasses the framework, manually tested at every step |
The full plan carries the date of each step, the rollback procedure, and every issue closed.
This is an abridged sample. The figures and the system name are invented, but the format, the headings and the way it is written are exactly what a real client receives.
Everything you get
This list is the entire scope of the package. Nothing is hidden in a contract.
- Everything in Fix
- PHP and Laravel moved onto versions that still get security support
- Security holes closed, with a written explanation of each one
- Automated deploys, so nobody uploads files by hand again
- Test coverage across the important paths, not only what I changed
- One training session for your team, recorded so they can rewatch it
- Rewriting the whole system in a different stack. If the check says a rewrite is genuinely the right call, I will say so and quote it as new build work rather than folding it into maintenance.
- WordPress plugin and theme work. That is a different discipline from Laravel and I do not take it on right now.
- Recovering a system that has already been compromised. That has to be scoped case by case, because the blast radius differs enormously.
- Server and third-party service costs. Those go straight to the provider and I tell you the numbers before you commit.
Questions about this package
Does the system look different afterwards?
No. This changes what sits underneath. Daily users should notice nothing except that it is faster. If you also want the interface changed, that is separate work and I price it separately rather than folding it in quietly.
Why step through versions instead of jumping to the latest?
You can jump, but the risk is different. Crossing several versions at once means that if something breaks you do not know which step caused it and have to unpick all of them. Stepping with tests tells you immediately. It costs a little more time in exchange for not having to guess.
Is automated deployment really necessary?
It is, once you want somebody else to be able to maintain this. While releases are files uploaded by hand, only the person who knows the sequence can do it, and the day they are away is the day the system cannot be updated. Automated, anyone can run it, and it can be rolled back when something is wrong.
Is there anything confirming the holes were closed?
A report covering each one: what was found, how it was closed, and what risk remains along with what I would do about it. It is the same document I give clients of my security audit service, which is my main line of work. There is a full sample of one on this site.
Can we keep using the system during the 30 days?
Yes, as normal. I work on a separate copy with its own test environment. Your live system keeps running until the switchover, which we schedule in advance and keep as short as it can be.