Legacy Software Modernization Services
The system works, the business depends on it, and nobody wants to touch it. A rewrite is the obvious answer and the one most likely to fail. There is a better route, and it is slower and duller.
Discuss your projectWhy the big rewrite usually fails
The pattern is well documented and repeats reliably. A rewrite is approved, a team starts building the replacement, and meanwhile the old system must keep being maintained because the business runs on it. Now two systems are being developed, the new one is chasing a moving target, and it must reach feature parity with twenty years of accumulated behaviour before it can be switched on. Much of that behaviour is undocumented, and some of it is undocumented because the person who understood it left.
Then the switch-on is all-or-nothing. Everything migrates on one date, and every assumption the new system got wrong is discovered simultaneously by the whole business. If it goes badly, the fallback is reverting to the old system — which has carried on diverging in the meantime.
The alternative is to replace the system piece by piece while it keeps running. New functionality is built in the new stack and the old system is routed to it one capability at a time, usually behind a façade or proxy that decides which implementation handles a given request. Each piece goes live on its own, can be reverted on its own, and delivers value before the next one starts. The old system shrinks until what remains is small enough to retire or to leave alone.
This is not a novel idea — it is the strangler pattern, and it is slower in total than a rewrite that goes perfectly. It is considerably faster than a rewrite that does not, and it never puts the business in a position where it cannot operate.
How we run it
- 01
Audit and map what exists
What the system does, what depends on it, where the data lives, and which behaviour is load-bearing. This includes finding the undocumented rules, which usually means talking to the people who use it rather than reading the code.
- 02
Put a seam in
A proxy, API gateway or façade in front of the old system, so requests can be routed per capability. Nothing changes functionally at this stage — it is the step that makes everything after it incremental.
- 03
Pick the first slice carefully
Something self-contained, valuable, and low-risk to revert. Often a read-only view or a reporting function. The purpose of the first slice is to prove the mechanism, not to tackle the hardest part.
- 04
Move data deliberately
The hardest part of any modernisation. Usually a period where both systems read the same data, or one writes and the other follows, rather than a single migration. This is where most of the engineering care goes.
- 05
Repeat, in priority order
Each capability moved, proven in production, and left running before the next begins. Progress is visible continuously rather than at the end.
- 06
Retire what is left
Or do not. A small remaining legacy component that works and needs no changes is a perfectly acceptable end state, and insisting on removing it is sometimes vanity rather than engineering.
What we work with
- Older PHP applications, which are the most common case and often modernisable in place to a surprising degree.
- Legacy .NET Framework applications moving toward current .NET.
- Python 2 code, and early Django or Flask versions.
- Monolithic Java applications, where the useful move is frequently a modular monolith rather than microservices.
- Desktop applications being moved to the web, where the hard part is usually that the desktop version does things a browser cannot.
- Access and Excel-based systems that became business critical by accident, which is more common than anyone admits.
- Systems with no source code, where the starting point is understanding the running application and its database.
Common questions
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch