Every IT organisation has legacy systems. Applications that have been running for years, maybe decades. They work, sort of. They’re critical to business operations. They’re also expensive to maintain, difficult to integrate with modern tools, and often built on obsolete technology.

This year we confronted nine legacy systems that needed decisions. Retire and replace? Refactor and modernise? Leave alone and pray? Here’s how we approached each decision and what we learned about legacy system modernisation.

The Inventory

Our legacy portfolio included a fifteen-year-old customer service application, a homegrown inventory management system from the early 2000s, a financial reporting tool built on a database platform the vendor no longer supports, and six other systems of varying ages and criticality.

Some of these systems were business-critical. Others were used by small teams for niche purposes. Some had modern alternatives available. Others were so specific to our business that replacement meant custom development.

The easy answer would be to replace everything with modern SaaS alternatives. The reality is more complex and more expensive than that sounds.

Decision Framework

We needed a systematic way to evaluate each legacy system. We scored them across several dimensions.

Technical health: How stable is the system? How often does it break? How difficult is it to maintain? Systems that are technically fragile scored higher priority for action.

Business criticality: How important is this system to business operations? What happens if it fails? Critical systems needed more careful approaches than nice-to-have tools.

Replacement availability: Are there modern alternatives that meet the business need? Good replacement options made retirement more attractive. Niche functionality with no clear replacement forced us toward refactoring or acceptance.

Cost to maintain: How expensive is this system to keep running? Include licensing, infrastructure, staff time, and opportunity cost of skills tied up in legacy technology. High maintenance costs justified investment in modernisation.

Integration needs: How much does this system need to interact with other applications? Highly integrated systems are more complex and expensive to replace. Standalone systems are simpler.

System One: Customer Service Application (Retired)

This was our highest priority legacy system. Business-critical, technically fragile, expensive to maintain. The application ran on a proprietary platform. The vendor still existed but had stopped active development on this product line years ago.

We evaluated modern customer service platforms and found several that met our needs. The functionality was comparable or better than our legacy system. The integration capabilities were superior. The total cost of ownership was lower even including migration costs.

Decision: retire and replace. We selected a modern SaaS platform and ran a six-month migration project. It was disruptive and expensive, but the long-term benefits justified the investment. We’re now on a supported, actively developed platform with far lower maintenance costs.

System Two: Inventory Management (Refactored)

Our inventory management system was custom-built for our specific business processes. It worked well functionally but was built on outdated technology. Maintaining it required specialized skills that were increasingly difficult to hire.

We evaluated replacement options but found that commercial alternatives didn’t match our workflows without extensive customisation. Building a new system from scratch would be extremely expensive and risky.

Decision: refactor the existing system. We migrated the database to a modern platform, rewrote the user interface using current web technologies, and documented the business logic thoroughly. The core functionality stayed the same, but the technology stack became supportable.

This approach was less disruptive than replacement and preserved institutional knowledge embedded in the existing system. It wasn’t glamorous, but it was pragmatic.

System Three: Financial Reporting (Retired)

Our financial reporting tool was built on a database platform the vendor had discontinued. We were running an unsupported version with known security vulnerabilities. The system worked but was a disaster waiting to happen.

Replacement options were abundant. Modern business intelligence platforms offered comparable functionality with better integration and visualisation capabilities. The migration was mostly about rebuilding reports rather than complex data or process migration.

Decision: retire and replace with a modern BI platform. The project took four months and went smoothly. Users actually prefer the new tool because the visualisation capabilities are better. This was a clear win.

System Four Through Nine: Varied Approaches

The remaining systems got different treatments based on their specific situations.

Two systems were retired without replacement. They’d been built for business needs that no longer existed. Usage had declined to near zero. We decommissioned them and archived the data.

One system was left alone. It supported a niche process for a small team. Technically it was fine, just old. Replacement wasn’t justified by the limited usage. We accepted the technical debt and moved on.

Two systems are still under evaluation. The business need is clear, but we haven’t found good replacement options or built consensus on approach. Sometimes the right answer is to defer the decision until more information emerges.

The final system got a hybrid approach. We retired part of it by moving functionality to another platform, but kept the core application running because it had capabilities we couldn’t easily replicate.

What Made Decisions Hard

The technical assessment was usually straightforward. What made decisions difficult was understanding business needs accurately.

Users often can’t articulate what they actually need from a system versus what the current system happens to do. Replacing a legacy system requires understanding the essential business requirements separately from the specific implementation.

We spent months on requirements gathering for some systems only to discover that half the functionality was never used or was workarounds for limitations in the original design. Replacing unnecessary functionality is wasteful.

Political considerations complicated several decisions. Systems often have internal champions who resist change regardless of technical or business justification. Managing these stakeholders requires diplomacy and patience.

Cost Considerations

Every option costs money. Retirement means migration costs and new licensing. Refactoring means development costs. Even leaving systems alone has costs in ongoing maintenance and risk.

We built total cost of ownership models for each approach over a five-year time horizon. This helped make the costs and benefits comparable across options.

Retirement costs are front-loaded. High upfront investment, lower ongoing costs. Refactoring spreads costs over time with moderate upfront investment and moderate ongoing costs. Leaving systems alone has minimal upfront cost but higher ongoing costs and increasing risk.

The right choice depends on budget availability, risk tolerance, and strategic priorities. There’s no universal answer.

Lessons Learned

Start with business needs, not technology. Understanding what the business actually requires drives everything else. Don’t let current implementation constrain your thinking about requirements.

Retirement is often better than refactoring if good replacement options exist. Refactoring preserves technical debt even as you modernise the technology stack. Clean breaks are better when practical.

Refactoring makes sense when functionality is highly specific and replacement options don’t exist. Custom systems built for unique business processes often can’t be replaced with commercial alternatives.

Some systems should just be left alone. Not every piece of technical debt needs immediate attention. Focus resources on systems where modernisation delivers clear value.

Finally, be honest about organisational capacity. Modernisation projects are disruptive and resource-intensive. Don’t take on more than your organisation can execute well. Better to do fewer projects successfully than many projects poorly.

Looking Forward

Legacy system modernisation is ongoing work, not a one-time project. New systems become legacy systems. Technology evolves. Business needs change. This work never ends.

The goal isn’t to eliminate all legacy systems. That’s impossible. The goal is to manage technical debt intentionally, making conscious decisions about where to invest in modernisation and where to accept legacy technology.

We’ve made good progress this year. Several problem systems are resolved. Others have clear paths forward. Some remain in limbo, but that’s progress too. Understanding what we don’t know is valuable.

If you’re facing similar legacy system decisions, build a framework for evaluation rather than deciding case by case. Consistent criteria make better decisions and help justify those decisions to stakeholders. And be patient. This work takes years, not months.