03/MODERNIZE LEGACY SOFTWARE
The system still works. Nobody wants to touch it.
The application does its job. It has done it for years, and the business depends on it.
It is also several major versions behind, the original authors have moved on, and the test coverage is whatever survived the last deadline.
Every change now takes longer than it should, and the estimates carry a silent risk premium because nobody can predict what a small edit will break.
A rewrite has been discussed more than once. It never starts, because the system cannot stop earning for eighteen months while a replacement is built.
01/Why it happens
It is nearly always one of these three.
There is no safety net to change against
Without tests and a reliable pipeline, every change is validated by hand and by hope. Teams respond rationally by changing as little as possible, which makes the problem compound.
Upgrades were deferred until they became large
A dependency one version behind is an afternoon. Six versions behind, with breaking changes stacked on each other, is a project — so it gets deferred again.
The knowledge left with the people
The reasoning behind the odd decisions was never written down. What remains is code that looks wrong but might be load-bearing, and nobody is willing to find out which.
02/What we do about it
The engagement, phase by phase.
Assess and map
one to two weeks
We read the code and the infrastructure, and produce an honest map. This includes the parts that look alarming and turn out to be fine, which is most of them.
Produces
A written assessment: what is solid, what is risky, what is dead
Build the safety net
two to four weeks
Tests that pin the current behaviour — including the behaviour that is technically a bug but that customers now rely on — plus a pipeline that can deploy and roll back. Nothing else is safe until this exists.
Produces
Characterisation tests and a working deploy pipeline
Upgrade the foundations
two to six weeks, depending on how far behind
Runtime and dependencies moved forward in ordered steps, each deployed and verified separately, so a regression is traceable to one change.
Produces
Current runtime, framework and dependency versions
Improve the architecture where it pays
scoped with you, in increments
We change the parts that are slowing the team or the system down, and deliberately leave alone the parts that are ugly but stable. Not every piece of old code needs rescuing.
Produces
Targeted changes to the parts that actually cost you
03/What done looks like
How you will know it worked.
- Dependencies and runtime on supported, patched versions
- A test suite that fails when behaviour changes unintentionally
- Deploys and rollbacks that run from a pipeline rather than from memory
- An architecture document explaining the parts that previously only existed in someone's head
- Your team making changes without a risk premium on every estimate
- A list of remaining known issues, sized and prioritised rather than forgotten
04/Honest caveats
Where this gets harder.
Every engagement has failure modes. Here are this one’s, before you commit to anything rather than after.
- Modernization is not free and does not directly add features. It buys down risk and speeds up everything that comes after, which is real but harder to point at than a new screen.
- Characterisation tests pin existing behaviour, bugs included. Deciding which of those bugs to keep is a business decision, and we will bring you the list rather than choosing for you.
- Occasionally a rewrite genuinely is the right answer — usually when the platform is unsupported or the data model actively prevents what the business needs next. We will say so, even though the incremental work is the easier sale.
- Progress in the early phases is mostly invisible from outside. The safety net has to exist before anything looks like it is improving.
05/Questions
Modernize legacy software, asked about.
01Can you work on it while our team keeps shipping?
Yes, and that is the usual arrangement. Work goes through the same repository and review process as your team's, sequenced so we are not competing for the same files at the same time.
02What if the original developers are gone?
That is the common case rather than the exception. The assessment phase is how we rebuild the missing context — from the code, the infrastructure and the incident history rather than from people.
03How do you decide what not to touch?
Anything that is stable, understood and not blocking the team gets left alone regardless of how it looks. Effort goes where the pain is measurable: slow changes, repeat incidents, and blocked work.
Sound familiar?
Describe your version of it. You will get a reply from an engineer within one business day, including if we think you do not need us.