The 7Rs of modernization – a roadmap for application transformation


Digital transformation is well underway, with tech teams around the world gearing up to try and update their organization’s digital experiences at the pace consumers demand. The way companies have integrated technology slowly, over time, means many have a vast network of half-adapted apps behind the scenes that could be improved, updated, or scrapped altogether.

Modernizing requires a fair amount of elbow grease – not as simple as hitting “update” in the App Store. A thorough assessment of an organization’s systems could potentially reveal that there are thousands of diverse applications and services to explore and examine. Air France-KLM, for example, is working on the modernization of 2,000 applications. Larger organizations might have even more, further complicated by corporate “life” events like mergers and acquisitions.

It may seem that the main motivation for modernizing is for technical reasons – why not make everything run smoothly and quickly? Although the beauty of technology is that it is constantly improving, in an organization it is also important to understand the business reasons for modernization.

The impact of an application or service will ultimately be determined by its fitness for purpose – whether it performs well for the business. This actually makes your job easier, as not all systems need to be the highest specification possible. There’s no point in buying a Ferrari to race at the neighborhood school.

We found that there are seven different ways to modernize a given application. Perhaps humanity will one day discover an eighth, or a ninth, and a tenth if we survive long enough, but these seven approaches keep coming back. By design, these seven layouts all start with the letter R so we can label them “The Seven Rs”. Here they are, ranked from least to most effort, risk, and value: retain, retire, rehost, replatform, refactor, rewrite, and replace.

To hold onto

As the saying goes: if it ain’t broke, don’t fix it. If an app is old but still serves its purpose, let things work as they are. This is probably the default option for most apps in your portfolio, as doing nothing can be a smart strategic choice when there are likely other apps that need your attention more urgently.


As an organization changes and grows, the need for an application sometimes takes its course. There is no need to update it – just decommission all end-of-life apps. If your analysis revealed that the application is very lightly used, has been replaced by another application, or is no longer profitable to run, it can be retired without worrying about upgrading or replacing it. A good example here is the Minitel service, once the most popular online service in the world. After the internet swallowed up everything “online”, Minitel was finally retired after 32 years of operation in June 2021. Apps specifically designed for regulations that no longer exist are another common app to retire, as is applications that run parts of your business that no longer exist.


Often referred to as “lift and shift”, it involves repackaging and moving existing applications with as few changes as possible. It’s a bit like copying an application and all its data to a new computer. Typical examples are cloud and data center migrations or the process your company went through when virtualizing its data center.


Now we get to the heart of what might generally be considered modernization. Here, the application remains the same, but significant changes have been made to the underlying technology stack and platform (runtime environment, infrastructure, middleware, operating system) of your application. This may require changes to the app itself, but they should be very minimal. For example, reformulation could 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.


In this type of modernization, you end up deliberately modifying the code of your application. When you refactor, you redesign and rewrite parts of your application to take advantage of new platforms and features. This is distinct from the rewrite in that the functionality of the app remains the same and is not updated: only the “internals” of the app are changed. It’s a bit like having the exterior and interior of your car look and function the same, but replacing everything under the hood.

From video game backends such as Diablo II to core banking systems such as the evolution of Open Banking and government services exposed to citizens on the Internet such as Germany’s Online Access Act, this option is often the Default cost-effective choice for rejuvenating existing systems. while bringing them into a new era.


The name says it all: sometimes it’s time to start from scratch and write a new application. Your organization still needs what the app does (for example, registering fishing licenses or scheduling ice machine maintenance), but the old app no ​​longer solves the problem well and is difficult to maintain.
Instead of just duplicating the same screens and workflows but with new fonts and colors, this kind of modernization gives teams the ability to reinvent how people interact with the app and how it works. The only real option for modernizing a digital user experience is usually to redesign and rewrite it from scratch. There’s nothing quite like throwing a little fairy dust on the front-end code to drastically improve usability and usability.

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 the ground up with the latest hardware paradigms and available infrastructure: x86 and 64-bit architectures, parallel processing and new devices for end users.


In this scenario, you still need the functionality provided by the app, but you no longer find value in the control and customization capabilities that come with owning the app. Instead, you outsource it by replacing it with a standard commercial application (COTS), often software as a service (SaaS). The same “results” are achieved, but you are now using a third-party or outsourced option.

Such transformations are simple for highly standardized systems like mail or file servers, by simply switching to already familiar commercial software like Outlook.

For end-of-life non-standard systems, this is often the most effort-intensive option. Transitioning from your highly customized enterprise resource planning (ERP), customer relationship management (CRM), human resource management (HRM) or e-commerce system to another, for example, is likely to be a arduous task. But see it as an opportunity for freedom instead, because all that customization over time tends to become a burden that leaves you behind.

Choose well

While your technical side may have a preference for one method or another, the final decision on what to do with each application should be made with the aforementioned business goals in mind. Many modernization project problems arise because the overall business objective is not properly considered. However, the combination of the two makes modernization an exciting task rather than a daunting one.


Comments are closed.