Legacy Code Modernisation and Refactoring
Making an old codebase safe to change again - incrementally, in production, without stopping the business.
Legacy code is rarely bad code. It is usually code that worked, kept working, and accumulated twenty different people's assumptions with no documentation. The symptom is not that it fails - it is that every change takes three times longer than it should and nobody is confident deploying on a Friday.
This is a large part of what I do, and it is work most developers avoid. I do not.
What modernisation covers
Chosen based on what is actually causing pain, not on a checklist.
- Language and runtime upgrades - including long-overdue ones
- Framework and dependency upgrades
- Refactoring towards a maintainable structure
- Introducing automated tests around risky areas
- Removing dead code and unused dependencies
- Documenting how the system actually works
- Security patching and vulnerability remediation
- Performance profiling and optimisation
- Splitting monoliths where it genuinely helps
- Database schema cleanup and indexing
How modernisation works in practice
Incremental and reversible. The system stays live throughout.
1Assessment
I read the code, run it, and map what is actually there against what people believe is there. You get a written assessment of risk areas, upgrade blockers and effort - useful on its own even if you go no further.
2Safety net first
Before changing behaviour, I put tests around the parts we are about to touch. Refactoring without a safety net is how legacy projects turn into outages.
3Incremental change
Small, deployable changes rather than a big-bang rewrite. Each one goes to production and proves itself before the next.
4Upgrade path
Runtime, framework and dependency upgrades sequenced so that each step is independently shippable.
5Documentation and handover
The system is left documented, so the next person - possibly you - is not in the same position in three years.
Why a rewrite is usually the wrong answer
The instinct with a difficult codebase is to start again. It is almost always more expensive than it looks, because the old system encodes years of business rules that nobody has written down and that only become visible when they are missing. Rewrites routinely take twice the estimate and ship with a feature set that is a subset of what was replaced.
Incremental modernisation is less satisfying and more reliable. You keep the business running, you keep the accumulated knowledge, and you can stop at any point with value already delivered. I will recommend a rewrite when the evidence genuinely supports it - but that is the exception, and I will show you the reasoning.
The other thing worth saying plainly: an unsupported language runtime or framework version is a security problem, not just a technical debt problem. If your stack has fallen off its support window, that moves up the priority list ahead of everything else. See also cloud and server administration for the infrastructure side of the same question.
Related services
API Development
REST and GraphQL APIs, integrations and microservices that are documented, versioned and pleasant to consume.
Data Migration & ETL
Moving data between systems without losing rows, breaking references or taking the business offline.
Cloud & Server Admin
AWS and Linux setup, hardening, monitoring and deployment pipelines for teams without a dedicated ops person.
Frequently asked questions
Our original developer has left and there is no documentation. Can you still help?
Yes - that is one of the most common situations I am called into. The first phase is reconstructing how the system works by reading and running it, and the output of that phase is documentation you keep regardless of what happens next.
Will the system have to go offline?
No. The whole approach is built around incremental change to a live system. Where a specific step needs a maintenance window, it will be planned and short.
How do you price this kind of work?
The assessment phase is fixed price, because it is well defined. The work that follows is priced once the assessment tells us what is actually there - quoting before that would be guesswork.
What if the code is in a language you do not normally use?
Tell me what it is. After 20 years the patterns transfer more than the syntax differs, and I will be honest with you if a codebase is genuinely outside what I should be taking on.
Sitting on a codebase nobody wants to touch?
A written assessment is the cheapest way to find out how bad it actually is - and it is usually less bad than feared.
Tell me about your project