Solution · Apps & software
Legacy software modernisation
Most companies have at least one system that nobody wants to touch: it was written years ago, the original developer has left, documentation is thin, and every change risks breaking something else. Yet the business depends on it daily. Modernisation makes such a system safe to change again — usually step by step, without a risky big-bang replacement.
[ 01 ]
In short
In short
- 01
The first step is an assessment: what the system does, who relies on it, where the risks are and what the code actually looks like.
- 02
Stabilisation comes before improvement: backups, monitoring, a copy for testing and a documented deployment process.
- 03
Gradual replacement — moving one module at a time behind stable interfaces — is usually safer than a full rewrite.
- 04
A full rewrite is justified when the platform itself is unsupported or insecure and no part can be reused.
- 05
Data migration is often the hardest part and deserves its own plan.
[ 02 ]
Scope
Signs a system needs attention
- Changes take weeks because nobody is sure what else they will affect.
- The system runs on an operating system, database or framework version that no longer receives security updates.
- Only one person knows how to deploy it, or how it works at all.
- Staff keep parallel spreadsheets because the system cannot do what they need.
- Integrations with new services — payment providers, messengers, analytics — are impossible or fragile.
How we approach it
1. Assessment
We review the code, the infrastructure, the data and the way the system is used. We interview the people who rely on it. The result is a map of modules, dependencies and risks, and a recommendation: stabilise and extend, replace gradually, or rebuild.
2. Stabilisation
Before changing anything, we make the system recoverable and observable: tested backups, a staging copy with anonymised data, monitoring of errors and performance, and a repeatable deployment. Security fixes for known vulnerabilities come here too.
3. Tests around critical behaviour
Legacy systems rarely have automated tests. We add tests around the behaviour that must not change — calculations, document generation, integrations — so that later changes can be checked quickly.
4. Gradual replacement
Modules are replaced one by one. New functionality is built in a modern stack alongside the old system, connected through an API or a shared database layer, and traffic is moved to the new module when it is ready. The old system shrinks until it can be switched off. This pattern is often called the "strangler fig" approach.
5. Data migration
Old data is often inconsistent: duplicates, free-text fields used for three different purposes, values that only make sense to someone who left years ago. We profile the data, agree on mapping rules and run repeatable migration scripts. See data migration to a new system.
Rewrite or improve?
A complete rewrite looks attractive because it promises a clean start, but it has a known trap: while the new system is being built, the old one keeps changing, and the new one must catch up with years of undocumented rules. We recommend a rewrite when the platform cannot be secured or supported, or when the system is small enough to replace quickly. Otherwise gradual modernisation delivers value sooner and with less risk. The same logic applies to websites: see redesign vs rebuild.
Choosing the target stack
The new stack should be widely used, well supported and within reach of developers you can hire later. We explain our reasoning in choosing a tech stack and avoid choices that would make you dependent on us or on a rare skill set.
What we need from you
- Access to the code, servers, databases and any documentation that exists.
- Time with the people who use the system and the people who used to maintain it.
- A list of what hurts most today, in business terms.
[ 03 ]
FAQ
Frequently asked questions
Can the system keep running during modernisation?
Yes — that is the point of the gradual approach. Users keep working while modules are replaced behind the scenes.
What if the original source code is lost?
It happens. Sometimes compiled code can be analysed; often the practical path is to document the system's behaviour from the outside and rebuild it module by module.
How do we know modernisation is worth it?
We compare the cost of keeping the system as it is — incidents, slow changes, manual workarounds, security risk — with the cost of the modernisation plan, stage by stage.