Over the last 18 months, organisations have had to evolve to stay competitive, or even just to survive. Initiatives that were typically off-agenda or low priority pre-2020 have become mission critical, including the adoption of new services.

The evolution of the workplace has leaned heavily on technology, demanding digital modernisation, often at pace and with varying success. It has forced organisations to re-evaluate their trajectories and priorities, and as a result revisit their ‘digital roadmap’ with fresh eyes. Increasingly, the legacy application is no longer sustainable, and cannot be worked around. It is a serious impediment to business success - a ‘blot on the landscape’ and an obstruction to that critical evolution. Legacy applications and systems are often monolithic by design with unsupported binaries and platforms. When they fail, they fail hard, damaging productivity, user satisfaction and other dependent services. Their support and maintenance is often a costly and labour-intensive drain on high-value resources.

Savvy IT leaders know that there are options to bring legacy in line with an evolutionary strategy. These options exist along a continuum and are characterised by the degree (and cost) of change they represent. Each change must be considered against the potential value of the outcome. We typically see 3 main application change options – migrate, modernise or rebuild.

Migrate: Replatform

Migration involves the lift and shift of the legacy system, with minimal change to application functionality. The application still ‘looks’ like the original, but the infrastructure location and compute source will change, for example, moving from on premise physical or virtual servers to cloud Infrastructure as a Service (IaaS) virtual machines (VMs).

Replatforming naturally leverages some native benefits, such as scalability and availability. This benefit can only be realised however, if the application tolerates the new platform functionality. Whilst migrating to a new platform may promise lower cost of ownership and increased performance, little business value is added and any problems caused by the application code will persist, just on a shiny new infrastructure.

Also note that this option is rarely available to systems that are run on infrastructure that is way past end of life (for example running on a mainframe) – these are effectively impossible to get into the cloud. If this is you, scroll down for other options!

Modernise: Refactor or Rearchitect

Modernisation involves some form of re-engineering of the existing application - the scale of which is dependent on your requirements. Changing and optimising the application could involve using cloud-native services.

Refactoring

You could start off small and make minimal changes to the application: swapping out a server-based database for a cloud-based Database as a Service instance, or putting a web front end in a container or in a WebApp. The architecture of the application remains the same, but a portion can leverage some cloud native benefits, potentially creating efficiencies in terms of cost, scale and availability.

Rearchitecting

Taking this a stage further would involve Rearchitecting the application. Here we break down the application into its component parts, decouple capabilities and deploy them on to appropriate services. An example would be to look for common services that could be modernised into functions or containerised. These new constituent parts can be kept as separate concerns that talk to each other through documented APIs, easing maintenance and development. This obviously requires significantly more effort for it to be successful than the replatform or refactor solution, however, the longer-term benefits and overall business value are often greater.

Rebuild

The final approach is to Rebuild, and for many there is huge appeal in starting fresh. You can develop a new application that has all the known problems and mistakes designed out - and design in new features and capabilities that make it extensible, scalable, and modular. Similarly, a cloud-native application is likely to create the agility to release and update faster with lower risk and less stress and expense. You can also build in better governance, compliance and security adherence. You can build to your exact requirements today with the tolerance to accommodate tomorrow’s directional change. Should business requirements evolve or priorities switch, the platform, development, and support staff are able to pivot and reprioritise releases with agility. This represents the highest cost to implement, however the relative benefit is potentially massive and far reaching.

So, what’s the right approach?

It depends on several factors: your success horizon (what you need to achieve in the short versus long term), the time and resources you have available and their capability. It depends on budget and how you are going to measure the return on investment - and the cost of doing nothing. You need to start by understanding the business problem that needs to be solved and consider the potential long-term value. There are numerous other factors that should also be considered to make the decision on whether to migrate, modernise or rebuild.

Some of the challenges our customers typically bring to us include:

• Frameworks and operating systems not being supported by the business or having passed end of life

• Applications that do not ‘play’ with the other apps and services

• Feature improvements and new feature requests that are not feasible

• Limited internal capability to understand, manage and support

• Old tech and apps that are not interesting to developers, making recruitment difficult

• Unavailable hardware

• Expensive patching and updates in terms of downtime, fraught with uncertainty

• Benefits decay: severely diminished from its initial proposition

• Uncompetitive user experiences that negatively affect productivity

• Data centre migration mandates (in many weeks…)

• Duplication of data and lack of a true source of truth.

The decision to migrate, modernise or rebuild is really about right-sizing the degree of change your business can tolerate in line with readiness, budget and business impact. Even if you just lift and shift your app to a new cloudy platform like Azure, you have just taken a first step into the world of application modernisation. You have made a change for the better and opened up the opportunity for improvement at a pace that you can control. And trust us - your business, customers, users and stakeholders will thank you for it.