The hidden costs of legacy application modernization services that quotes leave out

The hidden costs of legacy application modernization services are almost never in the build itself. They are the lines that begin the day the first module goes live: model inference, parallel running of old and new, data reconciliation, evaluation upkeep, integration and middleware licences, change management, and the ongoing care plan. A quote prices the build. These seven price the ownership.

This article walks each line, gives you the questions that force it into a written quote, and sets out what Eazyware charges for the parts we can name up front so you can budget the rest honestly.

Why the quote and the true cost diverge

A modernization quote is a scope document. It answers one question well: what will it cost to move these capabilities off the old system and onto a new one. It is a snapshot of a project. What you are actually buying is a system that runs for the next five to ten years, alongside the thing it is replacing, for longer than anyone plans.

The divergence is structural, not dishonest. Most vendors quote what they can scope, and the ongoing lines depend on decisions you have not made yet: how much traffic, which model, how long you keep the old system warm, how many people need retraining. A vendor who invents those numbers to make the quote look complete is guessing. A good vendor names the line, states the driver, and gives you a range.

Martin Fowler's description of technical debt is the useful frame: the interest payments are real whether or not anyone books them. Modernization does not remove the interest, it refinances it. The job of a budget is to show where the new payments land.

The seven cost lines a quote usually omits

1. Model inference on live traffic

If the modernised system has AI in it, whether that is document extraction, a copilot over the new screens or natural language reporting, every real user request costs money. A pilot with fifty users tells you almost nothing about a rollout to five thousand. Inference is a usage line, not a project line, and it scales with adoption, which is the thing you are trying to maximise. Model it before launch with the LLM inference cost calculator and re-forecast monthly.

2. Parallel running

Under the strangler-fig pattern the old system stays alive while capability moves across module by module. That means two sets of licences, two hosting bills, two sets of on-call and, in regulated environments, two audit trails, for anywhere from six months to two years. Almost no quote includes the incumbent's licence renewal, and it is often the single largest hidden number in the programme.

3. Data migration, reconciliation and the long tail of exceptions

Migration is quoted as a task. Reconciliation is a practice. Every cutover produces records that do not balance: orphaned rows, historic codes nobody recognises, decimal drift in fifteen-year-old financial tables. Someone has to adjudicate those, usually a finance or operations person on your side, for weeks. Budget their time as a real cost, because it is the one that delays go-live.

4. Evaluation upkeep

An evaluation suite is built once and maintained forever. Models get deprecated, prompts drift, your business rules change, and the golden set that proved the system worked in March is stale by September. Expect to re-run and extend the suite on every model change and every quarter regardless. This is covered in Evals: the practice that separates AI demos from AI products.

5. Integration and middleware licences

The anti-corruption layer between old and new usually needs something: an API gateway, a message broker, an iPaaS connector, a change-data-capture tool. These are third-party subscriptions, often priced per connection or per message, and they grow as you add modules. Ask for the named list, not the phrase "integration layer".

6. Change management and training

People who have used the same green screen for twelve years are fast on it. The new system will make them slower for six to ten weeks. That productivity dip is a cost, and so is the training, the floor-walking during hypercare, and the two or three power users who are pulled off their day job for the duration. Adoption failure is the most common way a technically sound programme is judged a failure, as Why enterprise software implementations fail on adoption sets out.

7. Care and on-call after go-live

The build ends. The system does not. Patching cadence, dependency upgrades, incident response, monitoring and the AI-specific work of cost monitoring and prompt regression are monthly commitments. Priced honestly, they are not large. Left out of the business case, they are the reason year two looks like a surprise.

What each line typically costs

The questions that force these into writing

Send these before you sign, and ask for answers in the contract rather than in an email thread.

• Who pays for model usage, and on whose account? At Eazyware you pay for API usage through your own accounts, and we set budgets, routing and dashboards so it stays predictable. Any other arrangement means your running cost is inside someone else's margin.
• How long does the incumbent stay live, and who renews its licence? Get the assumed parallel-running window in months and a named owner for the renewal.
• What happens to records that do not reconcile? Ask for the exception process, who adjudicates, and how many hours of your team's time is assumed.
• Who maintains the evaluation suite after handover? If the answer is "you do", make sure the suite and its documentation are part of the deliverable.
• Which third-party tools are needed for integration, named and priced? Gateways, brokers and connectors, with their pricing basis.
• What is the assumed training effort, in hours per role? Then double it for the roles that never used a browser-based system.
• What is the care plan and its SLA? Response time is not resolution time; ask for both.
• Who owns the code, prompts and infrastructure at the end? You should, without a licence-back clause.

What Eazyware charges, and what we will not quote

Our Legacy-to-AI Modernization Program starts at $31,500 or ₹22,40,000 and runs to $105,000 or ₹72,00,000 and above for multi-module programmes, fixed price against a locked scope. Post-launch, Care Plans are published: Essential at $1,000 or ₹68,000 a month with business-hours IST cover and ten hours, Standard at $2,500 or ₹1,60,000 with 24x5 cover and twenty-five hours, Enterprise at $5,250 or ₹3,40,000 with 24x7 cover, one-hour response, sixty hours and a named engineer. The AI system add-on is $750 or ₹40,000 a month and covers evals, cost monitoring, prompt regression and re-indexing. Every figure is on the pricing page.

What we will not put a number against in a first quote is your inference bill, your incumbent's licence renewal or your internal change effort, because we would be inventing them. We give you the drivers, a forecasting model and a range, and we re-forecast at the end of the discovery sprint when the numbers are real. A ten-day Sprint Zero at $3,250 or ₹2,00,000, credited to the build, exists partly to turn those guesses into figures you can take to a board.

When the cheap quote is genuinely the right one

Not every low quote is hiding something. If your legacy application is a single internal tool with one database, no regulated data, under fifty users and no AI component, a modernisation that looks small probably is small. In that case the hidden costs are genuinely close to zero: there is nothing to run in parallel, reconciliation is a weekend, and inference does not apply because there is no model in the loop.

Equally, if the honest answer is that the system should be retired rather than modernised, you should hear that. We say no to work where a commercial product covers the need outright, and a sensible vendor will too. The trade-offs between replacing, rewriting and modernising incrementally are set out in Application modernization vs rewrite.

What this looks like on a real programme

A university ran a fifteen-year-old ERP that touched admissions, fees and examinations. The build was the smaller half of the story: the institution had to keep the old system live across a full academic cycle because results and fee records could not be cut over mid-term, and reconciliation of historic fee data took weeks of the finance team's own hours. Module-by-module replacement behind a stable interface is what made it survivable. The programme is described in the university ERP modernisation case study, and the calendar constraint is the general lesson: your organisation's cycle, not the vendor's Gantt chart, sets the parallel-running window.

Before you approve the budget

• Write down the parallel-running window in months and price both systems for that period
• Forecast inference at expected adoption, not pilot volume, and set a monthly budget alert
• Name the person on your side who adjudicates reconciliation exceptions
• Add the evaluation suite and its upkeep to the deliverable list, not the wish list
• List every third-party integration tool with its pricing basis
• Budget training hours per role and a six to ten week productivity dip
• Choose a care plan tier before go-live, not after the first incident
• Confirm in writing that you own the code, prompts, infrastructure and documentation

Related reading

Legacy application modernization services cost in 2026 breaks down the build side in detail, Total cost of ownership for AI systems covers the running lines for AI specifically, and What a care plan should cost explains what a maintenance contract should and should not include. If you want a number for your own programme, the estimate tool is the fastest starting point.

Ask for the running costs in the quote and you will get a bigger number and a better decision.