Modernisation is as much about people as technology

Most modernisation programmes are planned as technology projects: a target architecture, a migration plan and a budget. Whether they create value depends just as much on the people who know the old system, run it every day and will have to trust its replacement.

The system is only half of what you are changing

A legacy application is more than its code. Around it sit years of working practice: the workarounds operations staff rely on, the reports finance reconciles each month, and the exceptions everyone has learned to handle by hand. Replace the system without understanding that practice and the new one can pass every test and still fail in use.

That is why the first question in a modernisation should not be “what do we build?” but “what does the business actually depend on?” The answer sits partly in the code and partly in people’s heads.

Capture what people know before you decide

In a recent engagement for a European software vendor, the scope was not a rebuild at all. It was to deconstruct and document an existing legacy application so the business could plan its modernisation. The code was read module by module, but some of the most important material came from knowledge-gathering sessions with the staff who run and support the system. Their explanations filled the gaps the code could not, and they reviewed the documentation before it was approved.

The result was not new software. It was something the business did not have before: an approved record of what the application does and why, which it can now use to plan and modernise with confidence.

Two lessons carry over to most programmes:

1. Start with knowledge, not architecture. Decisions made before the system is understood tend to be revisited later, at greater cost.
2. Make the experts reviewers, not just interviewees. People who confirm or correct the record have a stake in it, and the record is better for it.

Four groups to bring with you

Different people experience the same programme in very different ways. Each needs something different from it.

• The people who keep the system running. They hold knowledge nobody else has, and they are often the most unsettled by change. Involve them early and be clear about their role afterwards. We have written separately about why engineers make or break a modernisation.
• The people who use it every day. Their routines will change. They need to see the new system handle the cases they care about, and time to learn it before the old one is switched off.
• The business owners. They decide what must stay the same and what can change. Give them evidence, not assurances, and ask them to sign off the decisions that affect them.
• Leadership. They need to see risk falling and value arriving, stage by stage, rather than a single promise at the end.

Keep the old and new running side by side

Change is easier to accept when it is reversible. Running the existing system until the new one matches it lets people compare results, raise concerns and build confidence on real work. It also turns adoption from a single go-live event into a series of smaller steps.

What this means for the business case

A business case that counts only build cost and licence savings misses where the risk really sits. Knowledge that leaves with a retiring specialist, a team that loses confidence, or a new system people work around: none of these appears in a migration plan, but each can erase the savings it promised.

Treating people as part of the scope from the start is not a soft extra. It is how the value in the business case is protected.

If you are weighing up a modernisation and are not sure how much of your system is understood today, a free assessment of one legacy application is a practical place to start.