You’ve established your legacy system isn’t meeting your constantly evolving needs, but the thought of scrapping it and starting afresh is waking you up in the middle of the night. Surely there must be a way to modernise? But how much time and resource is it worth investing to reduce your technical debt? And how far do you go before you finally admit defeat?

At least you can feel safe in the knowledge that you’re not alone in battling this conundrum. According to MIT, 67% of C-level executives would like to completely replace their core legacy systems, but at the same time, 70% say they’d like to keep their systems as long as possible. To replace, or not to replace? That is the question.

Choosing how far you modernise doesn’t have to be a black or white solution though; it should encourage a whole spectrum of different methods and processes to be explored. From re-hosting and re-factoring through to a complete re-build – application modernisation is what you make of it.

Before deciding which route to go down, you need to ask yourself some important questions about why you’re having to modernise your application. Has the scope or specification of your application changed? Does it still fulfil your business requirements? How well is your system performing or is the source code still supported? By answering these questions you’ll be on the way to finding the right solution.

With a wide range of modernisation options available (and multiple combinations), it can be a bit of a minefield to work out the most appropriate solution for your given situation. But by establishing why you want to modernise, it will lead you on to figuring out how to modernise. Discover below the variety of methods of modernisation out there…

 

 

Encapsulate

Your system’s performing well and meeting most of your business requirements, so you’ve established nothing drastic needs to change. However, you want to improve performance and increase the scope. In this scenario encapsulation will help you leverage and extend your application’s features and value through encapsulating the data and functions.

Re-host

Your application seems to be meeting most of your business requirements, however it’s not operating in the optimum environment. Through re-hosting you can simply re-deploy the application component to another physical, virtual or cloud infrastructure without having to alter the application code or modify features and functions.

Re-platform

If application performance is your main concern, then this might be solved by re-platforming. By making minimal changes to the code to adapt to the new platform without changing the code structure or the features it provides, migrating the application component to a new runtime platform should improve your performance.

Re-factor

If you’re experiencing performance issues but your business requirements have changed too, then re-factoring your application would be beneficial. Involving restructuring and optimising your existing code without changing its external behaviour, re-factoring is a step up from re-platforming and involves a deeper dive into the application.

Re-architect

Is your system not running quite the way you want it, but nothing seems to be standing out as the main issue? Perhaps re-architecting is the answer. By materially altering the application code so you can shift it to a new application architecture, you can now fully exploit new and better capabilities of the application platform.

Re-build

You’ve identified that the critical issue you’re facing is that you’re using outdated or unsupported code. This is inherently risky as it’ll be difficult to maintain and ultimately run effective tests. Therefore, re-building or re-writing the application component from scratch while preserving its scope and specifications, would be the preferred option.

Replace

If you’ve explored all the alternative methods of modernising but none have the capacity to solve your issue, unfortunately it seems that replacement is your only option. As your scope has changed significantly your current application has become redundant and although it’s a drastic measure, it would be best to eliminate the former application component altogether and take the new requirements and needs into account.

 

Modernising your applications isn’t a quick decision to make. But by taking the time to explore your options, rather than maybe going straight to Replace, means you could get the best of both worlds – a modernised, flexible and scalable system that also retains the originality of why you kept the system around in the first place. Multiple issues, such as performance and a sub-optimal environment, may also mean a combination of options can be chosen. For example, you can both re-host and re-platform to tackle multiple issues in one move.

Whichever route you go down, effective application modernisation is what you make of it – it’s more than a just a decision between staying put or completely changing. However, the most important driver is to ensure that architectural and technical change are aligned to the needs of the business and isn’t simply technology change for technology’s sake.