How are modernization services priced?

By commercial model matched to how much is known. Discovery is a bounded, fixed-price engagement because its scope is clear. Early slice delivery is priced per slice, again fixed, once discovery has scoped the work. The longer transformation runs on time-and-materials or a fixed model, depending on how predictable the remaining slices are. You commit incrementally, as confidence grows.

Why won't a modernization vendor quote a price up front?

Because the cost lives in the system, not in a rate card — and the system is unknown until someone reads it. A precise total quoted before any code is analyzed is either padded to cover the unknowns or set to win the deal and revised later. The honest answer is a fixed-price discovery first, then a scoped figure once the coupling is understood.

What drives the cost of a modernization project?

The depth of coupling between the application and its runtime, how much business logic is undocumented, how little downtime the business can tolerate, the compliance scope in play, and the size of the estate. A small, well-understood system costs far less to move than an entangled one carrying a decade of undocumented rules.

What's the difference between fixed price and time-and-materials for modernization?

In a fixed-price model the vendor commits to a total against a defined scope, so the vendor carries the risk of underestimating, which only works honestly when the scope is genuinely well understood. In time-and-materials you pay for effort actually spent, carrying that estimation risk yourself in exchange for the flexibility to change direction as you learn. Neither is better outright. Fixed price suits bounded, well-scoped work like discovery or a single slice. T&M suits the open-ended parts of a long transformation.

Is outcome-based or value-based pricing available for modernization?

Sometimes, for the part of a deal where the outcome can be defined and measured cleanly, such as a legacy system fully decommissioned or a specific performance benchmark hit. It rarely covers a whole modernization honestly, because most of the value it delivers, maintainability, reduced risk, faster future changes, resists being reduced to one metric without arguments over what it should have been. Treat an outcome-based pitch that covers the entire fee with the same skepticism as a confident fixed total for unread code.

Does pricing a modernization per slice cap the total cost of the program?

It bounds each slice, not the program as a whole, and that distinction matters. Each slice is scoped and fixed once discovery has sized it, so you always know what the next increment costs before committing to it. What it does not do is promise a fixed total for a transformation whose full scope isn't knowable until later slices are reached. The real protection is that you are never asked to fund more than one bounded increment at a time, with the option to stop after any of them.

What should I look for when comparing quotes from different modernization vendors?

Whether the model matches the phase, fixed for bounded work, time-and-materials or fixed-per-slice for ongoing delivery, rather than one number covering everything including work nobody has scoped. Whether the assumptions and unknowns are named rather than buried in a contingency line. And whether the engagement has a defined end state you'd recognize, not an open-ended relationship with no exit.

How Modernization Is Priced

ModernLift ·June 25, 2026 ·12 min read

Modernization is priced by commercial model, not by a list price — because the cost is driven by the system, which no vendor can size before reading it. The honest shape is a fixed-price discovery first, fixed-price-per-slice delivery once the work is understood, and time-and-materials or fixed pricing for the longer transformation. What drives the total is coupling, undocumented logic, downtime tolerance, and compliance scope — not a per-seat rate.

The first question every buyer asks is “what will this cost?” — and the honest answer is that no one can tell you before they have read your system. Modernization cost does not live in a rate card; it lives in the coupling, the undocumented rules, and the downtime you can’t afford. A vendor who quotes a confident total before seeing the code is either padding to cover what they don’t know or pricing to win and revising later. This guide is about how to think about the spend — the models you’ll see and what actually moves the number — so you can read a proposal clearly. It contains no prices, because an honest one can’t.

Why there’s no list price

A modernization is not a product with a SKU. The same headline goal — “get us off this aging system” — can mean a few weeks of upgrade work or eighteen months of careful re-architecture, and the difference is invisible from the outside. Two systems that look identical on an org chart can differ by an order of magnitude in effort, depending on how entangled the application is with its runtime and how much of its behavior was ever written down.

That is why the credible commercial answer is structured, not a single figure: price the part that is knowable now, and scope the rest once it becomes knowable. The structure below is how that works in practice.

The three commercial models

A modernization engagement moves through three phases, and each is priced to match how much is known at that stage. Commitment scales with confidence.

Phase	What happens	Commercial model
Discovery	The system is read end to end; you get a blueprint, roadmap, and risk assessment	Fixed price — the scope is clear, so the fee can be too
Accelerator	The first slices are built, validated, and put into production	Fixed price per slice — bounded units of known work
Transformation	Ongoing slice delivery at steady velocity until the legacy is retired	Time-and-materials, or fixed — depending on how predictable the remaining slices are

The logic is the same at every step: you never commit to a number for work nobody has scoped yet. Discovery is fixed because its boundaries are clear before it starts. Slices are fixed because discovery has sized them. The longer transformation is priced on the model that fits how predictable the remaining work is — fixed where the slices are well understood, time-and-materials where they’re still being discovered. A deeper treatment of these structures lives in modernization pricing models.

The commercial models, compared

Underneath those three phases sit a handful of pricing models you’ll see across the modernization market, not just from us. Knowing what each one actually commits both sides to is what lets you read a proposal instead of just trusting it.

Model	How it works	Who carries the estimation risk	Best fit	Watch for
Fixed price	A total is agreed against a defined scope before work starts	The vendor, if the estimate runs short	Discovery, or any single slice small enough to be genuinely well understood	A fixed total quoted for work nobody has scoped yet
Time and materials (T&M)	You pay for the effort actually spent, billed against agreed rates	You, in exchange for the flexibility to change direction	The open-ended parts of a long transformation, where scope is still being discovered	A T&M engagement with no milestones, so there’s nothing to check progress against
Fixed price per slice	Each increment of the transformation is scoped and priced on its own, once discovery has sized it	The vendor, per slice, because each one is bounded	Ongoing delivery once discovery has scoped the work in front of you	Slices priced before discovery has actually happened, which is fixed price in name only
Outcome or value-based	Some or all of the fee is tied to a measurable result, such as a legacy system fully decommissioned	Shared, weighted toward the vendor for the tied portion	The part of a deal where the outcome is genuinely well defined and measurable	Outcomes vague enough that nobody can say whether they were met, or a pitch that tries to tie the entire fee to one metric
Retainer	A recurring fee buys ongoing delivery capacity rather than a fixed deliverable	You, since the fee is paid whether the capacity is fully used or not	Long-running programs with a steady, proven cadence of slice delivery already established	A retainer with no defined output, which functions as an annuity rather than a project

Fixed price and T&M are the two foundations. Everything else is a variation built for a specific situation, per-slice delivery, an outcome the two sides can genuinely agree on, or steady-state capacity for a program that’s already proven its cadence. None of them removes the need for discovery first. A vendor offering to price per slice, or tie fees to an outcome, before reading your system has just moved the guess somewhere less visible.

What actually drives the cost

Once you understand the models, the useful question becomes what moves the total within them. Five factors do most of the work.

Coupling. How deeply the application logic is bound to its current runtime — the stored procedures, the dialect-specific code, the integration surface. Tight coupling is the single biggest multiplier, because it turns a move into a re-architecture.
Undocumented logic. Every rule that lives only in the code or in someone’s head has to be discovered before it can be safely carried forward. The more of the system that was never written down, the more discovery the move requires.
Downtime tolerance. A system that can take a maintenance window is cheaper to move than one that must keep transacting throughout. Zero-downtime delivery is worth its cost for load-bearing systems, but it is a cost.
Compliance scope. A system inside the cardholder-data, ePHI, or audited path carries validation and evidence requirements that a low-stakes internal tool does not.
Estate size. More slices, more integrations, more data — straightforwardly more work, though usually the most predictable of the five drivers.

Notice what’s absent from that list: a headcount rate. The cost of modernization is governed by the properties of your system, not by how many seats a vendor bills. That’s why the most useful thing you can do to size a project is to understand the system — which is exactly what discovery is for.

How to read a modernization proposal

A few signals separate an honest commercial proposal from a sales posture.

Confidence should match evidence. A precise fixed total for transforming a system no one has read yet is a flag, not a feature. Expect a fixed discovery first, then a scoped figure.
The model should match the phase. Fixed price for bounded work, time-and-materials or fixed-per-slice for ongoing delivery. A single number covering a multi-year transformation, or an outcome tied to a metric nobody could actually verify, is the same red flag wearing a different commercial wrapper.
The unknowns should be named. A good proposal says plainly what it would need a discovery phase to confirm. Silence on the unknowns means they’ve been buried in a contingency you can’t see.
The end should be defined. What does “done” look like — legacy decommissioned, your team owning a modern system? An open-ended engagement with no defined end state is an annuity, not a project.

When staying put is the cheaper answer

We don’t publish prices, and we won’t quote one for a system we haven’t read — that’s not coyness, it’s the same parity-first honesty we bring to the engineering. The flip side is a real commitment: the cost driver to weigh against any of this is the cost of standing still. An aging system carries its own running bill — maintenance that only climbs, audit findings, the risk concentrated in a few retiring experts — and for a stable, low-stakes system, that bill may be lower than the cost of moving. Sometimes the honest financial answer is to stay put, or to run a simple in-place upgrade, and we’ll say so. The legacy cost calculator helps put a figure on the do-nothing side of that comparison.

Where to start

The way to turn “how much?” into a real number is to scope the system. A discovery call is a 30-minute conversation about what you’re running and how entangled it is — enough to frame which model fits and what would drive the cost, with no figure invented on the spot. The modernization guides show how the work lands by platform, and software modernization cost covers the business case behind the decision. Reach the team at sales@modernlift.ai.

Frequently asked questions

How are modernization services priced?: By commercial model matched to how much is known. Discovery is a bounded, fixed-price engagement because its scope is clear. Early slice delivery is priced per slice, again fixed, once discovery has scoped the work. The longer transformation runs on time-and-materials or a fixed model, depending on how predictable the remaining slices are. You commit incrementally, as confidence grows.
Why won't a modernization vendor quote a price up front?: Because the cost lives in the system, not in a rate card — and the system is unknown until someone reads it. A precise total quoted before any code is analyzed is either padded to cover the unknowns or set to win the deal and revised later. The honest answer is a fixed-price discovery first, then a scoped figure once the coupling is understood.
What drives the cost of a modernization project?: The depth of coupling between the application and its runtime, how much business logic is undocumented, how little downtime the business can tolerate, the compliance scope in play, and the size of the estate. A small, well-understood system costs far less to move than an entangled one carrying a decade of undocumented rules.
What's the difference between fixed price and time-and-materials for modernization?: In a fixed-price model the vendor commits to a total against a defined scope, so the vendor carries the risk of underestimating, which only works honestly when the scope is genuinely well understood. In time-and-materials you pay for effort actually spent, carrying that estimation risk yourself in exchange for the flexibility to change direction as you learn. Neither is better outright. Fixed price suits bounded, well-scoped work like discovery or a single slice. T&M suits the open-ended parts of a long transformation.
Is outcome-based or value-based pricing available for modernization?: Sometimes, for the part of a deal where the outcome can be defined and measured cleanly, such as a legacy system fully decommissioned or a specific performance benchmark hit. It rarely covers a whole modernization honestly, because most of the value it delivers, maintainability, reduced risk, faster future changes, resists being reduced to one metric without arguments over what it should have been. Treat an outcome-based pitch that covers the entire fee with the same skepticism as a confident fixed total for unread code.
Does pricing a modernization per slice cap the total cost of the program?: It bounds each slice, not the program as a whole, and that distinction matters. Each slice is scoped and fixed once discovery has sized it, so you always know what the next increment costs before committing to it. What it does not do is promise a fixed total for a transformation whose full scope isn't knowable until later slices are reached. The real protection is that you are never asked to fund more than one bounded increment at a time, with the option to stop after any of them.
What should I look for when comparing quotes from different modernization vendors?: Whether the model matches the phase, fixed for bounded work, time-and-materials or fixed-per-slice for ongoing delivery, rather than one number covering everything including work nobody has scoped. Whether the assumptions and unknowns are named rather than buried in a contingency line. And whether the engagement has a defined end state you'd recognize, not an open-ended relationship with no exit.