Resources · Decision guide
In short
Fixed-price projects, time and materials and subscriptions pay for the same work but put scope risk in different places and forecast differently. Choose by how well the scope is known, how long the work will last and how your finance team wants to see the spend. Whatever the model, agree the exit terms before the price.
Somewhere in your inbox there's a modernization proposal, and the first page you turned to was the one with the price. That's reasonable. But the shape of the price matters more than the number, because the shape decides who pays when the work turns out harder than expected. With a legacy system, it usually does.
There are three common ways to pay for modernization: a fixed-price project, time and materials, and a subscription or retainer. Each forecasts differently, rewards the vendor for different behavior and puts scope risk in a different place. The takeaway is simple: choose the model that matches how well the scope is known, how long the work will last and how your finance team wants to see the spend. Then make sure the exit terms let you leave without losing what you paid for.
Let's see how each one behaves once the work starts.
A fixed price is the easiest number to put in front of a board, and the one most likely to be wrong, because it's set before anyone knows what the legacy system actually does. Vendors protect themselves with a risk premium and a tightly defined scope, so every rule discovered later becomes a change request. The contract rewards matching the specification, not finding what it missed.
In our experience, fixed price works when the scope is small and already mapped. A German fintech client once asked us to fix-price a payments reconciliation workflow. We agreed, but only after a paid discovery phase that documented the rules first. Without it, one of us would have paid for a guess.
Time and materials (T&M) puts the budget risk on you and removes the vendor's incentive to argue about scope. The vendor can recommend the right approach rather than the cheapest one that satisfies the contract, but nothing in the model pushes them to finish. Forecasting is weak unless you add structure: monthly caps, a prioritized backlog you control and a report each period on what moved and what it cost.
T&M suits work where the scope is still being discovered, which describes most legacy modernization in its early months. It's a poor fit when the board wants a committed figure and nobody on your side has time to run the backlog.
A subscription trades a single project price for a recurring fee against agreed scope or capacity. The vendor commits to a term, often two or more years, and accepts that the backlog will change. You get a predictable monthly line of spend. The vendor gets continuity, which keeps the knowledge of your system in one team.
The weak point runs the other way: a vendor can deliver less per month than you expected and still bill the same. A subscription needs a visible backlog, agreed capacity per period and a report you can check. Without those three, it's a retainer in the old sense.
Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects and found an average cost overrun of 27%, but one in six projects overran by 200% on average, with schedules almost 70% late. McKinsey and Oxford, across more than 5,400 projects, found large IT projects run 45% over budget and deliver 56% less value than predicted, with each additional planned year adding 15% to the overrun.
Those numbers don't disappear when you sign a fixed-price contract. They move. A vendor who absorbs an overrun recovers it on your change requests, or by cutting corners you won't see until the rebuild handles live traffic. The same McKinsey article describes a bank that negotiated a low unit price for a trading-system project and then "encountered high costs for changes and support after the system was introduced." The discount was real. So was the bill.
Here I have to be careful, because the accounting treatment of modernization spend is your finance team's decision, not a vendor's. What I can describe is the questions that come up.
A project that builds software you own has traditionally been discussed as capital investment, and a recurring service fee as operating expense. It's rarely that clean. The IFRS Interpretations Committee published an agenda decision in 2021 on configuration and customization costs in cloud arrangements, and the FASB issued ASU 2018-15 on implementation costs in a cloud service contract. Both exist because the line between buying an asset and buying a service is blurred, and a renewal subscription that delivers code into your own repository sits right on it.
Expect the board or audit committee to ask some version of these:
Bring the finance team in before the model is chosen. The proposals we've seen stall are the ones where the CFO found out at contract review.
It sounds contradictory to quote research showing longer projects overrun more, then consider a two-year term. The difference is what the term commits you to. A long project commits you to a single outcome, with the cost of being wrong rising each year. A long service term commits you to capacity and a method, with scope decided period by period from a backlog you control. The team that captured how your system behaves in year one is more useful in year two than a new team reading their notes, and a vendor who knows the relationship lasts can price capacity rather than risk.
The case against is lock-in, and it's fair. The UK Cabinet Office, reviewing its experience of exiting large IT contracts, advised that terms should be "for the shortest appropriate duration" and that exit "typically takes longer than anticipated (up to 4 years)." That was written about single-vendor outsourcing deals of five to ten years, a different animal, but the lesson carries: a term is only safe when the exit is designed before the start. Whatever the model, the exit clause should cover:
"We'll never need that, we're not planning to leave." Nobody plans to. Exit terms aren't a comment on the relationship; they're what makes a long term safe to sign.
It depends, and these are the variables. How well is the scope known? If an assessment has already mapped the workflow and its rules, a fixed price is an informed bet; if not, you're paying a premium for someone else's uncertainty. How often will the system change after the first release? If "constantly," a project with an end date is the wrong shape. And how does your board want to see the spend: a capital line with a completion date, or a monthly figure it can forecast?
Say three vendors quote the same scope: a fixed $900,000; T&M estimated at $700,000 with a wide range; and a subscription at $35,000 a month over two years, so $840,000. The numbers look comparable. They aren't. The first includes a risk premium you'll never see itemized. The second could land anywhere. The third buys the first migration plus two years of upgrades and documentation. Compare what each one buys, not what each one costs.
Fabrica is testing two of these models: an assessment and pilot with a fee agreed before work starts, and a renewal subscription on a two-year term with the first migration included and exit terms agreed up front. In either case the fee pays for the CLEAR method: Capture and Lock produce a specification your owners approve, Engineer and Attest prove the rebuild against the running system, and Release moves production by cohort with rollback. Code lives in your repository, and how the service is treated in your accounts is your finance team's call, not ours.
A modernization proposal is a financial instrument as much as a technical plan. Fixed price moves risk to the vendor and charges you for it. T&M keeps the risk with you, and the control too. A subscription spreads risk over a term and asks for continuity in return. Legacy systems hide rules, and someone pays when those rules appear. Decide which model fits how your company funds technology, read the exit clause twice, and only then look at the price.
Tell us about it on a 30-minute call. We'll suggest a first scope and what a technical review would need to confirm.