When an important software system starts to struggle, the explanation usually comes fast.
The code is too old. The architecture is outdated. The platform is legacy. The language is obsolete.
But after two decades working with enterprise software, I have learned to be careful with that diagnosis. Old technology is visible. It has a name, a version number, and a history. It gives people something concrete to point at, which makes it an easy target.
But the most dangerous debt in software is not always technical debt.
It is system stewardship debt.
Technical debt is the cost of earlier technical choices that make future change harder: shortcuts in code, architecture, design, testing, tooling, or integration.
System stewardship debt in this context is the accumulated cost of failing to actively care for systems, knowledge, and operational understanding over time. That includes the code, but it also includes the knowledge around the code: the people, training, documentation, operating discipline, judgment, and shared understanding of why the system works the way it does.
In most companies, stewardship debt does not build up because people are lazy or careless. It builds up because the incentives are wrong.
Companies reward new projects, visible launches, crisis response, and big transformation programs with big budgets and executive attention. They are often less consistent about rewarding the quieter work that keeps critical systems healthy: training the next person, documenting what actually happens, reducing key-person dependency, improving tools, closing security and compliance gaps, and making sure the business still understands the systems it depends on.
That is how system stewardship debt grows.
It is like owning a building and only paying attention when the lobby needs to be remodeled. The lobby matters, but so do the roof, wiring, plumbing, foundation, inspection records, and maintenance schedule. Those things are not exciting, but they determine whether the building is safe and useful over time.
If those things are neglected long enough, people eventually blame the building.
Software works the same way. The system may still be doing exactly what it was designed to do, but the organization’s ability to understand it, change it, operate it, and make good decisions about its future has deteriorated.
Enterprise systems do not become hard to manage overnight.
Training gets pushed off because there is always a deadline. Documentation falls behind because nobody is measured on whether it is accurate. Knowledge collects in the heads of a few senior people because they are the ones who can get things done quickly. Architecture decisions stop being actively made and start being inherited. Tooling investments get delayed because they do not look urgent. Teams spend more time reacting to problems than building the understanding that would prevent them.
Taken individually, most of these decisions look rational.
A customer needs something, a release has to go out, a deadline has to be met, a regulatory request lands, or a production issue takes priority. The person who knows the system best jumps in and fixes it because that is the fastest path.
The business rewards the heroics, but heroics are not a way to run a business.
Over time, the organization becomes dependent on a few people instead of shared understanding. Changes become harder to make with confidence. New engineers take too long to become productive. Experienced people leave, and important knowledge leaves with them.
At Instantiations, we have spent decades building the opposite outcome. The VAST Platform traces its roots to IBM VisualAge Smalltalk, first released in 1993. Since assuming stewardship of the platform in 2005, we have continued to evolve, extend, and modernize it through ongoing research and development rather than treating age alone as a reason for replacement.
Today, VAST supports modern cloud, desktop, server, and IoT deployment models while preserving the live programming methodologies and rapid iteration capabilities that made Smalltalk valuable in the first place. The platform's continued relevance is not the result of standing still. It is the result of sustained stewardship.
That distinction matters. Systems do not become liabilities simply because they have been around for a long time. More often, they become liabilities when organizations stop investing in the understanding and care required to evolve them.
Most executives already know that training matters, documentation matters, and key-person dependency is risky. The challenge is not awareness. It is incentives.
A new product launch gets attention. A platform replacement gets funding. A crisis gets executive visibility. The work that prevents the next crisis, however, often gets treated as overhead.
Nobody gets celebrated for improving onboarding, reducing operational risk, or making a system predictable and well understood.
But for systems that move money, support banks, process transactions, support compliance, or run critical operations, that kind of boring is exactly the goal.
Many companies say they value stability, but reward novelty. They say they want lower risk, but fund the things that look transformative. They say people are their greatest asset, but allow critical knowledge to sit with a handful of people for years.
That gap between what companies say they value and what they actually reward is where system stewardship debt grows.
The same pattern exists in the broader software market. Replacement stories are easier to fund than stewardship stories.
A startup that says it will replace an old platform with something new, faster, AI-native, cloud-native, or dramatically cheaper has a story people understand. It sounds like growth. It sounds like disruption. It sounds fundable.
A startup that says, “We are going to help you take better care of the critical systems you already depend on,” may be solving a more important problem, but it is not usually the pitch that makes a venture capitalist lean forward.
If all the capital, attention, and internal excitement point toward replacement, it becomes very easy to mistake movement for progress.
Once those incentives are in place, old software becomes the easiest thing to blame. It may use a language that is no longer fashionable. It may not look like the technology people would choose today. It may not fit the current story the company wants to tell about itself.
System stewardship debt is harder to see, and it requires a more honest conversation.
It is much less convicting to assess a problem at the technology level. Technology can be blamed from a distance. Stewardship cannot. Saying “the platform is old” is easier than saying “we stopped training people,” “we let knowledge concentrate in too few hands,” “we rewarded crisis response more than prevention,” or “we treated long-term ownership as overhead.”
That is why companies so often default to the technical diagnosis. It is not always wrong, but it is usually more comfortable.
Sometimes replacement really is the right answer. I am not arguing that every old system should be kept forever. That would be just as foolish as saying every old system should be replaced. The point is different. If age is the problem, replacement may solve it. If stewardship is the problem, replacement may just move the same problem into a newer system.
I have seen this pattern many times. A company decides that the legacy system is the problem, launches a major modernization program, spends a lot of money, and moves to a newer platform. For a while, everyone feels better.
But if the organization does not change how it owns, understands, documents, trains, and governs the new system, the same pattern starts again. A few years later, the new system becomes the system nobody understands.
That isn’t transformation. That is relocation.
Old software is not automatically a liability. Poorly stewarded software is.
Systems are sustained by people, not technology.
That sounds obvious, but it needs to be said, especially now. We are entering a period of agentic AI, coding assistants, virtual workers, and automation that can produce software faster than ever.
Those tools are powerful. We are investing in them too. But AI does not own the consequences when a system fails. People do.
Long-lived systems need teams that understand the code, the business process, the customer environment, the operational constraints, the security requirements, and the history of decisions made over many years.
Good engineering organizations treat that understanding as an asset. They do not view stewardship as a maintenance burden. They view it as a professional responsibility. Their teams know they are not just shipping features. They are taking care of something other people depend on.
That changes behavior. People teach each other, write things down, ask better questions, care about operational discipline, and make decisions with the next team in mind, not just the next deadline.
Most organizations assume stewardship problems begin with technology. In my experience, they begin earlier, in the habits and expectations that form around the system.
By the time the technology looks like the problem, the culture around the technology has often been breaking down for years.
AI raises the stakes.
I believe AI will be one of the most powerful tools software teams have ever had. It can help developers learn faster, diagnose problems faster, understand unfamiliar systems faster, and automate work that used to take much longer.
But AI is entering organizations that were already struggling with stewardship. Documentation was already drifting. Knowledge transfer was already weak. Teams were already operating systems they did not fully understand. Incentives were already pushing people toward speed and visible output instead of durable understanding.
AI did not create that problem, but it can accelerate it.
If AI helps teams understand systems better, it can be a major stewardship tool. But if AI is used mainly to produce more code faster, without improving the organization’s understanding of that code, system stewardship debt will grow faster too.
That is the danger. A company can wake up in a few years with more software than ever, more automation than ever, and less understanding than ever.
The best use of AI in enterprise software will not be limited to generating more code. The real opportunity is helping people understand systems more deeply: how they behave, how business rules flow through them, where risk is hiding, and what will happen if something changes.
But even there, AI is not a substitute for stewardship. It is a tool that can either support stewardship or hide the lack of it for a while.
If one senior engineer left tomorrow, what would we no longer understand?
Do we reward the people who prevent crises, or only the people who rescue us from them?
Can our team explain the most important business rules in the system, or only the code paths that implement them?
Are we funding stewardship with the same seriousness that we fund transformation?
Do we know where our key-person dependencies really are?
When we say a system is legacy, do we mean the technology has failed, or do we mean our understanding has failed?
Can we onboard new people into this system in months, or does it take years?
Are we measuring the health of the system, or only the speed of new delivery?
These are not just engineering questions. They are business questions, because when a company loses understanding of a system it depends on, it loses control.
The scarce resource in enterprise software is not code. It is understanding.
Code can be generated. Tools can be upgraded. Platforms can be replaced. Vendors can be changed. New architectures can be adopted. However, deep understanding of a critical system is hard to create and easy to lose.
That is why system stewardship matters.
The software industry spends a great deal of time celebrating what is new and dismissing what is old. Some of the most important systems in the world are not impressive because they were built recently. They are impressive because someone kept taking responsibility for them.
That is the real obligation of enterprise software leadership: not just to modernize what is old, not just to adopt what is new, but to create incentives that reward taking care of what matters.
System stewardship debt compounds whether or not it appears on a balance sheet.
The question is whether leaders will recognize the incentives creating it before the bill comes due.
