The Cost of Maintaining Legacy Systems: A Worked Comparison

Compare the cost of maintaining a legacy system with the complete cost of changing it over the same period. Include ongoing support, internal work and transition costs. A lower future hosting bill alone does not establish that a replacement is worthwhile.

This guide builds a planning comparison for a fictional distributor's order-approval portal. Every amount is an invented input in USD, not an industry benchmark, a Nomadic Soft quote or an actual customer's result. The model combines cash expenses with allocated internal effort, so its reductions must not all be described as cash savings.

Start with a cost ledger you can trace

Choose a recent period that represents how the system operates. Record unusual incidents separately and note seasonal workloads. Use supplier invoices, service subscriptions, time records, support tickets and release histories rather than assigning a percentage to “technical debt.”

For each entry, record the activity, amount or hours, period, source, responsible owner and treatment. Mark it as observed, estimated or assumed. An invoice documents a charge; it does not establish how much staff time a future redesign will save. A target estimate should remain distinguishable from a measured current cost.

Separate cash expenses, such as a supplier invoice, from the value assigned to existing employees' time. Use a consistent internal allocation method across both options. If a change frees staff to do other work without changing payroll, that is released capacity rather than an immediate reduction in cash expenditure.

Avoid counting the same work twice

Separate routine review, manual operational work, incident response and project implementation. If someone spends an hour investigating an incident, record that hour once. Do not also count it as ordinary maintenance time unless the totals are adjusted to remove the overlap.

Elapsed recovery time is not the same as labor. A service can be unavailable while a team waits for a provider, or several people can work during the same interval. Record each person's actual effort separately from service unavailability and customer impact.

Keep uncertain business impacts visible without automatically adding them to the cost total. A delayed order may complete later. Lost revenue and lost profit describe different measures and must not be added as if they were independent losses. If the available evidence cannot support a monetary estimate, report the affected orders or hours separately.

Define the same service on both sides

In our example, the distributor's portal lets staff submit orders, routes them for approval and records the outcome before handover to fulfillment. The business needs those capabilities to continue while part of the implementation changes.

The comparison retains the same users, transaction workload and required workflow. It does not fund a new mobile app, additional business units or a redesigned sales operation. If the proposed change adds capabilities, show their costs and benefits separately rather than treating them as maintenance savings.

Keeping the current system is also a decision with assumptions: it must remain operable for the chosen horizon, with the maintenance work included below. Required upgrades or expiring dependencies must be reflected if they apply. Our legacy system modernization guide covers how to define a bounded change; the brownfield development guide covers working within an existing application.

Build the monthly baseline and target

The following amounts are hypothetical recurring costs. The target column assumes the change is accepted and the old components can be retired. It is not an observed result. Routine internal review and manual work are separate activities, with no overlapping hours.

The modeled reduction is $2,300 per month after the transition. Of that, $1,000 comes from the supplier and hosting/license categories; $1,300 comes from internal effort. Even the supplier reduction depends on actually changing the support arrangement. Reducing expected tickets does not automatically reduce a fixed invoice.

Include implementation, migration and temporary overlap

Assume implementation costs $36,000 and migration and handover cost $5,400. Their combined one-off amount is $41,400. The estimate must identify included project work and avoid counting the same implementation or review time again in recurring operations.

For the first six months, the distributor continues incurring the full $5,600 monthly current-system cost. The $3,300 target cost begins in month seven. Extra temporary parallel resources cost $900 per month for three months within that initial six-month period, adding $2,700.

The extra $900 is the model's incremental parallel-resource allowance. We do not add another full $3,300 monthly target-service charge during transition. If a real project requires both complete operating setups, replace this assumption with their actual non-overlapping costs. Migration rehearsal, data reconciliation, training and recovery work must also be covered by the estimate rather than disappearing between categories.

Microsoft's Strangler Fig guidance describes replacing functionality incrementally while the existing application continues operating, and highlights temporary infrastructure costs. For a real estimate, identify any routing layer, synchronization or other transitional component that must be built and operated. Give each an owner and a retirement condition; temporary work does not become cost-free because it is absent from the final architecture.

The model includes all $41,400 of one-off work and the $2,700 overlap allowance within each comparison horizon. It does not discount future amounts or include tax or inflation. It compares total modeled cost, not monthly cash flow or an accounting treatment.

Compare 24 and 36 months

At 24 months, keeping the system costs 24 × $5,600 = $134,400. Changing it costs $41,400 + $2,700 + 6 × $5,600 + 18 × $3,300 = $137,100.

At 36 months, keeping it costs 36 × $5,600 = $201,600. Changing it costs $41,400 + $2,700 + 6 × $5,600 + 30 × $3,300 = $176,700.

The longer horizon gives the target operating cost more time to offset the transition expense. It also assumes the target costs and workload remain valid for longer. The table does not prove that modernization will save a particular amount; it shows what follows from these inputs.

Test a three-month delay

Now assume target operation starts in month ten instead of month seven. The old system runs for nine months. Keep the same $41,400 one-off estimate and the same three months of extra $900 resources; this particular sensitivity does not assume those resources run for six months.

The delay replaces three target months with three current-system months: 3 × ($5,600 − $3,300) = $6,900 of additional modeled cost at either horizon.

A real delay may also extend parallel resources or implementation effort. Add those separately if they apply. This single-variable comparison isolates the effect of postponing the lower operating cost; it is not a worst-case forecast.

Use evidence to challenge the target

Identify what must happen for each target reduction: a support agreement changes, a resource is decommissioned, a review task takes less effort or manual re-entry ends. Name an owner and a measurement for each. Keep recurring benefits conditional until the changed workflow is accepted and used.

Track incidents and blocked changes without inventing a universal failure rate for older software. Record the requested change, reason it was blocked, work already attempted and consequence. That can support a technical or operational decision even when the consequence cannot be priced credibly.

Use the legacy modernization workbook to replace these invented inputs with your own ledger and assumptions. Compare options over the same horizon, keep cash and internal capacity visible, and update the model after discovery or migration rehearsals expose new work.

Our custom software development service starts with the existing workflow, constraints and a bounded delivery scope. A traceable baseline and explicit transition assumptions give that discussion a more useful starting point than the age of the code alone.