Technology and Power V — Legacy Systems and Institutional Lock-In

The technology an institution built its operations around becomes the constraint on what it can do next.

How Lock-In Forms

Technology lock-in — the condition in which an institution's operations have become sufficiently integrated with a specific technology system that migration to alternatives is prohibitively costly — forms through a process that is individually rational at each step and collectively irrational in aggregate. Each integration of the technology into operational processes creates a dependency. Each dependency raises the cost of migration. Over time, the accumulated dependencies produce a lock-in condition in which the technology that was chosen for its capabilities at the time of adoption is now maintained for its switching costs rather than its merits.

The lock-in is most complete in the cases where the adopted technology becomes the operational language of the institution — where the data formats, the process designs, and the institutional knowledge of how to perform core functions are all structured around the specific technology's architecture. Migrating from this condition requires not just replacing the technology but restructuring the operations, retraining the personnel, and converting the data formats that have been built around the prior technology's requirements.

The Cost Structure of Legacy Systems

Legacy systems — the technology infrastructure that has been maintained well past the point where its ongoing costs would, in hindsight, have justified replacement — carry a specific cost structure. That threshold is easier to identify in retrospect than to calculate in advance, which is part of why institutions cross it. Direct costs include the maintenance of systems that are no longer actively supported by vendors, the security risks that accumulate in unpatched systems, and the operational inefficiencies that outdated architecture produces. Indirect costs include the strategic constraints that legacy systems impose: the capabilities that cannot be built because the underlying infrastructure does not support them, and the integrations that cannot be achieved because the legacy architecture is incompatible. A further indirect cost, widely reported across engineering organizations, is talent attrition: skilled practitioners increasingly avoid institutions whose technical debt forces them to work against outdated systems rather than build on modern ones.

Managing the Transition

Institutions that manage legacy system transitions most effectively do so through a deliberate sequencing strategy that reduces migration risk while progressively reducing the legacy system's scope. One such approach, the strangler fig pattern — a term coined by software architect Martin Fowler for the practice of building new capability alongside a legacy system and incrementally routing functions to it rather than replacing the legacy system outright — reduces transition risk by maintaining operational continuity while progressively shifting functions to the new architecture. The pattern is not universally applicable, and its record is one of design practice rather than controlled evidence, but its logic — that a system need not be stopped to be replaced — is the same logic that governs institutional migration more broadly. The key discipline is committing to the migration before the legacy system's accumulated technical debt has made operation critically fragile, which requires making the investment before the urgency is maximum and the options are minimum.

The legacy system is the institution's technological history made operational. It represents every decision not to migrate, compounded into a constraint that is now more expensive to address than any of those individual decisions would have been. The institution that manages technology debt proactively pays a fraction of the cost that the institution that allows it to accumulate eventually bears.