Why legacy applications also benefit from a cloud strategy

Written by: Bart M. Veldhuis

For years, the legacy applications have served as the core application in the landscape. They are often large and complex applications that control equally complex processes. The reliability is high, the performance moderate. Updating is a hassle: built-in customisation ensures that updates go wrong or are not possible at all. We are talking about applications that are clearly in mode 1 of the Gartner bi-modal IT concept. Clear applications that are not part of a cloud strategy? That’s a quick judgement. In this blog I discuss the benefits of a cloud strategy for your legacy applications. Because there are!

Legacy applications and the cloud strategy

If your organisation has a cloud strategy (perhaps you are writing one right now), then it is certain that with equal functional suitability, the ‘as-a-service’ variant is preferred to proprietary hardware. Certainly when it comes to applications that do not contribute to the distinctiveness of the organisation, such as marketing and sales and process-supporting applications, these are preferably purchased as a service or developed directly in the Cloud. The legacy applications are (probably) not included in the cloud strategy and there is a good reason for that. The properties of legacy applications make them unsuitable for the Cloud. If you are going to try it anyway, then this is what you will run into (among other things):

Scalability: Legacy applications are often not horizontally scalable, which is a requirement for Cloud. Or they are only scalable using clustering technology, which is certainly not a best fit for cloud environments.

Network requirements: Some legacy applications use legacy network typologies that cannot be used in a cloud environment (think multicast traffic) or client-server applications (not web applications) that cannot withstand network latency.

Licensing: a cloud deployment is often not included in the licensing model, so you can be confronted with bizarre costs for, say: your database in Cloud (I won’t name names).

Performance requirements: Cloud is naturally flexible when it comes to performance, which can vary per cloud server (unless you opt for reserved virtual data centers or ‘reserved instances’).

OS architecture: Cloud only supports X86 Intel architectures. Thus, RISC or SPARC based architectures such as HP-UX or AIX do not function in Cloud.

With brute force to Cloud?

You can try to bring an application that is unsuitable for Cloud to Cloud with all your might. However, this feels a bit like hammering a square block into a round hole: eventually it will work, but the question is what it yields. The intended benefits of the cloud strategy will not apply to the legacy application: cost savings and increased agility (by applying pay-per-use and self-service architecture patterns) will not apply. It therefore makes no economic sense to continue such a project. And because legacy applications (because of all that customisation) can often no longer be updated, this will remain the case.

The above does not alter the fact that many companies still feel the need to make their legacy applications more agile. The lack of flexibility is going to be a huge problem for organisations, if it isn’t already. For example, research agency Gartner predicted that more and more market leaders will have to give up their number one position to a company that was founded after the year 2000. The reason for this: a lack of digital business advantage. So something has to be done.

Legacy applications and the cloud strategy; a step-by-step plan

Many companies therefore have the need to make their core applications more agile, save costs, get new functions faster and connect better to the outside world. This is often part of an organisation’s digital strategy, probably with a long horizon of several years.

In such a case, start by studying the application landscape in a structured way. The large legacy application looks like a monolithic application from a distance, often represented in drawings as one large block. In practice, however, this is far from the case: such enterprise applications consist of dozens, if not hundreds of individual modules, each with its own characteristics. These modules are linked together by mechanisms such as an Enterprise Service Bus.

Stream 1: Unbundling the application landscape

Part of your cloud strategy can be to move modules that require a lot of attention (in the sense of people or system capacity) to the cloud if there is a fully-fledged alternative for this. Some of these modules fulfill functions that are also offered as cloud services. Think of CRM, Identity & Access Management, e-mail, SMS functionality, etc. The application landscape must therefore be unravelled. This “unbundling” of modules is sometimes very simple, but can also be complicated.

Select modules and bring them to Cloud

To determine whether it makes sense to remove a certain module from the application landscape and bring it to the Cloud, you want to determine whether these are modules that require a lot of work for the management organisation or that require a lot of resources or otherwise cause problems.

Let me give an example: at one of our customers we found a module that was responsible for more than 80% of the database size and 10% of the number of malfunction tickets and therefore a large number of management hours. It concerned a module that enabled the customer to call and send formatted e-mail templates. The sent e-mails were neatly stored in the database and kept indefinitely, which meant that the database of the ERP package had become unmanageably large. In addition, this module was very susceptible to failure. A short analysis showed that this functionality was also offered by the online e-mail package MailChimp and that it could be fully integrated with some integration work via the APIs (mandrill).

Another example: a module for sending automated SMS messages turned out to be very error-prone, used a lot of CPU and memory resources and generated 20% of the number of malfunction tickets. This functionality is also offered by online messaging services such as messagebird and could therefore easily be replaced.

By analysing the landscape and addressing problem cases in this way, the large monolithic application gradually becomes a lot lighter. Sometimes even more functionality can be provided, as the MailChimp example shows.

Stream 2: Replace customization with new software

We have seen that complicated customisation in an ERP package can make updating to new versions of the application difficult or even impossible. I know examples of companies that were sometimes dozens of versions behind with their ERP package. This is not only a problem for the IT operations department, but it puts a company’s entire innovation at a standstill.

Rebuilding is often the only option. By redeveloping the customisation in a modern, cloud-based Enterprise PaaS platform, the complexity of the legacy application is gradually reduced to proportions within which the normal life-cycle management process can be picked up again. The transition to a cloud-enabled version is easiest if the standard ERP software is used as much as possible.

Bringing legacy applications to the Cloud

We have now discussed two streams that can run side by side in one program:

Unbundle modules and replace them with SaaS
Replacing custom solutions with new modules on an (Enterprise)PaaS platform

This is a program that, depending on its complexity, will take several years. This reduces the legacy application to a size and complexity that enables the IT organisation to manage it as a regular application again. There is a good chance that new versions of the software will be able to run on standard X86-Intel and that major steps have been taken by the supplier to make the application cloud-worthy.

Move the development, test and acceptance environment to Cloud

Once the legacy application has been scaled down to a manageable level and life-cycle management is active again, you can start placing the legacy application in the Cloud. Start with the non-critical environments: the development, test and perhaps the acceptance environment. Once experience has been gained with this, you can consider migrating the production environment to Cloud. This saves a lot of money on licensing costs for databases, but you can also cancel expensive support contracts on non-standard hardware.

Legacy applications and cloud: a long horizon

Final verdict?

With a few adjustments and a plan, legacy systems do benefit from a cloud strategy. It just takes a little extra work. And while I can imagine sexier projects to work on, making your older, bulkier systems cloud-ready is something that can bring huge benefits (including savings) to your organisation. So don’t immediately finish serving both the legacy systems and the legacy-Cloud combination and look at what you can improve per module.

Would you like to know more about the road to a solid cloud approach and how to arrange the selection and relocation of applications?