Your business has been using applications that are many years old without problems. But an email from your hosting company or managed service provider now states that they no longer support the versions of the technology stack your application relies on and you are urged to upgrade or find an other partner, all within a couple of months time.
This is a common scenario that many organizations face, especially if they are running critical applications for many years. Even though this might seem like a difficult situation, there are effective strategies to overcome this challenge.
The five Rs
Originally defined by Gartner in 2010 [Paywall protected], the five Rs framework defines cloud migration strategies that helps an organisation decide how a “legacy” application could be modernised to run in “the cloud”. When setting aside this cloud objective, these strategies are still enormously helpful in guiding your modernization efforts.
Rehost
Rehosting is better known as “lift-and-shift” where the application and all its dependencies are taken from one place to another without modifying the code, the libraries and the operating system.
This strategy can be implemented fast and has limited impact on business operations and is recommended when there is an urgency (like in the introductory example).
The downside of this strategy is that the application remains legacy and can not benefit from new techniques to improve its resilience, performance, and scalability.
If this strategy is chosen, it should be temporarily to mitigate the urgency followed by one of the next strategies.
Refactor
When time is less of a pressure, refactoring an application is often found to be the significant step forward. By changing only small portions of the application to make it more useful to run on cloud-native or scaled virtual environments, the business can be continue it’s operations without spending a massive amount of capital and resources to enjoy the fruits of this modernisation strategy.
Over the years we have observed a top-3 of common blockers that could be solved within days or even hours. These are:
- Fixed IPs or static FQDNs hard-coded in the code
- Fixed file paths statically hard-coded in the code
- Synchronous interaction with other services like databases and messaging systems
These issues are inexpensive to resolve, but there’s a major caveat: the application requires sufficient test coverage to ensure that the refactoring effort will not break the functionality. Unfortunately many teams I worked with still lack the habit of writing sufficient tests with their code, causing additional delays when refactoring the application for modernisation.
Revise (re-architect)
When the aged application is not performing well and adding features becomes a true nightmare because of the application’s complexity structures, one might decide to rearchitect the whole application. In some cases this could be as simple as splitting up core services over multiple machines, or more complex by splitting the application up by business domain.
Even though this strategy drastically impacts the operational availability of the existing application, it could prove to be financially more economic and faster than rewriting the application entirely. The drawback is that a majority of code needs to be refactored to meet the new architecture. Additionally the transition from the existing architecture to the new architecture could cause operational challenges and could even mean downtime. This transition needs to be carefully planned, tested and executed to ensure that the operational impact is kept to a minimum.
Rebuild
Most common scenario is that an existing application has been running in production for such a long period without proper updates or maintenance and no commercial alternatives exists, that there’s no other option than to rewrite the application entirely.
This is by far the most impactful strategy an organisation could take. Not only will it lock up teams for a long time, it will also slow down the creation of new features. Hiring an external team or outsourcing the work to an off-shore team could help overcome these impediments, but you give out knowledge to your vendors. This is a tradeoff each organisation has to make for themselves.
Rebuilding an application from scratch also comes with huge advantages. Not only can you integrate the latest technology stack, you can rearchitect the application from the ground up, keeping what works well and eliminate what wasn’t used at all.
Replace
If the aforementioned strategies are not a fit, maybe there’s a commercial product or service available that accomplishes the goal of the application. Especially for standardised systems there’s now a cloud service available, commonly referred to as SaaS or Software as a Service.
For a monthly or yearly fee, you can enjoy the same functionality while outsource the maintenance of the service. Examples are E-mail, CRM/ERP, HR tools, Document Management, Electronic Learning Platforms (ELP), and many more.
Although replacing a custom system with a standardised commercial solution might seem simple, there’s a lot of complexity underneath the surface.
- How to solve issues where the commercial product does not deliver a functionality required by the organisation?
- How easy can we re-train and on-board users on this new solution?
- How can we connect with our existing integration layers and external partners?
- How are upgrades provided by the vendor and what kind of impact do they have on our daily operations?
Not surprisingly, replacing an existing solution with a commercial off-the-shelf product or service takes often longer to fully complete than rebuilding the existing solution from scratch. The benefit comes in the long-tail where all support and maintenance costs are now replaced by a monthly or yearly fee.
Modernisation Lifecycle
The road towards modernisation takes a few essential steps that will ensure a successful result.
- List and prioritise applications: In this phase we collect all essential technical and business information regarding the applications that require modernisation and come up with a prioritisation based on urgency, business criticality, and technical blocking factors
- Define modernisation strategy: For each application we define the best suited modernisation strategies based on the information gathered in the first phase
- Approve strategy: Together with the organisation, we select the modernisation strategy that will be approved to work on.
- Modernisation cycle: Each application, depending on their chosen modernisation strategy, must go through either rehost, refactor, rearchitect, replace or rewrite steps to be completed
- Confirmation of efforts: When each application is modernised, all stakeholders confirm that the objective is met and the rejuvenated application is operating successfully
- Next steps: Now that all applications are modernised and operational, next steps can be discovered to fully optimise the chosen modernisation steps like cost efficiency improvements, disaster recovery optimisation or high-availability requirement adjustments
In the case of our example scenario, the urgent exit might require a rehost approach first, but as next steps a new modernisation process could be the solution.
A decade of modernising applications
For the past decade, our engineers have worked together with organisations modernising their portfolio of legacy applications. Either it was because of an urgent datacenter exit, or it was because teams were no longer able to provide new functionality to their existing applications.
You too can benefit of our expertise to modernise your application portfolio and add an additional decade to the lifespan of your business critical applications.
