KTLO in Legacy Systems: When Keeping the Lights On Costs More Than Modernization

The meeting had been on the calendar for six weeks. A Fortune 500 manufacturer, mid-sized by revenue but enormous by operational footprint, had gathered its CIO, its VP of Applications, three enterprise architects, and a finance director in a room to decide the fate of a single system: the order management platform that had been running, largely untouched at the architecture level, since 1998.

Nobody in the room wanted to be the one who said “just keep patching it.” That felt like admitting defeat. But nobody wanted to be the one who greenlit a rewrite either, because the last attempt — four years earlier, on a different system — had run 60% over budget and delivered half the promised functionality before being quietly shelved.

So the conversation didn’t start with technology. It started with a question that has quietly shaped more IT budgets than any architecture diagram ever has: how much are we already spending just to keep this thing alive, and what are we not doing because of it?

That question has a name in enterprise IT circles, and most people who use the term have never really sat with what it implies. The term is KTLO — Keep the Lights On. It sounds administrative, almost boring, like a line item buried in a budget appendix. It is, in fact, one of the most consequential and least understood forces shaping which companies modernize successfully and which ones spend a decade circling the drain.

This is not another article telling you legacy systems are bad and cloud-native architectures are good. It’s an attempt to explain why smart, well-resourced organizations keep choosing to fund the status quo — and why, in a surprising number of cases, that’s the correct call.

The Hidden Economy of Enterprise IT

Every enterprise runs two IT budgets, even if only one shows up as a line item. There’s the budget everyone talks about — the AI pilot, the cloud migration, the new customer portal. And there’s the budget nobody wants to discuss in the board meeting: the money spent simply making sure yesterday’s systems still work today.

Research from Gartner and Deloitte, cited repeatedly across recent IT budgeting studies, puts the second budget at somewhere between 55% and 80% of total enterprise IT spend, depending on industry and legacy footprint. A widely cited 2018 Deloitte survey found the average enterprise devotes 57% of its IT budget to running existing operations and only about 16% to innovation — and that the innovation spend that does happen is roughly a quarter less effective than it should be, precisely because it has to work around the constraints of the legacy estate. Government IT tells an even starker story: the U.S. Government Accountability Office has repeatedly found that federal agencies spend around 80% of technology budgets on operating and maintaining existing systems.

This is what economists studying platform businesses would recognize instantly as a tax — not a tax imposed by a government, but one imposed by decisions made ten, twenty, or thirty years ago by people who are mostly no longer at the company. Call it the innovation tax. Every new initiative, every AI pilot, every customer-facing feature has to first clear a toll booth built from decades of accumulated commitments: the batch job that has to finish before the new reporting layer can run, the undocumented business rule buried in an RPG program, the integration that only works because someone found a workaround in 2011 and nobody has touched it since.

The uncomfortable truth is that this tax isn’t a symptom of bad management. It’s closer to a law of physics for any organization old enough to have built real infrastructure. A twenty-year-old company has, by definition, twenty years of decisions layered on top of each other. The question was never about paying the innovation tax. It’s how consciously you manage it.

What KTLO Really Means

Ask ten IT leaders to define KTLO and most will give you some version of “maintaining the systems we already have.” That definition is true and almost useless, because it makes KTLO sound like a passive, low-stakes activity — something you do because you haven’t gotten around to replacing it yet.

Look closer at what actually falls under the KTLO umbrella at a large enterprise and a different picture emerges. It includes production support and incident response for systems that, if they go down, stop the business rather than merely inconveniencing it. It includes the steady stream of bug fixes and small enhancements that keep a twenty-year-old application usable by people who were in elementary school when it was built. It includes regulatory and compliance work — because a payroll system or a banking core doesn’t get to skip a tax law change just because the code is old. It includes infrastructure and security patching, user support, and, critically, the quiet, unglamorous work of retaining institutional knowledge before it walks out the door.

That last piece is the one most executives underestimate. KTLO is not really a maintenance function. It’s a risk management function wearing maintenance clothes. Every dollar spent keeping a core banking system, a manufacturing execution system, or a claims platform running is, functionally, a dollar spent preventing an outage, a compliance failure, or a business continuity crisis that would cost vastly more than the maintenance itself. The organizations that treat KTLO as an afterthought — a cost center to be squeezed every budget cycle — are the ones that eventually discover, at the worst possible moment, that the “boring” maintenance work was quietly carrying enormous operational risk.

This is exactly the discipline behind Programmers.io’s IBM i Modernization Services, which names KTLO directly as one of its core service lines alongside advisory, cloud migration, and staff augmentation — treating “keeping the lights on” as a managed, budgeted strategy rather than a default state a system falls into.

Why Legacy Systems Stay in KTLO

Return to that manufacturer’s boardroom. Why had this order management system survived, untouched at the core, for a quarter-century, while the company had modernized its website three times in the same period?

The honest answer has very little to do with the technology itself and everything to do with what the technology touches. The system was business-critical in the most literal sense: every order, every inventory adjustment, every shipment confirmation flowed through it. A modernization failure wouldn’t cause an inconvenient outage; it would stop trucks from leaving the warehouse.

Layered on top of that criticality was two decades of technical debt — not sloppy code, necessarily, but code written to solve problems that made sense in 1998 and have been patched, rather than reconsidered, ever since. Buried inside it was tribal knowledge: business rules that exist nowhere in any requirements document, understood only by three people, two of whom were eligible for retirement. The system connected to eleven other platforms through integrations built at different times, by different teams, using different conventions — any one of which could break in an unpredictable way if the core system changed shape.

Then there was the matter of regulatory exposure. Some of what the system did touched financial reporting, and finance doesn’t tolerate experimentation with anything that touches the general ledger. And underneath all of it sat the most human factor of all: fear. Nobody in that boardroom had personally broken a mission-critical system in front of the executive committee, and nobody wanted to be first.

This is not irrational behavior. It’s the accumulated, entirely reasonable output of business criticality, technical debt, tribal knowledge, integration complexity, regulatory weight, and organizational risk aversion, all reinforcing each other. Add budget constraints — because modernization competes for the same capital as revenue-generating initiatives — and you get an organization that keeps choosing, quarter after quarter, to fund KTLO instead of transformation. Not because anyone consciously decided legacy was a strategy. Because nobody could build a business case compelling enough to justify the risk of touching it.

The KTLO Trap

Here’s where the story usually turns dark, and where most articles about legacy systems stop — at the moment an organization gets stuck.

The mechanism is almost elegant in its cruelty. As a system ages, it accumulates more patches, each one a small workaround rather than a fix to the underlying design. Each patch increases the cost and risk of the next change, because there’s more surface area to break. As maintenance costs rise, less budget remains for anything resembling innovation, so the system falls further behind what the business actually needs, so more workarounds get built on top to bridge the gap, which increases maintenance costs further. Meanwhile, the engineers who understand the system’s real behavior — as opposed to what the documentation claims it does — are aging out of the workforce, and the ones who remain increasingly find themselves the sole custodians of knowledge that exists nowhere else, which makes them both irreplaceable and, eventually, a retention risk that keeps executives up at night.

One technology executive at Analog Devices summed up the moment of reckoning bluntly in comments reported this year: the company calculated what share of its investment would be needed just to keep existing systems alive, and the number came back in the low 80s — as a percentage. When eighty percent of the budget is committed to survival, twenty percent is left for everything else: new products, competitive differentiation, and the very modernization that would eventually break the cycle.

This is the KTLO trap, and it explains a pattern familiar to anyone who has worked inside a large, aging IT organization: technical debt compounds, agility declines, and the gap between what the business needs and what the systems can deliver widens every year, even though — and this is the part that confuses outside observers — nobody at the company is doing anything obviously wrong. Everyone is working hard. The budget is being spent responsibly on real, necessary work. The trap isn’t a failure of effort. It’s a failure of compounding math that nobody adequately priced in a decade earlier.

Maintaining legacy software is a lot like maintaining an aging bridge. Every year, engineers reinforce a beam here, resurface a section there, just enough to keep traffic flowing safely. No single year’s repair looks unreasonable. But the bridge was designed for the traffic loads of decades ago, and every year of patching narrows the gap between the cost of maintenance and the cost of building a new bridge outright — until, one year, maintenance costs more than replacement would have, and everyone wonders how they got there.

When KTLO Is Actually the Right Strategy

And yet — here is the point most modernization vendors would rather you not think too hard about — the trap is not universal. There are systems where continued, disciplined KTLO investment is not a failure of nerve. It’s the financially and operationally correct choice.

Consider IBM i (the platform long known as AS400). It has survived not because organizations were too timid to replace it, but because it does something genuinely difficult to replicate cheaply: it bundles an integrated relational database, a security model, and an operating system into a single, extraordinarily stable unit, purpose-built for exactly the kind of high-volume, must-not-fail transaction processing that manufacturing, distribution, and mid-market ERP workloads demand. The same logic applies to COBOL running on mainframes in banking, where a widely cited estimate puts roughly $3 trillion in daily financial transactions flowing through COBOL systems, and industry figures suggest the language still underpins the large majority of ATM transactions worldwide — the exact “must-not-fail” transaction profile addressed by Programmers.io’s IBM Z Mainframe Development Solutions. Payroll systems, healthcare claims platforms, banking cores, and government benefits systems share a common trait: they are boring, stable, extremely well-understood by the people who built them, and catastrophically expensive to get wrong if a rewrite introduces even a small defect into a process touching millions of transactions.

For these systems, the real question is not “modernize or don’t.” It’s “modernize what, exactly, and why.” A payroll engine that correctly calculates tax withholding across fifty jurisdictions doesn’t need a new architecture; it needs a modern interface, better observability, and an API layer so other systems can talk to it without touching the core logic. The core logic itself, battle-tested over decades against edge cases nobody remembers introducing, may be the single most valuable and least risky part of the entire estate — provided the organization actually invests in KTLO properly, rather than starving it.

This is the insight that gets lost in most modernization conversations: KTLO, done well, is not the absence of a strategy. It is a strategy — one that says, correctly, that some systems generate more business value by being reliably maintained than by being replaced, and that the money saved by not rewriting a working core system can be redirected toward the parts of the business where genuine competitive differentiation actually lives.

When Modernization Becomes Unavoidable

None of this means KTLO is a permanent state that any system can sustain indefinitely. Every legacy system eventually crosses a line, and the line rarely announces itself with a single dramatic failure. It shows up as a pattern of smaller signals that, taken individually, each seem manageable.

Maintenance costs that once tracked steadily with inflation start climbing faster than the business is growing, and finance starts asking uncomfortable questions about a budget line that used to be predictable. Security exposure that used to be theoretical becomes concrete, as vendors stop patching underlying components and compliance auditors start flagging the platform by name rather than by finding. The platform itself — an operating system version, a database engine, a piece of middleware — reaches the end of support, and the organization is quietly running production workloads on infrastructure no vendor will help them fix if something breaks.

Developer availability, discussed later in more detail, becomes a live operational risk rather than a talent-pipeline concern for HR to worry about someday. Integration bottlenecks multiply as the rest of the technology landscape moves toward APIs and event streams that the legacy core was never built to support, so every new digital initiative requires custom, expensive middleware just to have a conversation with the core system. Customers start noticing — a mobile app that can’t reflect real-time inventory because the backend only updates in a nightly batch job is a legacy problem wearing a customer-experience costume. Feature delivery slows to the point where competitors, unencumbered by the same technical debt, ship in weeks what takes the incumbent quarters. Cloud strategies stall because the core system’s architecture assumptions — mainframe batch cycles, tightly coupled monoliths, hardcoded on-premises dependencies — don’t map cleanly onto elastic, consumption-based infrastructure. And increasingly, in 2026, AI adoption itself becomes the forcing function: an organization cannot layer a modern AI assistant, a RAG pipeline, or an automated decisioning engine on top of a data layer it can’t safely query, integrate with, or trust.

None of these signals, individually, forces a rewrite. Together, appearing in the same system within the same eighteen-month window, they describe an organization that has quietly crossed from “managing legacy responsibly” into “managing legacy risk that is now larger than the cost of fixing it.” This is the point at which it’s worth reviewing Modernization Solutions, which covers re-engineering, microservices, and database modernization for exactly these warning signs — before the compounding costs described above make the decision instead of the organization.

The Economics of KTLO vs Modernization

The decision, when it finally gets made correctly, is almost never a technical one. It’s a financial one dressed in technical language.

Technical debt research consistently shows it consuming a significant share of IT spend in organizations with a substantial legacy footprint — some analyses put the figure as high as 40% of the IT budget in the worst cases, with McKinsey research suggesting that 10% to 20% of budget originally intended for new development gets quietly redirected to legacy-related firefighting instead. That redirection is the opportunity cost that rarely appears on a balance sheet: it’s not just what you spend on legacy, it’s what you didn’t build because the money and the engineering hours went somewhere else.

A useful mental model, borrowed from software maintenance benchmarking research, is to treat annual maintenance spend as a percentage of the original build cost. Healthy systems tend to run in the range of 15% to 25% of build cost per year in ongoing maintenance. When that figure creeps consistently above 25%, it’s a signal — not that the team is inefficient, but that the system has accumulated enough technical debt that continued patching is no longer the cheaper option. At that point, the comparison an executive actually needs isn’t “modernization cost versus zero” — its modernization cost versus the fully loaded, multi-year cost of continuing to patch a system whose maintenance bill keeps climbing, and whose risk profile keeps climbing with it.

This is also where the phased-modernization argument earns its keep. Recent industry analysis of legacy modernization programs suggests that a business-case-led, phased approach — fixing the highest-impact, highest-risk components first rather than attempting a full rewrite — can reach positive ROI in roughly twelve to fourteen months, compared with three to four years for a full system replacement, and with dramatically less execution risk. The economics rarely favor the dramatic, all-at-once rewrite that vendors like to pitch in a single slide. They favor the boring, sequenced, business-case-driven approach that treats modernization the way a good portfolio manager treats an investment portfolio: not everything gets sold at once, and not everything needs to be sold at all.

Legacy Knowledge Is Disappearing

Underneath every one of these financial calculations sits a workforce problem that no amount of budget can immediately solve, because the constraint isn’t money. It’s people, and specifically, the disappearance of a very particular kind of person.

The COBOL talent story has become almost a genre of its own in the trade press, and the numbers are worth taking seriously rather than treating as folklore. Surveys of IT professionals working with COBOL systems have found that roughly half report their COBOL staff averaging 45 years old or older, with a meaningful share reporting an average age above 55. Estimates of COBOL programmer attrition — through retirement alone — have run as high as 10% of the specialist workforce per year in some analyses; the shortage is severe enough that it’s a large part of why Programmers.io maintains a dedicated Hire COBOL Developers practice, rather than treating COBOL staffing as an afterthought of general development services. The RPG and IBM i community faces a structurally similar dynamic: a technology that remains deeply embedded in manufacturing, distribution, and mid-market ERP environments, supported by a shrinking, aging specialist base, even as demand for the platform’s underlying ERP workloads (Infor LX, System21, and similar) continues to grow — a trend documented in Programmers.io’s IBM i Ecosystem Insights 2026, which found strong demand for these ERP variants even as the specialists who support them become harder to find.

What makes this different from an ordinary skills shortage is what’s actually walking out the door. It is not simply the ability to write RPG or COBOL syntax — that, at least in principle, could be taught. What’s disappearing is the tacit, undocumented understanding of why a given piece of business logic exists: which edge case a 2004 patch was written to handle, which downstream system silently depends on a quirky data format, which “temporary” workaround from a systems migration a decade ago quietly became permanent load-bearing infrastructure. That knowledge rarely lives in a design document. It lives in the memory of the person who wrote it, and once that person retires, it is gone in a way that no amount of source-code archaeology can fully recover.

This is why institutional knowledge, in a very real sense, is often more valuable than the source code itself. Code can be read, however painfully. The reasoning behind the code — the business context that made a given decision correct at the time — often cannot be reverse-engineered at all. Organizations that treat knowledge transfer as a checkbox item, rather than an urgent, multi-year program, are quietly accumulating a form of risk that doesn’t show up in any dashboard until the day someone needs an answer that only one retired employee ever knew.

How Staff Augmentation Supports KTLO

This is where a practical, unglamorous but genuinely important tool enters the picture: experienced external teams brought in specifically to support the systems that internal hiring pipelines can no longer reliably staff.

The logic isn’t about outsourcing responsibility. It’s about closing a specific, well-defined gap. When an organization can’t hire enough RPG or COBOL specialists fast enough to keep pace with attrition, an experienced augmentation team — like the model behind Programmers.io’s IBM i Staff Augmentation and IT Staff Augmentation — can step in to maintain critical systems without a multi-year internal hiring ramp that the business timeline doesn’t allow for. When institutional knowledge is at risk of leaving with a retiring employee, a structured knowledge-capture engagement — pairing outside specialists with the departing expert for a defined transition period — can convert tacit understanding into documentation and trained capability before it’s lost, rather than after; Programmers.io’s COBOL modernization case study documents almost exactly this scenario, where knowledge concentrated in a small number of long-tenured specialists had to be captured and future-proofed before it walked out the door. When a modernization program is underway, augmented teams that have done similar migrations elsewhere can support the effort without requiring the organization to build a permanent bench for what is, in some cases, a finite project. And in the ordinary course of business, augmentation reduces the lag between “we have a business continuity gap” and “we have someone qualified handling it,” which matters enormously for systems where a gap in coverage is not a productivity problem but an operational risk.

The organizations that use this well don’t treat augmentation as a permanent substitute for owning their own systems. They treat it as a pressure valve — a way to buy time and stability while they make the more difficult, more strategic decisions about which systems to modernize, which to retire, and which to keep exactly as they are. Used that way, staff augmentation isn’t a hedge against having a real modernization strategy. It’s what makes it possible to build one without the current KTLO burden collapsing in the meantime.

A Modern CIO’s Decision Framework

Return, one more time, to that boardroom. The mistake most organizations make at this stage is asking the wrong question in the first place. “Should we modernize this system?” is a yes-or-no question forced onto a decision that was never binary.

The more useful framing, and the one that increasingly separates organizations that manage their legacy estate well from those that don’t, treats every application as a candidate for one of several distinct strategies, not a single verdict. Some systems should simply be maintained — funded properly, staffed deliberately, and left architecturally alone, because they work and the risk of touching them exceeds any plausible benefit. Some should be modernized incrementally: wrapped with APIs so the rest of the organization can integrate with them without anyone touching the core logic, refactored piece by piece to reduce the worst pockets of technical debt, or replatformed onto more sustainable infrastructure without rewriting the business logic itself. Some genuinely need to be rebuilt from the ground up, because the underlying platform or architecture has become a structural constraint rather than a maintenance inconvenience. And some should simply be retired — decommissioned, with their remaining function absorbed into other systems, because they’ve outlived any purpose beyond institutional inertia.

The organizations getting this right build what amounts to an application portfolio management discipline: a running, honestly maintained inventory of every significant system, scored not just on technical age but on business criticality, maintenance trend, talent risk, integration complexity, and strategic value. This is precisely the function of a structured discovery engagement like Programmers.io’s AI-Assisted Modernization Assessment, which turns that portfolio-scoring exercise into an actual roadmap rather than a one-time boardroom debate — and it’s worth comparing advisory-first frameworks like this against emerging AI-driven approaches, as laid out in TimeBridge™ vs. IBM Bob, when deciding how much of the assessment and modernization work to automate versus run through expert-led advisory. That portfolio view turns the “modernize or don’t” debate — the kind that consumed six weeks of a manufacturer’s calendar before a single decision got made — into an ongoing, much less dramatic process of continuous evaluation. Instead of one enormous, high-stakes bet made once every decade, the organization makes dozens of smaller, better-informed bets continuously, adjusting as systems, talent availability, and business priorities shift.

Conclusion

The manufacturer in that boardroom eventually made its decision, and it wasn’t the dramatic one. They kept the order management core largely as it was, invested properly in the KTLO budget that had been quietly starved for years, brought in specialized support to capture the knowledge of two engineers approaching retirement, and spent their transformation budget instead on an API layer that let a new mobile app and a new analytics platform talk to the old core without anyone touching the parts that actually processed orders correctly. It was not a headline-worthy modernization story. It was the correct one for that system, at that moment, given what the business actually needed.

That’s the real lesson underneath all of this. KTLO is not the opposite of innovation, and it’s not a failure to modernize. It is, when done deliberately, one of the most important investment decisions a CIO makes — a judgment about which parts of the business’s technology foundation deserve continued, careful stewardship, and which parts have genuinely outlived their usefulness. The organizations that struggle are not the ones that keep legacy systems running. They’re the ones that never consciously decided to — that let KTLO happen by default, underfunded and unexamined, until the compounding math of technical debt and disappearing institutional knowledge made the decision for them, at the worst possible time and the highest possible cost.

The goal was never to eliminate KTLO. The goal is to make sure that keeping the lights on doesn’t prevent your organization from building what comes next.

https://differ.blog/p/ktlo-in-legacy-systems-when-keeping-the-lights-on-costs-more-than-mod-af09c8