How long does legacy application modernization services take? A realistic timeline

A scoped phase of legacy application modernization services takes eight to sixteen weeks at Eazyware, and a whole programme across a system of real size runs six to eighteen months because the phases are deliberately sequenced. The first phase is the slowest: discovery, a test safety net and a routing seam all land before a single module is replaced.

This is a scheduling article rather than a methodology one. It sets out where the calendar time actually goes, which activities overlap and which genuinely cannot, what pushes a date to the right, and why a vendor promising the whole thing in six weeks is describing a demo.

Why the timeline is quoted per phase and not per programme

Incremental modernization replaces a system module by module while the old one keeps serving users. That structure is what makes the work safe, and it is also why nobody can honestly quote a single end date for a fifteen-year-old application on the first call. Each module carries its own data, its own integrations and its own users, and each one is a small delivery with its own go-live.

The unit of estimation is therefore the phase. A phase takes a defined set of functions from the legacy system, builds the replacement beside it, runs both, and cuts traffic over. Eight to sixteen weeks covers most phases we deliver, matching our general range for scoped builds. The number of phases is what turns that into a programme length, and it is set by the module inventory, not by ambition.

Martin Fowler's write-up of the strangler fig application makes the point that the gradual approach takes longer in total than a rewrite on paper, and is chosen because the risk profile is completely different. That trade is the honest answer to why the calendar looks the way it does, and it is explored further in the strangler pattern in practice.

What happens in each week: a realistic schedule

The table below is a first phase on a mid-sized business application with four or five integrations. Later phases drop most of the discovery and safety-net weeks, which is why phase two is usually a third faster than phase one.

What adds weeks to a modernization timeline

Estimates move for a small number of recurring reasons. All of them are visible during discovery if anyone looks.

• Undocumented behaviour. Rules that live only in the code, or in one person's head, have to be discovered by testing rather than by reading. This is the single biggest variable.
• Dirty data. Duplicate customers, orphaned records and totals that never balanced add reconciliation cycles, and each cycle is days rather than hours.
• Downstream systems you do not control. Every partner reading your legacy database needs a change on their own release schedule, which is rarely yours.
• Shared people. A subject-matter expert who is also running month-end will give you two hours a week, not two days, and the phase stretches to match.
• Freeze windows. Financial year end, peak retail season and an admissions cycle all close the door on cutovers for weeks at a time.
• Approval chains. In regulated environments, each go-live needs a change board slot, and those slots have their own calendar.
• Scope added mid-phase. A new report requested in week nine is a new phase, not an extra day, and we say so rather than absorb it quietly.

How soon does the first module go live?

Between weeks ten and sixteen of the first phase, and that date is the single most useful commitment to extract from a vendor. Everything before it is preparation that produces no user-visible change, so a programme without a named first go-live has no way of proving its approach works before the budget is half spent.

Choose that first module by business pain rather than technical tidiness. The module people complain about is the one whose replacement buys you political room for the rest of the programme, and it is also the one where users will report differences quickly and precisely. A quiet, low-traffic module goes live smoothly and teaches you nothing, because nobody was watching it closely enough to notice if it was wrong.

The go-live itself is not a weekend event. Traffic moves function by function through the routing layer, each switch reversible in minutes, and the module is only declared complete when the legacy path has been idle for a full business cycle. On a monthly process that means waiting for month end before switching anything off, which is one of the reasons a phase ends at sixteen weeks rather than twelve.

What genuinely runs in parallel

Overlaps that work

Characterisation tests can be written while discovery finishes, because both are reading the same system. Data migration scripting overlaps the build cleanly, since the target schema is agreed before the screens exist. User training can start during parallel running, using the new system with real data, which produces better feedback than a sandbox ever does.

Overlaps that do not

Building a replacement module before the seam exists creates integration work you then throw away. Migrating data before reconciliation rules are agreed produces a beautifully populated database that finance rejects. Cutting over two modules in the same week removes your ability to attribute a problem to a change, which is the entire point of doing this incrementally.

The part nobody can compress

Parallel running takes the time it takes. Two to four weeks is typical, and the exit criterion is evidence rather than a date: the difference log is understood, not merely short. Compressing this window is the most common way a programme that was going well produces its first serious incident.

What does each phase cost while it runs?

A legacy-to-AI modernization programme starts at $31,500 or ₹22,40,000 and reaches $105,000 or ₹72,00,000 and beyond for systems with heavy integration. That figure buys a sequence of phases, not a single sprint, and the modernization cost breakdown explains which factors move it. Published starting prices for every programme are on the pricing page.

If the module inventory does not yet exist, a fixed-price discovery sprint at $3,250 or ₹2,00,000, credited to the build, produces it in ten days and converts a guess about duration into a schedule. After go-live, a Care Plan from $1,000 or ₹68,000 a month covers the patching and support the modernised system needs, with the Standard tier at $2,500 or ₹1,60,000 giving 24x5 cover and a four-hour response.

When a short timeline is a warning sign

Modernization quoted at six weeks end to end is either a much smaller job than you described or a rewrite wearing a different name. Ask which modules go live in those six weeks, what the rollback path is, and how long old and new run together. If the answer to the last question is nothing, the plan is a big-bang cutover, and that is the failure mode most enterprise buyers have already lived through once.

The opposite warning also exists. A programme with no phase shorter than six months has no feedback loop; you will be a year in before anyone knows whether the approach works. If a vendor cannot name something that goes live within four months, the plan is too coarse. The trade-offs on both sides are laid out in a rewrite versus incremental modernisation.

A schedule shaped around the business calendar

A university ERP modernization had to fit around admissions, fee collection and examinations, none of which move. The phases were ordered by which windows were open rather than by which modules were most interesting, and cutovers were deliberately placed in quiet weeks between cycles. That sequencing decision, described in the university ERP case study, added elapsed time to the programme and removed almost all of its risk. Institutional scheduling is covered further in modernizing institution ERPs around the academic calendar.

Before the clock starts

• Write down every freeze window for the next twelve months and share it with the vendor
• Name the subject-matter expert per module and confirm their real weekly availability
• Agree who signs off reconciliation totals before migration work begins
• Confirm whether a production-like data set can be provided, and how quickly
• List downstream integration owners and ask each for their release calendar
• Decide the first module by business pain, not by technical convenience
• Set the exit criteria for parallel running in evidence terms, not calendar terms

Related reading

A practical implementation guide to modernization services walks through what happens inside each phase, characterisation tests explains the safety net that occupies weeks two to four, and the hidden costs quotes leave out covers the budget side of a longer calendar. To turn this into dates against your own system, start with a conversation through the contact page.

A modernization timeline is trustworthy when it names the week each module goes live and the day you could roll it back.