How best to update your apps, with VMware modernisation tips

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.