Legacy Application Modernization: cut the system down, not just the version number

Usually not, and a full rewrite is the most common way these projects fail. The default is incremental re-architecture behind the existing interface, with traffic moved in slices so every step is reversible.

It depends entirely on what you are running, and any number quoted before an assessment is guesswork. For reference, two engagements I ran personally took an engineering org from 20 people to 7 with run rate falling from $60K to $12K a month, and a $200K/year cloud bill to under $1K a month. Your system is not those systems.

That is the normal arrangement. The assessment and architecture are the outside contribution; your team knows the domain and usually does much of the implementation, which is also what makes the result maintainable after handover.

Then it says so, and you have saved a programme budget. Some legacy systems are stable, cheap and nearly finished being useful, and the right answer is to leave them alone and spend the money elsewhere.

It is scoped and priced per phase, so you can stop after any phase and keep what it delivered. The assessment comes first and its findings are delivered in writing before any implementation is agreed. Because each phase has a measurable outcome in cost, operational load or delivery time, the spend is tied to results you can see.

The assessment takes two to three weeks. After that, each phase is scoped on its own and must deliver a measurable reduction before the next one starts. There is no single long programme where the value arrives only at the end, because those are the programmes that get cancelled halfway through.

Rehosting or porting moves the system and keeps the same service count, operating burden and headcount, so the bill rarely falls. Re-architecture reduces what exists: fewer services, fewer moving parts, fewer people needed to run it. We recommend it where the savings justify it, and recommend leaving the system alone where they do not.

AI helps most with understanding legacy code: mapping call paths and data flow, finding dead code, and drafting characterisation tests before anything changes. It helps less with the rewrite itself, because a model will happily reproduce a bad abstraction in a new language. Deciding what to drop, merge or leave alone is still the work that pays.

Incrementally, behind the existing interface. New implementations run alongside the old ones and traffic moves across in slices, so every step can be reversed and nothing depends on a single cutover weekend. Characterisation tests capture current behaviour first, including quirks your customers now rely on.

An inventory of what runs, what it costs and what it is for. A map of what can be removed, merged or left alone. Infrastructure spend broken down by service with the waste identified. A clear view of which parts are load-bearing. Then a sequenced plan where every phase has a measurable outcome.

Because they move the system instead of reducing it, so the newer stack arrives with the same bill and the same team size. The other common failure is a programme whose value lands only at the end. We sequence phases so each one pays off on its own, which keeps the work funded.

Yes, that is the point of reducing what you run. Cost engineering runs alongside the phases and usually funds the rest of the programme. In one engagement I restructured an engineering organisation from 20 people to 7, taking its run rate from $60K a month to $12K. Your numbers will depend on your system.