Systems we take on
- Running PHP 8.1 or older, or still on PHP 5 or 7
- The company or person who built it is gone, and so is the spec
- No tests, so nobody knows what breaks when something changes
- Built on EC-CUBE, WordPress, CakePHP, an old Laravel, or a home-grown framework
- Every vulnerability headline costs a day just to find out whether it applies to you
As php2shell showed in October 2026, old PHP versions sometimes get no fixed release at all. PHP 8.2 also leaves support on 31 December 2026.
How we run it
We never rebuild everything at once. The system keeps running, and we move one step at a time, checking each step.
1. Inventory, and what cannot wait
We list the PHP, framework and library versions production really runs, the server setup and every outside connection. Then we match them against published vulnerabilities and apply the fixes or settings that are needed now.
You get: the inventory, the risks ranked by urgency, and a record of what we changed.
2. Build a safety net
Before changing anything, we record how the system behaves today. The main screens and flows (sign-in, orders, payments, admin updates) become automated tests. We rehearse the backup and the rollback for real, and set up a staging copy that matches production.
You get: the behaviour tests, a rollback procedure we have actually run, and the staging environment.
3. Move to supported versions
We take PHP to 8.3 or 8.4, with the framework and libraries alongside. Each move is one step. After each one the tests run and we compare the screens on staging before anything reaches production.
You get: a record of each step and how to undo it.
4. Move only what needs a new stack
If the upgrade is enough, we stop there. Where a part has hit its limits, for example screens that break whenever a feature is added, we move just that part to a newer stack (say, Next.js screens over an API). Old and new run side by side, and traffic moves one feature, and one group of users, at a time.
You get: the new code, its runbook, and the record of each switch.
Afterwards: keep watch
To catch what an upgrade breaks before most users do, we collect errors and the bugs users report. For that we use our own open-source tool, Mushi Mushi.
What we will not do
- Propose rebuilding everything at once
- Change production before today's behaviour is recorded
- Recommend a migration you do not need
- Promise that a system is "completely secure"
- Handle attack steps or proof-of-concept exploit code
Ways to work together
- Inventory only: an agreed scope, ending with the inventory and the ranked risks.
- Urgent fixes: apply the fixed release or the stopgaps, and check for signs of intrusion.
- Staged upgrade and migration: steps 2 to 4 above, split into stages.
We quote each stage after the first inventory.
About kensaurus
kensaurus LLC is a small software company in Shibuya, Tokyo. We build and run more than ten services and apps of our own, with bookings and payments, accounting and AI features among them (see them in the exhibit hall). We use AI coding agents too. On upgrade work, every change is checked against the tests and a side-by-side comparison before it reaches production.
Write to us using the link below. If you know which PHP version you run, please include it.