Upgrade or replace:
Pragmatic modernisation strategies

Software often fails to meet an organisation’s needs over time – whether it’s the result of changing requirements or the availability of a better solution.

The decision between upgrading or replacing systems ultimately comes down to deciding between how well the current software meets its requirements, and how well a new solution could do that job (or what new opportunities a new solution could unlock). 

From technical debt to the age or performance of a system, there are various reasons why a better, upgraded solution is desired. These upgrades usually follow one of the following routes:

    1. Rebuild from scratch. This requires the business to stop working on old platform completely or put it in limp mode until the new replacement version is ready to roll out.
    2. Upgrade in place. Retain the platform in production, and modernise technologies through carefully planned upgrade steps.

The typical pitfall is choosing option 1, deciding to rebuild or replace a system completely, when it’s not entirely necessary. Starting from a clean slate is more appealing. In theory there are no constraints, and so there is technical and creative freedom to create the ultimate solution. In reality, this bias can be blinding, and it’s often much more practical and economical to invest the energy in upgrading solutions in-place, wherever possible.

Below are 3 reasons why you should consider upgrades over replacements during your modernisation strategy:

1. Cost and time efficiency

In most instances, upgrades to current solutions are more than sufficient. Systematic upgrades allow you to introduce your upgrades to users and customers as soon as they are ready, rather than waiting for a big bang deployment. Rebuilding the plane while flying it and modernising as you go, allows you to think practically, and forces technology teams to consider business value, as well as the realities of constraints on the existing system.

2. Dependencies on other systems

More often than not, these solutions that require enhancements exist in a network of systems. Over time, organisations forget about elements and features that were built for specific systems in use. When replacing these, a whole landscape of integrated systems starts unravelling. It is safer and more diligent to uncover and resolve these piece by piece, reducing time and budget risk into smaller digestible iterations.

3. Sometimes good enough is good enough

It’s easy to fall into the trap of wanting the best – something shiny and brand-new. Complete replacements are risky, and usually take longer than planned – at a steeper price. Complete specifications of legacy systems are either non-existent or incorrect. If documentation does exist, it is unlikely that it incorporates all details of the system changes that have been made over the years.

In certain instances, wholesale rebuilds are necessary. Replacing your existing software is more likely to be the best choice when your organisation has grown to the point that it’s completely exceeding your software’s current capabilities. When going down this route, ensure that you have a detailed modernisation strategy in place, and that you are financially prepared.

In-place upgrades take more diligence, preparation and resolve from development teams, but offer a methodical upgrade path. These projects can take longer overall, and will still require investment and patience, but ultimately offer a more business-friendly compromise. Work backwards from what the business or product needs, and forwards from what technology can offer.

If you are currently planning on upgrading or replacing any systems, and don’t already have a modernisation strategy in place, get in touch with us.

Related Articles
Innovating with
design thinking
Innovating with
design thinking
Adapting the
design sprint methodology for enterprise