Software rescue and modernization, one tested slice at a time.
Before anyone touches a half-built or ageing system, it goes under test, so today's behaviour is pinned down. Then we finish, refactor or replace it, and you get the reasoning in writing.
Rescue a system when it does the right job and its data is sound, however poor the code, and fix it in place behind tests. Rebuild only when the job has changed or the platform is past support, and then in slices beside the old system. We read the code before quoting.
The code decides between rescue, refactor and rebuild.
Each route in the table follows from something the assessment finds in the code or the data. A rewrite is tempting and often the wrong call. Joel Spolsky called rewriting from scratch the single worst strategic mistake a software company can make, because old code carries years of fixed bugs that nobody wrote down.
Martin Fowler's strangler fig pattern offers another way. New parts grow around the old system and take over its behaviour one slice at a time, so risk and value both arrive in small pieces.
| What we find | What it usually points to |
|---|---|
| The system does the right job and the data is sound, but the code is untidy | Rescue: tests around what it does today, then fix and finish it in place |
| The job is right, but one part (billing, reporting, an integration) blocks every change | Refactor: replace that part behind a stable interface while the rest keeps running |
| A standard package now does the job, accounting on ERPNext for example | Replace with the package, and migrate the data reconciled against the source |
| The platform is past its support dates, or the job itself has changed | Rebuild in slices beside the old system, never in one switch-over |
| Nobody can say what the system is for | Stop: retire it, or write down what it must do before anyone codes |
AWS lists the same choices for cloud migration as the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform and refactor. We use plain words for the same decision.
Six checks come before any recommendation.
- Access. Who holds the source code, the hosting account, the domain, the database and every third-party credential. On a rescue this can be the hardest part.
- Behaviour. What the system does today, written down as tests before anything changes. A test that pins current behaviour is how a refactor proves it broke nothing.
- Data. Whether the records are complete and consistent enough to keep, or need cleaning and reconciling first, as covered under data readiness and migration.
- Platform. Language, framework and database versions, and which of them are past their support dates.
- Security. Access control on every route, secrets left in the code, and dependencies with known flaws. Broken access control heads the OWASP Top 10 for 2025.
- Running cost. Hosting, licences, and the hours spent keeping it alive.
The result comes in writing: the route, the reasons, the risks and a fixed price for the first stage.
The system stays up while it changes.
The old system keeps serving until each new part has proved itself beside it. Every change passes our release gate: the full test suite first, then the new version running next to the current one, and a bad release reversed.
Data moves in rehearsed migrations and is reconciled against the source before anyone relies on it, the books included when accounting moves to ERPNext. A rebuilt part is scoped like any custom web application. Once the work is done, the system can stay with us under managed hosting and support.
A takeover starts with control of the system.
A system left by its first builder can arrive with gaps: no documentation, credentials on a former contractor's laptop, a server nobody has signed in to for a year.
Three steps come before any code changes:
- Every credential rotated and moved into a vault, and access listed and reduced.
- A backup taken and restored, and the restored copy opened, to prove it works.
- The running version matched to the source you hold, so every change is made to the code that runs.
If the source code is not in your hands, recovering it comes before all three.
We work on mainstream web stacks.
Two kinds of work sit outside this service.
- Mainframe, COBOL and AS/400 systems. If yours needs that kind of specialist, you will hear it on the first call.
- Cloud migration as a hyperscaler partner. Systems run on our hosting or on yours, and we resell no cloud.
This page sets out the method and shows no client results.
Frequently asked questions
Should we rescue our existing system or rebuild it?
Rescue a system when it does the right job and its data is sound, however poor the code, and fix it in place behind tests. Rebuild only when the job has changed or the platform is past support, and then in slices beside the old system. We read the code before quoting.
What is the strangler fig pattern?
A way to replace a system without switching it off. Martin Fowler described it: new parts grow around the old system, each taking over one slice of its behaviour, until the old code has nothing left to do.
What does a code audit produce, and what does it cost?
Our assessment ends in a written recommendation to rescue, refactor, replace or rebuild, with the reasoning, the risks and a fixed price for the first stage. The first read, enough to say which way it leans, is free. A deep assessment of a large system becomes its own fixed-price first milestone.
Can you work on a codebase in a stack you do not normally use?
Often, on mainstream web stacks, because the first work is reading and testing the code. The proposal names the stack we would maintain it in, and where the right answer is a team that lives in your stack, we say that instead. Mainframe and COBOL systems stay outside our work.
Will the system stay up while it is modernised?
Yes. The plan is built around that constraint. Each new part runs beside the old system until it has proved itself, any release can be reversed, and data migrations are rehearsed and reconciled before cut-over.
Who owns the modernised system?
You do. Everything you have paid for is yours, source code included, on the same terms as a new build, and no clause in the contract ties the system to us.
What should we gather before the first call?
Bring whatever you have of the source code or repository access, the hosting account, the domain registrar, a recent database backup and a list of the outside services it talks to. Gaps are normal, and knowing which pieces are missing is the first finding.