The code nobody understands still pays the bills. We take it over.
Ten-year-old PHP, a Laravel version long out of support, a custom build from an agency that has gone, or code an AI tool wrote that nobody can explain. We take it over, make it safe to change, and modernise it in steps while it keeps serving customers.
Who this is for, and who it is not.
A good fit if
- A PHP or Laravel application runs part of the business and has not been upgraded in years.
- It runs on PHP 8.1 or older, or on a Laravel release that no longer receives security fixes.
- The agency or developer who built it has gone, and there is no documentation or handover.
- Much of it was generated by an AI tool, and nobody on the team can say how it actually works.
Probably not the right call if
- The system no longer does anything useful for the business, so there is nothing worth carrying forward.
- You want a new product built from scratch, and the old system is only a reference.
- You need one bug fixed and nothing more; a takeover is a bigger job than that needs.
What changes for your team.
Changes stop being a gamble
Staging, tests around the paths that take money, and deployments that can be rolled back turn a change into a decision rather than a risk. The team starts asking for things again.
Off the versions that no longer get fixes
PHP, the framework and the dependencies move onto releases that still receive security patches. The system stops being the easiest way into the business.
Someone understands it again
How it is deployed, where the data lives, what breaks and why are written down in the repository. The system no longer depends on one person's memory.
The parts that make it hold up in production.
Version control, staging and backups
The code goes into your repository, a staging copy of production is set up, and backups are taken and restored once to prove they work. Nothing else changes until these exist.
Error tracking and monitoring
Errors, slow queries, failed jobs and downtime reach us before a customer reports them. We fix what production is already throwing before adding anything new.
Tests around the critical paths
Tests pin down what checkout, invoicing, logins and imports do today, including the odd behaviour people rely on. Every upgrade is then checked against those tests rather than against hope.
Stepped PHP and framework upgrades
PHP, Laravel and Composer dependencies move up one version at a time, with deprecations fixed and each step released on its own. Hosting moves to a supported server where it needs to.
Module-by-module replacement
The worst parts are strangled one at a time: new code takes over a route, a job or a report while the old code keeps serving the rest. A piece is only rewritten when there is a reason to.
Security hardening
Credential and key rotation, patched dependencies, locked-down server access, TLS and firewall rules. After a compromise we find how they got in, remove what they left and close the route.
Modernised in place, not beside it.
New code sits in front of and alongside the old application, taking over one route, job or table at a time. The existing system keeps serving customers throughout.
-
Where people use it L4Customer site Admin panel APIs Scheduled jobs
-
The safety net we add first L3Error tracking Uptime checks Tested backups Staging CI pipeline
-
What gets replaced, piece by piece L2Routing layer New modules Upgraded framework Background queues
-
What you already run L1Legacy PHP app MySQL database Existing server Third-party integrations
From first call to running in production.
Each step ends in something you can look at. Scope grows after something is live, not before.
-
01
The first two weeks
We secure access, move the code into your repository, set up backups, staging and error tracking, and rotate the credentials we find. Nothing customers can see changes until we can see what production is doing.
-
02
Map what nobody wrote down
With no documentation, we read the code, the database schema, the cron jobs and the server, and watch real traffic and logs. What we learn is written into the repository as we go.
-
03
Upgrade in releasable steps
Upgrades go out one step at a time behind the tests we wrote. Data migrations add the new structure first, backfill in the background, and remove the old only once nothing reads it.
-
04
Hand it back or run it
Once the system is on supported versions with tests and documentation, your own team can take it on from the repository. Or we keep operating it: updates, monitoring, backups, incidents and small changes.
Published prices, fixed before we start.
€1,000
delivered within a week
We read the system you already have and tell you what is actually wrong with it, what it would take to fix, and what it would cost.
€5,000 – €20,000
typical project
Fixed scope, fixed price, agreed before anyone writes code. Most of what we do sits in this band.
from €750
per month
We take the system over and keep it alive. This is the part most people discover they needed about six months after launch.
What moves the price for Legacy Modernization
- How far behind the PHP and framework versions are, and how many major upgrades sit between them and a supported release.
- Whether access to the code, server, database and domain can be handed over cleanly or has to be recovered first.
- How much business logic sits in untested, undocumented code around payments, invoicing or integrations.
- Whether the system has already been compromised and needs investigation and clean-up before anything else.
What we work with
Questions we get asked.
Usually not. A rewrite has to rediscover every rule the old system encodes, and it earns nothing until it is finished. It is the right call when the code cannot run on any supported PHP version without being rewritten anyway, when the data model blocks something the business needs, or when so little of the system is still used that replacing it costs less than understanding it. When that is the case we say so, and we still move across a piece at a time.
With access: the repository if there is one, the server, the database, the domain and DNS, and the third-party accounts. If the code only exists on the server, we take it from there and put it under version control on the first day. Then we read it, watch the logs and traffic, and write down what we find next to the code.
Yes, and that comes before any upgrade. We keep a copy for investigation, find how they got in, remove backdoors and injected code, rotate every password, key and token, and patch the route they used. Where cleaning in place is not trustworthy, we rebuild the server from known-good code and data. If personal data may have been exposed, we tell you early so you can meet your notification obligations.
It should not. Each step is tried on staging against a copy of production data, released on its own and able to be rolled back. Schema changes happen in stages: add the new structure, backfill it in the background, switch reads over, then remove the old structure once nothing uses it. Where a change genuinely needs a pause, we agree the window with you in advance.
You choose. Your own team or another developer can take it on, because the code is in your repository, the documentation lives next to it and every account is in your name. Or we keep running it on a rolling monthly agreement: updates, monitoring, tested backups, incident response and the small changes the business asks for.
