Keeping old systems running consumes most of the IT budget

The maintenance share

The US federal government publishes unusually detailed data on what it spends to keep existing systems running, and the Government Accountability Office has tracked it for more than a decade. Of the $79 billion agencies budgeted for IT in 2011, about 69 percent went to operations and maintenance.¹ By fiscal 2015 the share was about 75 percent.² GAO’s more recent work puts it at about 80 percent of annual federal IT spending of more than $100 billion.³

Federal agencies are an extreme case, but they are not unusual in kind. Any organization that has run the same core systems for decades faces the same arithmetic: every year of deferred replacement adds to the cost of the next.

Maintenance crowds out change

Budgets do not grow to absorb rising maintenance. GAO found that increased operations and maintenance spending over fiscal 2010 to 2017 coincided with a $7.3 billion decline in spending on development, modernization and enhancement.² The money to replace old systems was being spent keeping them alive.

The same report listed some of the oldest systems still in use. Several were more than 50 years old, written in assembly language or COBOL, and one ran on 1970s hardware that used 8-inch floppy disks.²

What makes a system legacy

Age alone is not the problem. Many old systems are reliable. A system becomes a liability when one or more of the following applies.

Unsupported platform

The operating system, runtime or hardware no longer receives security fixes, so risk rises every month without any change to the code.

Scarce skills

Few people can change it safely, and they are expensive or close to retirement.

Undocumented rules

Business rules exist only in the code. Nobody can say with confidence what the system does in every case.

Tight coupling

Other systems read its database directly, so any change to its structure breaks something elsewhere.

Locked data

Data can be extracted only through batch files or screens, which slows every project that needs it.

Why staged replacement

A full rewrite asks an organization to rebuild decades of undocumented behavior, then switch over in one step and hope nothing was missed. Staged replacement, sometimes called the strangler fig pattern, puts a stable interface in front of the old system and moves one capability at a time behind it, until the old system has nothing left to do.⁴

The test for each stage is simple: the new path produces the same results as the old one, on real data, before the old one is switched off.

The approach is slower to announce and faster to deliver value. Each stage is small enough to test against the old system’s output, and each one retires a piece of maintenance cost. If priorities change halfway through, what has been moved stays moved.

Five stages

1. 1Record what the system doesCapture inputs and outputs from production as characterization tests before changing anything.
2. 2Put an interface in frontRoute callers through an API or message layer so they stop depending on the old system’s internals.
3. 3Move one capabilityChoose a capability with clear boundaries and high maintenance cost, and rebuild it behind the interface.
4. 4Run both and compareProcess real transactions through old and new paths in parallel and reconcile every difference.
5. 5Retire with evidenceSwitch off the old path only when the comparison is clean, and record the maintenance cost removed.