Continuous modernisation vs legacy displacement

While new product initiatives offer a way to introduce new technology to support business model innovation and displace older systems over time, most organisations are missing the opportunity to continuously modernise older systems as part of existing product evolution.

(Above illustration from Planview ‘The 2024 Project to Product State of the Industry Report’)

Analysis of over 8,000 global value streams reveals that 65% of organisations are underfunding technical debt. This underfunding occurs due to debt neglect or the organisation’s lack of clear visibility into its investment allocation.

This journey isn’t merely about replacing old technology with new; it’s about improving how teams deliver value to customers while maintaining business continuity.

This challenge isn’t limited to traditional enterprises with decades-old systems. Even high-growth startups find their portfolios rapidly becoming constrained by debt, demonstrating how quickly it accumulates in any organisation. The negative effects on business outcomes are significant and manifold – concept-to-cash cycles become prolonged, quality suffers, systems struggle to adopt new technologies or meet changing compliance requirements, security vulnerabilities appear, deployment becomes a complex operation rather than a routine task and scaling becomes increasingly difficult.

Without conscious technical debt management, teams risk devolving into ‘feature factories’ building upon outdated code. The impact of technical debt extends beyond the product itself and affects the human element of development. It can lead to reduced developer productivity and morale, as teams struggle with the challenges of working within constrained, outdated systems. The accumulation of technical debt in legacy systems creates complexity that hinders getting new product ideas off the ground and slows product enhancements for existing products.

Debt may occur at the code level, for example with long methods and functions, poor naming conventions, deep nesting and poor dependency management. Debt may also occur at the architectural level, for example when services are tightly coupled and cannot be independently deployed or when services become organised around technical concepts rather than business domain concepts leading to unnecessary dependencies.

Sometimes architectural shortcuts are taken where a new component is bolted on rather than reorganising existing services to reflect the new business domain. Over time, this creates an ‘onion’ effect, where each shortcut adds a layer to the system architecture, increasing complexity and slowing delivery. What was a simple interaction turns into a multi-hop chain of requests with multiple teams becoming involved in a simple change that ripples through the layers.

Over time, organisational structures become oriented around architectural debt rather than around value from a customer’s perspective. Over time, new features require coordination across multiple layers and teams to deliver value, creating dependencies, rework and high coordination costs. Change becomes increasingly slow, complex and risky. Effectively, you end up ‘shipping your org chart’, which is the product of poorly managed debt at the code and architectural levels.

Over time, systems become so complex that organisations can no longer see how work flows through them. Internal conversations about the state of the delivery system often fail to reflect customers’ reality and there’s an absence of common metrics allowing everyone to gain a shared understanding of how work flows from idea to customer.

So, what is the solution?

While big bets on new products offer a significant opportunity to displace legacy systems and architecture, continuous modernisation also has a part to play. Utilising the right approach in the right context leads to the best results.

Firstly, it’s important to create visibility of investment in debt reduction. The Flow Framework^® metrics are a great starting point.

Flow Distribution helps organisations understand whether priorities are in line with business objectives. Work is categorised into one of four types of work: Debt, Risk, Feature and Defect. Through Flow Distribution, leaders can then see the current balance between work types.

Second, it’s important to be clear on the business outcome you are trying to achieve. It might be that investment in debt reduction opens up business process optimisation and new product value or it may be that the debt reduction is focused on improving product quality or release frequency. Outcomes can be broadly categorised into a focus of ‘Build the Right Thing’ or ‘Build the Thing Right’. The former will require specific product metrics to understand when the outcomes have been achieved and may start with debt reduction, followed by new features to meet objectives. The latter may be entirely measured through Flow Metrics, demonstrating how debt reduction improves operational performance. For example, investing in improved infrastructure management may improve Flow Time and Flow Distribution.

When operational performance is the target, then some investigation is usually required to look for improvement opportunities.

Here we show an organisation that undertook a Floodlight Discovery to identify high-value improvements. A hypothesis is formed showing how investment in a set of high-value improvements could lead to measurable improvements in Flow Metrics. That small set of improvements then forms the basis of the debt reduction work with clear, measurable benefits.

By creating a baseline, organisations can move from opinion-based improvement to an empirical approach where a measurable hypothesis is formed based on real data before investment in debt reduction starts. The investment is then justified through improvements in Flow Metrics (combined with product metrics where appropriate) to build confidence that money is being well spent.

Continuous modernisation vs legacy displacement

The journey towards modernisation requires careful consideration of outcomes and stakeholder alignment. It’s also important to understand the limitations of existing systems and how far they can be adapted. There is a line where improving existing systems becomes over-investment – where it is better to displace the legacy system entirely over time.

Legacy displacement effort must align with where your company is heading, not just where it’s been. A common pitfall is building an exact replica of today’s functionality only to discover it doesn’t support the organisation’s strategic initiatives for the next five years. Have conversations with business leadership about their vision for the future and ensure your displacement strategy supports those goals.

Rather than attempting to replace everything at once, look for existing seams in your business processes where you can break the problem into manageable pieces. These boundaries might align with different business units, customer journeys or data domains. Breaking down the problem not only reduces risk but also allows you to deliver value incrementally, building trust and momentum along the way.

Legacy displacement isn’t just about replacing technology – it often requires fundamental organisational changes. Leaders must consider whether current structures and processes will support the new way of working, or whether permission to work differently will be required.

The first step in legacy displacement is to ensure you don’t fall into the trap of big-bang releases. Instead, establish the practices and capabilities you want from the beginning. This might mean starting smaller but delivering working software early and often.

Trust between business and technology leaders is often strained in legacy environments. Rather than making grand promises about future capabilities, focus on delivering tangible improvements early in the process. This builds credibility and creates a feedback loop that helps refine your approach. Remember, stakeholders who have lived through failed replacement attempts will be sceptical – you’ll need to prove this time is different.

Many business processes are shaped by the limitations of legacy systems rather than actual business needs. Question these constraints and look for opportunities to improve the underlying business processes, not just the technology supporting them. This might reveal opportunities to simplify or streamline operations that weren’t possible with the legacy system.

The case for change is clear… Organisations that cannot evolve their architectures risk becoming increasingly constrained by their technology, unable to respond to market opportunities or competitive threats. Continuous modernisation involves making ongoing improvements to systems to prolong their lives, lower cost, reduce risk and improve developer morale and productivity. Displacing legacy systems is a great strategy when you can no longer continuously modernise or when a significant business opportunity arises that makes this the right economic option. Displacing legacy systems can always be done iteratively and incrementally to reduce risk.

Whether you are embarking on continuous modernisation, legacy displacement or both, success requires more than technical expertise – it demands a broader approach that considers business outcomes, organisational structures and ways of working. The goal is not just to solve today’s problems, but to build the capability to address tomorrow’s challenges as they emerge.

The true measure of success isn’t technical excellence – it’s the ability to better serve the needs of users, customers and the business. This requires establishing shared measures of success and making good trade-off decisions based on the context of the systems at play and the future strategic needs of the organisation. Whether it is through continuous modernisation or a form of legacy displacement, organisations must continue to invest in systems to enable ongoing product innovation and to avoid constraining business evolution.