The rip-and-replace instinct
When a system is slow, difficult to integrate, or staffed by a shrinking pool of people who understand it, the instinct is to replace it. The logic feels sound: the new system will be faster, more maintainable, and easier to connect to modern tooling. In practice, large-scale system replacements are among the most reliably expensive and overrun project types in enterprise IT.
The Standish Group's CHAOS report has tracked enterprise software projects for three decades. Large replacements consistently show schedule overruns of 50-200% and budget overruns in the same range. The reasons are structural: full replacements require capturing every edge case the old system handles — and most organisations do not have complete documentation of what the old system actually does. That knowledge is embedded in code, in the heads of long-tenured staff, and in the behaviour of downstream systems that depend on it.
What legacy systems are actually good at
Legacy systems have typically been running core processes for ten to thirty years. That longevity is not accidental. They handle edge cases that were discovered through operational experience, often without those cases being explicitly documented. They have been tuned for reliability on specific hardware and network configurations. And they carry institutional knowledge encoded in business logic that no requirements document fully captures.
The problem is rarely that the system cannot do its job. The problem is that it cannot be easily queried, integrated, or extended. Data is locked in formats that modern applications cannot consume. Interfaces are batch-oriented when real-time is now required. Reporting requires manual export and transformation. These are integration problems, not fundamental system failures.
The additive layer model
An additive AI layer treats the legacy system as a stable data source and process engine, then builds modern capabilities on top of it. API wrappers expose legacy data to modern applications without touching the core system. ETL pipelines pull structured data into a modern data warehouse where AI and analytics can operate on it. AI models can be trained on historical data from the legacy system and deployed alongside it, with outputs fed back through controlled interfaces.
This approach preserves everything the legacy system does well while extending it with capabilities it cannot provide natively. It is also reversible. If the AI layer introduces errors or instability, it can be disabled without affecting the core system. A full replacement cannot be rolled back in the same way.
When replacement is genuinely the right call
Replacement is appropriate when the legacy system is preventing a core capability that cannot be added through integration — not just when integration is inconvenient. Specific triggers include: the system runs on hardware with no vendor support and no viable virtualisation path, the programming language or runtime has no available maintainers at any price, or the core data model is fundamentally incompatible with a regulatory requirement that has no workaround.
Even in those cases, the replacement strategy matters. Strangler Fig — gradually replacing components while keeping the old system live until the new one has proven itself at each stage — consistently outperforms big-bang cutovers. It reduces project risk, allows course correction, and maintains continuity for users and dependent systems throughout the migration.
The cost comparison that usually ends the debate
Model both approaches in the same spreadsheet. Full replacement: discovery and requirements, build, data migration, parallel running, training, cutover, and twelve months of post-launch stabilisation. Additive AI layer: API wrapper or ETL development, AI model build and training, deployment infrastructure, and ongoing model monitoring. In most mid-market enterprise contexts, the additive approach costs 20-40% of a full replacement and delivers a working system in a fraction of the time.
The organisations that benefit most from legacy modernisation are not the ones that commit to the largest replacement programmes. They are the ones that make the smallest change that closes the capability gap — and then build from there.