There is a service your team calls 'the monstrosity.' It was written seven years ago by engineers who left. The documentation is a single README that says 'ask Dave,' and Dave left in 2023. It processes 40% of your revenue, nobody wants to touch it, and every change feels like defusing a bomb. You cannot rewrite it -- there is no budget and too much risk. You cannot ignore it -- it breaks every other week. You need a pragmatic plan for a problem that has no clean solution.
Assessing and Prioritising Legacy Risk
Not all legacy systems require the same level of attention. Some are stable, well-understood, and rarely need changes. Others are fragile, poorly documented, and critical to business operations. Assess each legacy system across multiple dimensions: business criticality, frequency of required changes, operational risk, and the availability of engineers who understand it.
Focus your attention on systems that are both business-critical and frequently changing. A legacy system that runs reliably and rarely needs modification is a lower priority than one that must be modified regularly but is fragile and poorly understood. The intersection of high change frequency and high fragility is where the greatest risk lies.
Document what you know about each legacy system's architecture, dependencies, and failure modes. This institutional knowledge is often held by a small number of engineers, and if they leave, the risk to the organisation increases dramatically. Knowledge documentation is an investment in resilience.
- Assess legacy systems across business criticality, change frequency, operational risk, and knowledge concentration
- Prioritise systems at the intersection of high change frequency and high fragility
- Document architecture, dependencies, and failure modes to reduce knowledge concentration risk
- Identify the engineers who hold critical knowledge and cross-train to reduce bus factor
Choosing a Modernisation Strategy
Full rewrite is rarely the right answer for legacy systems. Rewrites are expensive, take longer than expected, and must replicate years of accumulated business logic - much of which is undocumented and discovered only when the rewrite fails to handle edge cases that the old system handles correctly.
Incremental modernisation is usually more effective. Extract bounded components from the legacy system, wrap them behind well-defined interfaces, and modernise them one at a time. This approach delivers value incrementally, reduces risk, and maintains the system's functionality throughout the process.
Sometimes the right strategy is to stabilise rather than modernise. If the system works, changes are infrequent, and the cost of modernisation is high, investing in monitoring, documentation, and automated testing may be more valuable than rewriting. Not every legacy system needs to be modernised - some just need to be managed.
Maintaining Team Morale on Legacy Work
Working on legacy systems can be demoralising. Engineers may feel that they are missing out on modern technology, that their skills are stagnating, or that legacy work is less valued than greenfield development. Address these concerns proactively.
Frame legacy work as a challenging and valuable skill. Understanding complex, undocumented systems, making safe changes in fragile codebases, and modernising systems without downtime are advanced engineering skills that not everyone possesses. Recognise and celebrate these contributions.
Rotate engineers between legacy and greenfield work where possible. Extended periods of exclusively legacy work lead to burnout and attrition. Even if full rotation is not possible, allocate time for learning modern technologies, contributing to new projects, or running experiments with new approaches that could eventually benefit the legacy system.
Making the Business Case for Legacy Investment
Leadership often underestimates the risk of legacy systems until an incident occurs. Build the business case proactively by quantifying the costs: engineering time spent on manual processes, incident frequency and impact, the cost of delayed features due to legacy constraints, and the risk of key personnel departure.
Present options with clear trade-offs rather than a single proposal. Option A might be full modernisation over 18 months with significant feature delivery disruption. Option B might be incremental improvement with less disruption but a longer timeline. Option C might be stabilisation-only with ongoing operational costs. Let leadership choose based on the trade-offs they are willing to accept.
Track and report the ongoing cost of legacy systems to maintain visibility. Monthly reports on time spent on legacy maintenance, incidents caused by legacy systems, and features delayed or constrained by legacy technology keep the conversation alive and build the cumulative case for investment.
Key Takeaways
- Assess legacy risk across business criticality, change frequency, fragility, and knowledge concentration
- Prefer incremental modernisation over full rewrites - extract, wrap, and modernise bounded components
- Maintain team morale by framing legacy work as valuable, rotating engineers, and providing learning opportunities
- Build the business case with quantified costs and present options with clear trade-offs
- Document institutional knowledge to reduce the risk of critical knowledge leaving with individuals
Frequently Asked Questions
- When is a full rewrite justified for a legacy system?
- A full rewrite may be justified when the legacy system's technology is genuinely end-of-life with no migration path, when the system's architecture fundamentally prevents necessary changes, or when the domain is well-understood and the business logic can be reliably replicated. Even then, plan for the rewrite to take twice as long as estimated and maintain the old system until the new one is fully validated in production.
- How do I prevent new systems from becoming legacy themselves?
- Build systems with maintainability in mind from the start. Invest in documentation, automated testing, clean architecture, and dependency management. Keep dependencies updated through automated tools. Allocate regular capacity for refactoring and modernisation rather than waiting until the system becomes difficult to change. The key is continuous maintenance rather than periods of neglect followed by expensive modernisation.
- How do I handle a legacy system when the original developers have left?
- Start by building understanding through observation - read the code, trace request flows, review logs and monitoring, and map the system's dependencies. Add automated tests around the existing behaviour before making changes, so you can verify that changes do not break existing functionality. This approach is slower initially but builds the team's understanding and confidence incrementally.
Explore Legacy System Management Resources
Access my field guide for legacy system management, including modernisation decision frameworks, risk assessment templates, and team rotation planning tools.
Learn More