IT Legacy in Practice

From crown jewel to millstone

Many systems that are technically outdated are still in use. Often at high cost, with significant risks and mounting frustration. And yet, few dare to let go. What if the replacement fails? What if critical knowledge is lost? And how do you build a business case for a replacement that offers little to no functional gain?

That’s precisely what makes legacy one of the most persistent challenges in the boardroom. The good news: there is a way forward for existing and potentially future legacy. But it requires courage, patience and a clear roadmap. Here’s a starting point.

It’s tempting to stick with what you know. The systems may be clunky and outdated, but they work. Everyone knows where the buttons are and what the limitations are. It feels safe. But that safety is deceptive. Risks are growing: security vulnerabilities that can no longer be patched, escalating licence costs, and specialists heading into retirement. The longer you wait, the more exposed you become.

A common pitfall is the sunk cost fallacy: the tendency to defend past investments. Millions may have been poured into the system, so letting go feels like throwing away value. But those costs are already sunk and won’t come back. Holding on often leads organisations to migrate everything one-to-one—including redundant features, outdated processes and design flaws. The result? An expensive replica of the past, wrapped in modern technology—functional legacy.

What helps?

Make it tangible: map out what it costs to keep your legacy running: in money, risk and missed opportunities. Then ask: what do we truly need to move our organisation forward? Often, that’s when it becomes clear that “just keeping things going” is more costly and dangerous than renewal.

Signs you’re relying too heavily on legacy

• Your vendor no longer supports the software.
• Only a handful of people understand how the system works.
• Job postings for legacy roles receive no response—it’s unfamiliar territory.
• New colleagues struggle to get to grips with the system.
• Integration with modern tools (APIs, cloud, SSO) is nearly impossible.
• Changes take weeks or simply can’t be implemented.
• You increasingly hear: “the system can’t do that.”
• Standard software: off-the-shelf packages for business processes (e.g. SAP R/3 or older, Microsoft Navision, Oracle E-Business Suite 10, WordPerfect).
• Custom software: developed in-house or commissioned; often tightly woven into specific processes.
• Platforms, tools & infrastructure: underlying technologies and frameworks (e.g. Windows NT, Internet Explorer, COBOL, AngularJS, MS Access, Java Applets, dBASE IV).

Types of legacy (briefly)

The type of legacy determines its impact on operations. A legacy ERP system or outdated database, for instance, has far greater business implications than obsolete support software. Something to keep in mind.

This may be the hardest lesson. Every organisation has features or processes that were once valuable but now mainly get in the way.

You’ll often hear: “We’ve always done it this way.” Or: “We’ve used that functionality for twenty years, it has to stay.” Many organisations don’t even realise they’re dealing with legacy. The system seems to work fine, while processes are inefficient and risks only surface when no one knows how the system actually functions. Many of these darlings are best left behind. The more you carry over to a new system, the more complex, costly and risky your migration becomes.

What helps?

Talk to end users. Ask what they need and actually use. You’ll be surprised how much is redundant. See migration as an opportunity to clean up your data, your processes and your application landscape.

Killing your darlings in practice

• Consolidate agreements and definitions: work with one set of core processes instead of ten variations.
• Don’t seek differentiation in luxury systems: that’s not what you’re judged on. Accept standard approaches for generic processes.
• Archive old data smartly, rather than migrating everything.
• Focus on business value: any feature that doesn’t demonstrably add value should go.
• Build a reserve: include all systems in your accounting and depreciate annually, so you create a financial buffer for future replacements—just as you would with machinery or capital-intensive installations.

A big bang migration may sound appealing (“done in one go!”), but in practice it’s rarely feasible. The risks are enormous, and the shop needs to stay open in the meantime.

A smarter approach: take it step by step. Use the strangler pattern: build new functionality alongside the old system and gradually shift more processes over. This way, you stay in control and can adjust course when needed.

What helps?

• Start with a target architecture: a clear vision of where you’re heading.
• First build an integration layer, then gradually adopt new modules. For instance, begin with the recruitment process before replacing the entire HR system.
• Make ownership explicit: legacy often arises from a lack of responsibility for lifecycle management. Make sure that’s properly addressed this time.

The biggest mistake you can make is building new legacy. And it happens faster than you think. Without clear choices, you end up with custom solutions, dependencies and technical debt all over again.

What helps?

Be explicit in your design principles and architectural decisions. Decide which systems to buy, what to build in-house, and how to standardise technology and data integration. Document, safeguard and periodically review all decisions. And always start with the end in mind: how long do we want this system to run? And how do we ensure it remains flexible and valuable over that period?

Avoid creating new legacy

• Document every architectural decision.
• Use open standards.
• Establish ownership from day one.
• Plan the exit strategy from the start.
• Any system that lasts long enough will eventually become legacy. The trick isn’t to avoid it, but to manage it consciously.
• That way, legacy becomes not a millstone, but simply a stepping stone towards the future.