Skip to content
Talk to an engineer

Legacy ModernizationRetire the system nobody wants to touch. One seam at a time.

You have 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 canceled three times, because a big-bang cutover risks the whole business on a single date. We move it one seam at a time instead. Every slice is small enough to roll back on a Tuesday afternoon.

Talk about this

Commitments

Big-bang cutovers required
0
Between independently valuable releases
Weeks
Old and new reconciled before every cutover
Parallel

Legacy Modernization and Cloud Migration

Discovery takes longer here because older systems have a lot to go through, and we're thorough. Where possible, we interview the people who built or maintained the original code. Discovery is a fixed fee, quoted on the size and complexity of the system.

When discovery is done, you get a report on how the system works today and your options for what to do next:

Stabilize
Fix the riskiest problems and document what's there
Modernize in stages
Replace one part at a time while the old system keeps running
Rebuild
Replace the system entirely, with a planned cutover and data migration
Migrate to the cloud
Move the system onto infrastructure somebody else maintains, which moves the maintenance and the storage risk off you with it

Each option comes with its cost, timeline and risk, so you can choose. Once you pick one, we quote it and work in the same weekly cycle as our custom software projects. The old system keeps running until the new one is proven.

When would I want this?

  • You want to cut the cost and risk of maintaining old infrastructure
  • You want the burden of keeping data safe to sit with somebody else
  • You want systems that scale without adding overhead
  • You want to reduce operational risk and improve reliability
  • You want to get to market faster

Sounds like

You might recognize 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.

  • We built it on a low-code platform and it can’t handle the volume any more.

  • The person who built it has gone, and it was mostly them and an AI.

  • Our license bill went from manageable to absurd and we’re locked in.

  • 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 you get

What lands on your side, and stays there.

  • 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 license and hosting savings model

Shapes

How this usually runs.

  1. Modernization assessment

    3–5 weeks

    A legacy estate is a bigger map than a single system, so this is its own engagement rather than a longer version of discovery. Fixed fee, quoted against your estate and the budget you have, because what moves the number is how much of it there is. Ask on the first call and you get the figure before you commit to anything. 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.

  2. Inherited system review

    1–2 weeks

    For one system you did not build and now own: a platform build that stopped scaling, a codebase whose author has gone, a project a vendor left unfinished. Shorter than the assessment above because it answers one question about one system rather than mapping an estate. Four answers, in this order: what you actually have, what it costs to keep it (licenses, the hours it quietly consumes, and the ceiling stated as a number rather than an adjective), what it costs to replace it, and our honest recommendation, which is sometimes to keep it. Fixed fee, quoted on the first call. Three options costed side by side, and doing nothing is one of them.

  3. First slice

    8–12 weeks

    We prove the pattern by moving one real, valuable capability off the legacy system and running both in parallel until the numbers agree.

  4. Sustained migration

    6–24 months

    Slice after slice on a predictable cadence, with the legacy footprint reported as a metric every month.

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.

  • Inherited builds: low-code, no-code and AI-generated

    A system that is two years old and unmaintainable fails differently from one that is twenty. The code may be generated rather than written, the logic may live in a platform’s configuration rather than in a repository, and the ceiling is usually commercial, a license tier or a record limit, rather than technical. We map what is actually yours, what is locked inside the platform, and what it would cost to leave.

  • 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.

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 work in
  • AS/400 · RPG
  • COBOL
  • VB6
  • Delphi
  • Access/VBA
  • ColdFusion
Migration patterns
  • Strangler fig
  • Change data capture
  • Dual-write
  • Anti-corruption layer
Targets
  • PostgreSQL
  • Azure
  • AWS
  • .NET 9
  • TypeScript
  • Python
Proof
  • Reconciliation harnesses
  • Golden-master tests
  • Shadow traffic

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. The plan is the deliverable before any code moves, because the alternative is the documented failure mode: reviewing the federal government’s most critical legacy systems, the U.S. Government Accountability Office found that agencies without a complete, documented modernization plan “will have an increased risk of cost overruns, schedule delays, and project failure”.

    Information Technology: Agencies Need to Develop Modernization Plans for Critical Legacy Systems (GAO-19-471) (opens in a new tab), U.S. Government Accountability Office

  • Sometimes the answer is that the system is fine. A low-code build serving forty people that is not growing is a decision somebody made well, and the review says so and tells you what to fix instead. The review is priced to be worth doing on its own, which is the only arrangement under which that answer is credible: an assessment that only becomes profitable through the project that follows cannot honestly recommend that nothing follows. You get three options costed side by side, and doing nothing is one of them.

  • The original requirements almost never were complete, and a rewrite that trusts them inherits the gap. That is 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.

All posts

Often paired with

Sources

  1. 1.Information Technology: Agencies Need to Develop Modernization Plans for Critical Legacy Systems (GAO-19-471) (opens in a new tab), U.S. Government Accountability Office,

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 what you already have can be made to work.

Talk to an engineerSee how we work
Reply
A person replies, not a sequence: within one business day, from someone who would be on the engagement.