If you’re ever looking for a real-world example that brings to life the phrase, “Missing the wood for the trees,” the standard approach to legacy modernisation should do the trick. At their heart, legacy projects are about updating a technological system, and so there’s a natural tendency to focus planning efforts on the technology.

However, after years of managing the delivery of such projects, I can tell you that in order to give your project the best chance of success, you need to step back from the technological ‘trees’ so that you can see the wood. It’s important to gain a holistic understanding of the project, and you need to be able to devote sufficient time to this and involve all the right people.

In this blog post, I’m going to explore this further, describing the expert input you need to draw on, the role of leadership in this context, and the kind of up-front planning that’s required. But to begin with, I’ll share a few insights on what’s different about managing delivery on a legacy modernisation project.

Legacy modernisation project delivery

When it comes to managing the delivery of a legacy project, the same basic principles apply as for a greenfield project: you need to understand the business problem, define the current and target states, and plan the delivery. However, the way you implement delivery based on those principles differs for a number of reasons.

Fundamentally, the business drivers are different. In greenfield projects, the primary driver is often revenue generation, whereas legacy modernisation projects tend to focus on cost reduction, operational efficiency, and risk mitigation. This difference impacts decision-making and prioritisation, with greenfield product roadmaps usually being influenced by marketing and commercial strategies. In contrast, a key milestone on a legacy modernisation roadmap might be, for example, the date when new regulations come into force.

Self-evidently, the as-is state is more complex on a legacy modernisation project. In the discovery phase of a legacy project, you need to map the current business setup, the organisational structure, ways of working, and technical architecture; this includes identifying dependencies and any risks of breaking changes. This all needs to be taken into account in charting the route to the to-be state – and this route may often appear circumlocutory compared to a greenfield project’s straight line towards a minimum viable product.

A multidisciplinary approach will contribute to a successful outcome on any project, but never more so than on a legacy modernisation project, as I’ll now explain.

Seeing from many angles to gain a holistic view

One symptom of not being able to see the wood for the trees on legacy modernisation projects is that many organisations focus the discovery phase on a technical investigation. Even when people in non-technical disciplines are involved in this phase, they can often work in silos. This is a mistake.

In my experience, the most successful legacy modernisation projects have always involved close collaboration between Architects, Analysts and Designers. This stands to reason. Legacy projects are like the three-dimensional chessboard in Star Trek, requiring consideration of:

  • People (roles, teams, customers)

  • Processes (business architecture, operations, workflows)

  • Technology (systems, data, architecture)

The delivery plan must align technical and business perspectives, and account for dependencies and impacts across all three layers. This complexity compels a multidisciplinary approach to discovery, planning and delivery. Taking this approach is important on any legacy project, but never more so than when you’re taking the opportunity to streamline processes at the same time as modernising the technology.

Business Analysts map the as-is and to-be business processes, independent of technology, while Architects focus on technical sequencing, data flows and system interactions. These specialists should not work in silos; instead, they should co-evolve artefacts like process maps, sequence diagrams, and service blueprints. Each iteration of these informs the others, creating a feedback loop that refines both the business and technical plans.

On any modernisation project involving user or customer journeys, the inclusion of User Experience (UX) Designers is key. These specialists map customer journeys and conduct service design, identifying pain points and opportunities in the current experience, and shaping the desired future state. This user-centric lens ensures that the planned changes improve real-world outcomes.

The business benefits of this collaborative approach can be huge. One platform modernisation project I worked on simplified and shortened a customer journey from two hours to twenty minutes, making sales staff much more productive and saving the business millions of pounds.

How leadership can support smooth delivery

The worst thing you can do on a legacy modernisation project is to begin delivery before you’re ready. That said, there’s often pressure to get underway without delay. Sometimes, there’s a fixed, external deadline that must be met, as with this API project my colleague Greg Lewis worked on. Or an executive sponsor may put pressure on the project team to produce visible outputs as soon as possible. Regardless of the reason, if you start too soon, it’s a recipe for rework caused by misaligned priorities and technical missteps.

Rather than applying pressure on the delivery team, the role of executive sponsors and leaders is to create the space for proper discovery and planning. All of the work to map processes, understand dependencies and shape the delivery roadmap is not only valid, it’s essential, and it will save the organisation time and money; getting underway too soon will do the opposite.

To repay this trust in the delivery team by the leadership, it’s the responsibility of the person overseeing delivery to communicate with leaders clearly and in business terms, rather than technical terms. Sometimes, this will be reasonably straightforward, given the extent to which legacy modernisation processes are tied up with business architecture. But even when the rationale behind something in the plan is technical, it should be articulated in terms of business value, such as what benefits it unlocks or how it reduces risk or cost. Communicating in this way fosters leadership support for the plan and avoids confusion or resistance when the recommended priorities don’t match initial expectations.

Of course, this clear communication should not be confined to the leaders – it should permeate all layers of the organisation. By working closely with business stakeholders from the start, the multidisciplinary team can take them on the journey, ensuring that they understand the logic underpinning the team’s recommended delivery approach. That way, when the time comes to make governance decisions concerning the project, everyone’s already on the same page.

Why sufficient up-front design is essential

I’ve mentioned planning throughout this post, as you would expect. We’re now in an age where agile is the orthodoxy, and the Agile Manifesto famously says that it values “Responding to change over following a plan.” Over the years, this has led some teams to assume that projects can get underway with minimal or no planning. But of course, the Agile Manifesto goes on to say, “While there is value in the items on the right, we value the items on the left more.” What the manifesto was warning against was the slavish implementation of a delivery plan produced after a comprehensive up-front design phase. It wasn’t cautioning against planning.

Planning remains of the first importance in software development, but particularly so with legacy modernisation projects. Regardless of whether you’re delivering a greenfield project or a modernisation project, you need to do sufficient up-front design to be able to get going and, more importantly, keep going. But to “keep going” on a legacy modernisation project is significantly more complicated. Without sufficient planning, you might find yourself frequently delayed while you wait for, say, data to be ready for migration, or you might build front-end components without knowing what data fields need to be displayed.

That’s what makes the discovery phase so important, providing the opportunity to determine the optimal, logical sequencing of the delivery phase. I use the word ‘optimal’ deliberately – there’s usually so much business architecture at play in legacy modernisation projects, so many variables, that there’s often not a ‘right’ sequence – you simply have to aim for the sequencing that’s as good as it can be in the constraints you’re working within.

In my experience, this sequencing is not always as obvious as it first seems. Let’s say you have four interdependent systems in scope for the modernisation project and that, at first, the logical sequence appears to be A, B, C, then D – chiefly, because system A is expensive to maintain and the business wishes to offload it first. However, through the discovery, you may find that offloading system A in the least disruptive manner requires ‘enabling changes’ first to systems B, C and D. On another project, you may discover that there’s unexpected early value to be unlocked by prioritising work on, say, system C ahead of the others.

It’s this quality of legacy modernisation projects that makes it sensible to have defined project phases – each one aligned to business outcomes and dependencies – in a way that is uncommon on greenfield projects. That’s not to say that a waterfall approach is required. Planning and delivery within each phase can be along agile lines, but the phasing ensures that the optimal delivery sequence is followed.

Drawing the threads of this blog post together, it’s the holistic view of the project that allows you to arrive at the optimal sequencing: the result of bringing the right people together, and giving them enough time and space to consider the layers of People, Processes and Technology, so that they can weigh up all the variables before making their recommendation. While all of this up-front design may appear to be at odds with an agile approach, it isn’t. By achieving a holistic view during discovery of all the risks and dependencies, you’re in effect buying yourself the freedom to be agile during delivery – and to “get going and keep going” with confidence.