App Modernisation: An Overview

App Modernisation is a popular topic, particularly in older organisations although it is also used with increasing frequency in tech companies. It’s popular because old systems become outdated and often start to struggle to meet the demands of the business they’re in.

These systems need to be dealt with in some way, which is how the discipline of App Modernisation was born. 

However, people’s understanding of what app modernisation means differs fairly substantially. In a poll of over 150 senior technology leaders at large organisations, around a third defined it as using cloud infrastructure, another third say it was about moving legacy systems to the cloud and others just felt it meant using cloud based tools. Some felt that just using microservices meant they were modernising. 

It’s unsurprising that there were fairly substantial differences in definitions and views. Even given App Modernisation’s popularity, it was hard to find a decent “Overview of App Modernisation” that did the discipline justice by giving the necessary background, the right definition, the context and a comprehensive, evidence based framework (amongst other things).

The purpose of this article is to give an overview of App Modernisation, we’ll cover:

1. Background
2. What is App Modernisation?
3. When and Why You Need App Modernisation
4. App Modernisation In Context
5. Your Choices With Old Systems

What is App Modernisation?

App Modernisation is the discipline of upgrading, rebuilding and replacing old systems. It also provides a useful frame of reference to deciding whether to keep operating an old system and how to go about operating it.

Any system that has existed for more than a few months starts to age. The system itself ages with tech debt, bugs and constraints while technology advances to offer new capabilities, new experiences and faster cycles.

This means old systems need to be reviewed regularly to determine the best pathway forward. At one extreme this could be completely rebuilding a system. At the other extreme you may decide to make no changes and just keep it running however you can.

This isn’t limited to applications you develop either, it applies to software you buy and subscribe to as well.

It also isn’t a new concept. Modernisation used to be moving from mainframes to Windows and Linux based applications. There were single system applications that then needed to be rebuilt as client/server applications. Now it’s predominantly private infrastructure to cloud and sometimes cloud to better cloud. In the future it could be something like cloud to AI.  The point is, we’ve always been modernising and will need to continue to do so, it’s a timeless concept at one level.

When and Why You Need App Modernisation

So when and why do you need to modernise an application? 

To answer this we’re going to look at data about what executives, architects, engineers and other professionals say is important to them in modernisation.

We will draw on vFunction’s survey of 250 technology professionals in 5,000+ employee companies, RedHat and Konveyor’s survey of 600 technology professionals globally and IDG’s survey of 400 technology decision makers at 1,500+ employee companies.

You can see that the data shows the key drivers for app modernisation to be (in rough order of popularity):

1. Reliability: the stability, availability and uptime of the system.
2. Development Velocity: how quickly work on the system takes place.
3. Innovation: the creation of new ideas, products and revenue streams.
4. Costs: reducing costs or making the system more cost efficient to run.
5. Scalability: the ease with which the system can handle more usage.
6. Security: how secure the system is.
7. User Experience: how the system is able to meet the needs of its users and customers.
8. Developer Productivity: the individual productivity of people working on the system.
9. Risk: the risk profile of the system in general terms. 

To arrive at this chart and prioritisation, the reports were mapped as follows:

It is worth noting that each of the surveys looked at this slightly differently:

1. Konveyor asked how respondents “plan to measure success” not necessarily why they are going to do App Modernisation, although you can infer their measure of success is highly related to why they are doing it.
2. IDG asked what benefits they’ve seen (past tense) which may be different to why they invested in App Modernisation initially. 
3. vFunction asked “What is the goal of App Modernisation?” which, like Konveynor’s is not necessarily why they are doing it but most likely indicates this.

You can use the data from these reports to help you see what business cases are likely to be accepted by others but ultimately you will need to workout what the right driver is for your specific situation.

Your Choices With Old Systems

Once you’ve done the analysis to understand what might drive modernisation efforts you will be faced with a decision. 

The decision will almost certainly be to make one of the choices listed below.

You need to put all of the possible choices on the table, not just those that relate to app modernisation, especially if you want credibility with all of your stakeholders.

The comprehensive list of decisions you can make with an old system are:

1. Encapsulate: Leverage and extend the application features by encapsulating its data and functions, making them available as services via an API.
2. Rehost: Redeploy the application component to other infrastructure (physical, virtual or cloud) without modifying its code, features or functions.
3. Replatform: Migrate to a new runtime platform, making minimal changes to the code, but not the code structure, features or functions.
4. Refactor: Restructure and optimize the existing code (although not its external behavior) to remove technical debt and improve nonfunctional attributes.
5. Rearchitect: Materially alter the code to shift it to a new application architecture and exploit new and better capabilities. 
6. Rebuild: Redesign or rewrite the application component from scratch while preserving its scope and specifications.
7. Replace: Eliminate the former application component altogether and replace it, considering new requirements and needs at the same time.
8. Retain: keep operating as is without major change.
9. Retire: just retire it and the functions it performed.

This list builds on Gartner’s list and is more comprehensive than “the 6 Rs” (an app modernisation “framework” repeated across the web but seemingly not grounded in data or comprehensiveness).

The list is mostly mutually exclusive but you can also combine some of the options.

Putting this into context:

Now you’re armed with more information to make better decisions about app modernisation.