The 7Rs of Modernisation – Identify how best to update your apps

The post-pandemic acceleration of digital transformation is showing no sign of letting up this year. While for consumers this change might look like a brightening up of websites and new services, developers know that there are far more complex tasks they need to power through in the background. Historically, enterprises were unsure if IT or technology mattered (hence the outsourcing trend of a decade ago). But today’s companies are focused on how to solve complex technical problems in software – whilst ensuring they are at the cutting-edge of innovation.

Modernising huge IT systems is no mean feat – if only it were as simple as hitting ‘update’ on the app store. Once you start identifying software to modernise, you’ll soon discover that there’s too much of it. Organisations often find that there are thousands of highly diverse applications and services on the list. Air France-KLM, for example, has been working on modernising 2,000 applications. Larger organisations could have even more, especially after many years of mergers and acquisitions.

Putting together a plan for what to modernise is confusing if you only focus on technical reasons to modernise. There will always be a plethora of reasons because, for the most part, there's always a better way to run and build applications. That's part of the magic of technology: it's always getting better.

But, modernising applications solely based on technical needs is not impactful enough business wise. Instead, we should consider how an application is fit for purpose, rather than whether it should become the fastest and most advanced it could possibly be. There’s no point buying a Ferrari to do the neighbourhood school run.

We've found that there are seven different ways of modernising any given app. Perhaps humanity will one day discover an eighth, or ninth, and tenth if we survive long enough, but these seven approaches come up over and over. By design, these seven dispositions all begin with the letter R so that we can label them "The Seven R's." Here they are, ordered from least to most effort, risk, and value: Retain, Retire, Rehost, Replatform, Refactor, Rewrite, and Replace.

Retain

As someone wise once said: if it ain’t broke, don’t fix it. If an app is old but still serving its purpose, keep and don’t touch the app for now. That is, make no changes and keep things running as they are. This is probably the default option for most apps in your portfolio, as doing nothing can be a wise strategic choice when there are likely other apps that more urgently need your attention.

Retire

Sometimes the need for an app simply runs its course. There’s no need to update it - simply decommission any end-of-life applications. In this case, your analysis often finds that the application is used very little, has been superseded by another application, or is no longer

profitable to run. A good example here is the Minitel service, once the world’s most successful online service. Once the Internet gobbled up all of "online," Minitel was finally retired after 32 years of operating in June 2021. Applications that were purpose-built for regulations that no longer exist are another common app to retire, as are applications that run parts of your business that no longer exists.

Rehost

Often called “lift and shift", this is repackaging and moving existing applications with as few changes as possible. This is sort of like just copying an application and all its data to a new computer. Typical examples are cloud and data-centre migrations or the process your company has been through while virtualising its data centre.

Replatform

Now we get into the meat of what might typically be considered modernisation. Here, the application remains the same, but there are significant changes to the underlying technology stack and platform (runtime, framework, middleware, operating system) of your app. This can require changes to the actual application itself, but they should be very minimal. For example, replatforming might mean moving from an Oracle WebLogic Server to Spring Boot, from .NET to .NET Core, from Windows or AIX to Linux, or moving your applications from virtual machines to containers.

Refactor

In this type of modernisation, you're finally changing your application's code deliberately. When you refactor, you redesign and rewrite parts of your application to take advantage of new platforms and capabilities. This is distinct from rewriting in that the functionality of the application stays the same and is not updated: just the "internals" of the app are changed. This is sort of like keeping the exterior and interior of your car looking and operating all the same but replacing everything under the hood and under the body. For example, you might refactor your application to scale from thousands to millions of users as your business gains customers. From video games backends such as Diablo II, to core banking systems such as the Open Banking evolution and governmental services exposed to citizens over the internet such as the German online access act, this option is often the default cost-effective choice to rejuvenate existing systems while bringing them to a new era.

Rewrite

The name says it all: sometimes it’s time to start from scratch and write a new application. Your organisation still needs what the application does (for example, registering for fishing licences or scheduling ice machine maintenance), but the old application no longer solves the problem well and is challenging to maintain. Instead of just duplicating the same screens and workflows but with new fonts and colours, this type of modernisation gives teams the chance to reimagine how people interact with the application and how it functions. The only real option to modernise a digital user experience is usually to rethink and rewrite it from the ground up. There is nothing like throwing a bit of fairy dust on the frontend code to radically ameliorate usability and ergonomics. Many inspiring examples of application rewrites can be found in the world of software vendors, where operating systems, middleware components,

and frameworks of all kinds have been rebuilt from scratch with the newest available hardware and infrastructure paradigms: x86 and 64-bits architectures, parallel processing, and new end-user devices.

Replace

In this scenario, you still need the functionality that the application provides, but you no longer find value in the control and customization abilities that come from owning the application. Instead, you outsource it by replacing it with a commercial off-the-shelf (COTS) application, often a Software-as-as-Service (SaaS). The same "outcomes" are achieved, but you now use a third-party or outsourced option.

Such transformations are straightforward for highly standardised systems like mail or file servers. Also while remaining in the same software vendor’s ecosystem such as Office to Office 365, replacement paths are frequently covered by exhaustive guides and tools.

For non-standard, end-of-life systems, this is often the most effort-intensive option. Transitioning your highly customised Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Human Resource Management (HRM), or e-commerce system to another, for example, will likely be a daunting task. The effort is usually worth it, however, as all that customisation, over the years, becomes a boat anchor that's causing all your problems. We have worked with large companies prioritising a rewrite of such systems over a replacement.

Choose right

While all of these technical approaches have their own merits, the decision on which you take should be motivated overall by the business goals behind modernisation in the first place. Modernisation project failure is often caused because this is left out of the decision-making process. With business context and technical knowledge, modernisation no longer needs to be a daunting task.