A legacy IT support contract can have transparent hourly rates and still leave the CFO unsure about next quarter’s spending. The rate card is known; the total is not. Predictability comes from two things: a contract that defines exactly what can change the price, and engineering that reduces how often it has to change.

In short: Cost variance is the gap between forecast and actual support spending. In legacy environments it comes from incident volume, resolution time, escalations, and undocumented dependencies, none of which appear on a rate card. The choice between time-and-materials (T&M) and a fixed fee decides who absorbs that variance. Only better engineering reduces it.

This piece continues our series on how legacy IT systems cost the CTO, CFO, and COO differently.

Key Takeaways

  • An hourly rate prices effort. The total depends on incident volume, resolution time, escalations, and undocumented dependencies.
  • T&M usually leaves effort risk with the client. A fixed fee moves part of it to the provider, but only within the agreed scope.
  • An unstable support baseline inflates contingency reserves and makes modernization business cases harder to compare.
  • A fixed fee is predictable only when scope, service levels, exclusions, volume assumptions, and renewal terms are written down.
  • Lasting predictability comes from cutting recurring support effort: knowledge capture, root-cause fixes, repeatable diagnostics, and human-validated AI assistance.

Why does a clear hourly rate still produce an uncertain support budget?

Because legacy support budgets mix two kinds of work. Planned work, such as security patches, scheduled maintenance, and agreed enhancements, can be scoped and estimated. Reactive work costs whatever investigation, escalation, and resolution take once an incident occurs.

Four factors drive the reactive portion, and none of them appear on a rate card:

  • Incident volume. A system that fails weekly costs more to support than one that fails quarterly, at any hourly rate.
  • Resolution time. Failures in poorly documented systems take longer to diagnose, so each incident bills more hours.
  • Escalation rate. When system knowledge sits with a few specialists, tickets go to the most expensive engineers in the pool.
  • Undocumented dependencies. A small fix can expose hidden integrations and turn a routine change into weeks of investigation.

The Core Tension

The CFO sees a known price per hour multiplied by an unknown number of hours.

Time and materials or fixed fee: who carries the risk?

The two models differ less in the price of an hour than in who absorbs the variability around it.

TIME AND MATERIALS FIXED FEE
What is priced Effort (hours worked) An agreed scope of service
Who carries demand risk Mostly the client The provider, within scope; the client, outside it
What happens when incidents spike Extra hours flow to the invoice Provider absorbs the effort up to the agreed volume threshold
Provider’s incentive to fix root causes Weak by default; fewer incidents mean fewer billable hours Strong; recurring incidents consume the provider’s margin
When it costs the client more When incident volume is high or unstable When incident volume stays below the provider’s assumptions
What to check in the contract Caps, not-to-exceed limits, improvement commitments Scope, exclusions, volume thresholds, renewal terms

Neither model is inherently cheaper. With a fixed fee, the provider prices in a margin for uncertainty, so the client pays for predictability as well as service. If your incident profile is stable and well measured, T&M may cost less. If it is volatile, a well-scoped fixed fee caps your exposure. Either way, the scope definition matters more than the headline number.

What does an unstable support baseline cost the business?

It costs capital, budget flexibility, and the ability to compare investments fairly.

Larger contingency reserves. When quarterly support spend swings [insert observed range, e.g., ±X% across N client engagements], finance either holds a bigger IT reserve or covers overruns from other budgets. Both tie up money that could go elsewhere.

A self-reinforcing budget squeeze. Support overruns defer the investments meant to reduce future support demand. Underinvested systems degrade, degradation raises support costs, and rising costs crowd out remediation. The pattern is documented at scale in U.S. federal IT:

~80%

Share of the U.S. federal government's $100+ billion annual IT budget spent on operating and maintaining existing systems, including legacy systems.

Source: U.S. GAO, GAO-23-106821

GAO also found that this share grew over seven fiscal years while development spending fell.

Distorted business cases. A modernization proposal competes against a support baseline whose true cost is unknown. Credible business cases can still use ranges and scenarios. But a baseline that omits likely incident costs makes continued support look cheaper than it is.

What makes a fixed fee actually predictable?

A fixed fee is predictable only when the contract states what it covers and what can change it. Check these seven terms before treating a flat monthly figure as a known cost.

CONTRACT TERM WHAT TO VERIFY RED FLAG
Scope Which applications, environments, and services are covered: defect resolution only, or also monitoring, minor enhancements, vendor coordination “Support for the platform” with no application list
Service levels Response and resolution commitments, plus remedies when missed A fee with no service commitments
Incident coverage Whether major incidents, security events, and outages are included Only “standard” incidents covered
Exclusions Third-party licensing, infrastructure, adjacent systems, changes caused by other vendors Exclusions defined loosely or not at all
Change requests How out-of-scope work is priced and approved Open-ended change requests billed at T&M rates
Volume assumptions The incident baseline and what happens above it (threshold, re-rating, renegotiation) No stated baseline
Renewal terms How the fee adjusts at renewal and which data drives it Adjustment at the provider’s discretion

 

Ask the provider for a written list of every price-adjustment trigger and the approval process for each. Use those triggers to model total spend under three scenarios: normal demand, incident volume 20% above baseline, and one major incident. If those totals diverge widely, the base fee alone tells you little.

How can engineering reduce support variability?

Contracts decide who pays for variability; engineering reduces how much of it there is. Four practices target the drivers listed above.

  • Knowledge capture targets resolution time and escalations. Documenting architecture, business rules, and dependencies as part of everyday tickets, not as a separate project, cuts repeat investigation and reliance on a few specialists.
  • Root-cause fixes target incident volume. Treating repeat incidents as candidates for permanent fixes, a practice ITIL calls problem management, removes future tickets rather than resolving them again.
  • Repeatable diagnostics target escalations. When investigation steps live in runbooks and automated checks, junior engineers can resolve what once required a specialist.
  • AI-assisted analysis targets undocumented dependencies. AI reads legacy code and drafts specifications quickly; engineers validate them before anyone relies on them.

How does our support model apply these practices?

We run, maintain, and support applications that cannot yet be modernized. Our service covers four elements: support and maintenance, knowledge capture, service accountability, and modernization readiness.

AI with human review. Our VELOX platform connects AI agents to a system’s code, ticket history, and documentation. It drafts requirements and specifications from legacy modules, including business rules, edge cases, and data assumptions buried in the code. Business analysts and subject-matter experts validate the output, architects check it for completeness, and QA specialists own the testing strategy. Specification review and regression testing are mandatory checkpoints.

Modernization readiness. Every supported application is assessed for business criticality, technology constraints, economic exposure, and change readiness, as described in the first article of this series. This keeps critical systems running while preserving a defined path to modernization, replacement, consolidation, or retirement.

Why Undocumented Knowledge Drives Variance

In a legacy reporting migration, the logic behind a set of production reports existed only in undocumented Java. Scope grew from a handful of known reports to more than 20, drawing on roughly 40 source tables, as dependencies surfaced one at a time over months. Under T&M, that discovery lands on the client’s invoice; under a fixed fee, it lands on the provider’s margin. Capturing the logic once means neither party pays for it again.

The commercial terms (price, coverage, and adjustment triggers) are set per agreement, which is why the questions below matter more than the model’s label.

What should you ask before renewing a legacy support agreement?

Five questions expose most of the variance a contract hides.

  • What spending is covered? Map every recurring cost for the supported systems against the agreement: support hours, emergency callouts, specialist escalations, licensing, infrastructure. Anything unassigned is where the next overrun will come from.
  • What can change the price? Get the full written list: incident thresholds, change-request rates, renewal adjustments, currency and rate assumptions. A short, specific, contractually fixed list means the fee is real.
  • Who owns recurring-problem resolution? Identify which party benefits financially when a repeat incident is fixed permanently, and whether the contract commits to reducing recurrence with incident data to prove it.
  • How is system knowledge retained? Confirm what documentation, runbooks, and validated specifications exist, who maintains them, and who keeps them if the provider changes.
  • How will predictability be measured? Agree on reporting in advance: incident volume and trend, resolution time, escalation rate, reopened tickets, and actual spend versus forecast, including out-of-scope charges.

The Bottom Line

A CFO needs a defined total cost exposure, a clear service commitment, and a mechanism for reducing recurring effort. A fixed price is valuable only when the contract makes all three explicit.

 

FAQ

Can time-and-materials support be budgeted at all?

Yes, historical incident data, ranges, and scenario planning can produce credible T&M budgets. Note that uncapped T&M does not itself limit total expenditure, though agreements can include caps or not-to-exceed provisions. What a basic T&M structure leaves with the client is the demand risk: if incidents spike, the budget moves.

Is a fixed fee cheaper than hourly support?

Not necessarily. A fixed fee is a risk allocation, not a discount. It is worth paying for when scope, service levels, and volume assumptions are explicit, and when the provider has a delivery approach that genuinely reduces recurring effort.

How does AI affect legacy support costs?

AI-assisted analysis accelerates discovery, documentation, and specification of legacy behavior, which can reduce investigation effort and rework where the output is validated by engineers. It does not, by itself, make any commercial arrangement sustainable, scope and service commitments still do that.

What's the first thing to review in a fixed-fee proposal?

The exclusions and volume assumptions. Review total expenditure, including variable charges, change requests, and renewal adjustments, rather than the base fee alone.

Do more with KMS. Get in touch to discuss your project needs.

TAGS

Written by

Kaja Grzybowska