Legacy Modernization
Retire the system nobody wants to touch. One seam at a time.
Every serious company has one: the application that runs a critical process, was written by someone who left in 2011, and now blocks everything. The rewrite has been proposed three times and cancelled three times, because a big-bang replacement asks the business to accept enormous risk on a single date. We don’t do that. We find the seams, put a boundary around them, and move functionality across in slices small enough that any one of them can be rolled back on a Tuesday afternoon.
- Big-bang cutovers required
- 0Big-bang cutovers required
- Between independently valuable releases
- WeeksBetween independently valuable releases
- Old and new reconciled before every cutover
- ParallelOld and new reconciled before every cutover
Sounds like
You might recognise one of these.
We can’t upgrade it and we can’t turn it off.
The vendor we hired left it two-thirds finished and walked away.
One person knows how the batch job works and he’s retiring.
Nobody will approve a two-year rewrite, and I don’t blame them.
It runs on a version of the runtime that stopped getting patches years ago.
What this includes
The work, specifically.
Not every engagement needs all of it. This is the range we cover and what each part is actually for.
Archaeology and dependency mapping
Before anything changes, we produce a truthful map: what calls what, which jobs are load-bearing, which tables are actually read, which features nobody has used since 2019. Most modernizations fail on surprises this stage removes.
Strangler-fig migration
A routing layer in front of the old system lets new implementations take traffic route by route. The legacy system shrinks continuously instead of being replaced on one terrifying date.
Data migration and reconciliation
Dual-write, backfill, and automated reconciliation that proves old and new agree, row by row, penny by penny, before anything is cut over.
Characterization testing
Undocumented systems get a test suite that captures what they currently do, including the bugs the business has come to depend on. That suite is what makes change safe.
Mainframe and thick-client exits
AS/400 and RPG, COBOL batch, VB6 and WinForms, Access and Excel VBA, on-premise Delphi. We’ve moved all of them, and we know which parts are genuinely hard.
What you get
Deliverables, not documents.
- Dependency map and risk register for the existing system
- A sequenced migration plan with independently valuable slices
- Characterization test suite for legacy behavior
- Reconciliation tooling proving data parity
- Documented rollback procedure for every slice
- Decommissioning plan with a licence and hosting savings model
Shapes
How this usually runs.
Modernization assessment
3–5 weeksFixed fee. Code and data archaeology, interviews with the people who keep it running, and a costed plan with three options, including the option to do nothing, priced honestly.
First slice
8–12 weeksWe prove the pattern by moving one real, valuable capability off the legacy system and running both in parallel until the numbers agree.
Sustained migration
6–24 monthsSlice after slice on a predictable cadence, with the legacy footprint reported as a metric every month.
Tooling
What we build it with.
No tool here was picked because it was new. Where we do reach for something novel, it is in one place, for a stated reason, and it is written down.
- Legacy we’ve exited
- Migration patterns
- Targets
- Proof
Questions
Modernization, honestly.
Usually yes, and it’s often the right structure. The people who know the legacy system are an asset, not an obstacle; we typically pair with them rather than replacing them.
Every slice has to deliver value on its own and has to reduce the legacy footprint measurably. We report both every month. If a slice can’t clear that bar, it isn’t the right slice.
They almost never were. That’s what characterization testing is for: we capture what the system actually does today, then change it deliberately rather than accidentally.
Further reading
What we think about this, at length.
- Engineering6 min read
What breaks when you replace an AS/400 while the plant keeps running
The hard part is not reading the RPG. It is that the machine cannot stop, the cutover window is a holiday shutdown, and four specific things fail that nobody budgets for.
- Engineering4 min read
Why your legacy rewrite keeps getting cancelled
It isn’t a failure of nerve. Executives are correctly refusing to accept a risk profile nobody should accept, and there’s a way to change the profile.
Next step
Tell us what’s breaking.
Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether you should be building this at all.