Taking over a legacy application
A representative scenario for a business-critical system whose original developer is no longer available.
Representative scenario
A representative scenario for a business-critical system whose original developer is no longer available. It is written from the pattern of work we do in this area rather than a single named engagement.
The shape of this project
How this project was approached
The seven stages this scenario moves through, from the problem as it was found to the position after implementation.
Challenge
The situation as it stood before any work began.
Requirements
What actually had to be true at the end.
Solution
The approach chosen, and why that one.
Technology
The stack, and the reasoning behind it.
Development
How the build was sequenced and verified.
Implementation
Rollout, migration and training.
Outcome
What changed — stated without invented figures.
Challenge
A system central to daily operations was running on an unsupported language version with dependencies years out of date. There was no documentation, no test coverage, no version control history worth the name, and deployment was a manual file copy. Nobody was willing to change it, so necessary improvements had stopped entirely.
Requirements
Get onto a supported runtime with known vulnerabilities closed. Make the system safe to modify again. Avoid a rewrite, which would have been both expensive and risky given how much undocumented behaviour the system contained.
Solution
A staged modernisation. First an audit establishing what was actually there. Then version control, reproducible environments and an automated deployment, so changes could be made safely at all. Then the runtime upgrade, then characterisation tests around the behaviour that had to be preserved, and only then structural improvement.
Technology
The existing PHP codebase kept and upgraded rather than replaced, with new modules written against Laravel conventions so the two could coexist during transition.
Development
Each phase was small enough to be reversible. Tests were written before refactoring, not after, so that changes could be verified against documented existing behaviour.
Implementation
Deployed incrementally with the ability to roll back at every step. No single cutover date.
Outcome
A system on a supported runtime with known vulnerabilities addressed, automated deployment, test coverage on critical paths, and written documentation — meaning the application can be changed again rather than frozen. No cost or timeline figures are published, as none has been supplied for verification.
Tell us what you are trying to build
Describe the problem in plain language and we will tell you what it would take to solve it — the approach, the moving parts and the sensible order to build them in. No obligation either way.