The Legacy Software Migration Nobody Wants to Talk About
Every enterprise IT organization is running software it should have replaced years ago. The system is old enough that the vendor who originally built it may no longer exist. The employees who know how it works are approaching retirement or have already left. The documentation, if it ever existed, is incomplete or missing. The integration with everything else in the technology stack was built on assumptions that have since changed. The system runs critical business processes that the organization cannot operate without.
The legacy system problem is not primarily a technical problem. If it were, it would be solved more frequently. It is an organizational problem: the risk of migration is visible and attributable, while the risk of not migrating accumulates slowly and invisibly until something forces the conversation.
Why Legacy Systems Persist
The calculus that keeps legacy systems in production is straightforward from the perspective of any individual decision-maker. The system works, in the sense that business processes depending on it continue to function. Replacing it requires budget, time, organizational attention, and a migration risk that the decision-maker will be responsible for if it goes wrong. Not replacing it requires none of these things. The risk of deferral — the accumulating security exposure, the increasing difficulty of finding people who can maintain it, the growing incompatibility with modern integrations — is diffuse and falls on the organization rather than on the individual who made the deferral decision.
This incentive structure produces rational individual decisions that accumulate into organizational irrationality. Each year the migration is deferred, the migration becomes more difficult. The integration surface area grows as more systems build dependencies on the legacy system. The knowledge base of people who understand the legacy system shrinks as retirements and departures occur. The technical debt compounds.
The Knowledge Concentration Risk
The most underappreciated risk in legacy system maintenance is knowledge concentration: the accumulation of critical operational knowledge in a small number of individuals who understand the system deeply enough to maintain it. When those individuals leave — through retirement, resignation, or sudden incapacitation — the organization loses operational capability that was never documented because documentation was never prioritized.
The COBOL programmer shortage that periodically appears in headlines reflects this dynamic at the infrastructure level. State government systems running COBOL mainframe applications have a shrinking pool of people who can maintain them. The organizations that have deferred mainframe modernization are in direct competition with each other for a diminishing supply of qualified maintainers. The competition is expensive and increasingly unwinnable.
The knowledge concentration risk is not limited to COBOL. Any system where deep operational knowledge is held by two or three individuals who are not being replaced by new hires learning the same systems is accumulating knowledge concentration risk. The organization that identifies these concentrations and addresses them — through documentation projects, cross-training programs, or accelerated migration timelines — is managing a risk that most organizations discover only when it materializes as an incident.
The Migration That Works
Successful legacy migrations share characteristics that distinguish them from the projects that fail or stall. They define success in terms of business capability transfer rather than technical architecture replacement. They begin with the parts of the legacy system that are most independent — the functions with the fewest integration dependencies — and work toward the core. They maintain the legacy system and the replacement in parallel for a defined period rather than attempting a cutover that requires everything to be right simultaneously.
They also secure organizational commitment that survives the inevitable mid-project difficulty. Legacy migrations encounter unexpected complexity. Undocumented business logic that the legacy system has been implementing for fifteen years is discovered when the new system does not replicate its behavior. Integration dependencies that were not in the original scope emerge during implementation. The projects that survive this difficulty are those with executive sponsorship that was committed to the outcome, not just the initiation.
The system that should have been replaced three years ago was worth replacing then. It is more expensive to replace now. It will be more expensive still in three more years. The deferral decision has a cost that accrues continuously. It is not free money.