Moving legacy applications to the cloud can be challenging. Richard Blanford, Chief Executive, Fordway, explains how businesses should approach the migration process
As organisations increasingly consider moving their applications to the cloud, they will find that these applications can be divided into two broad categories. Some, where a suitable, fit for purpose and cost effective Software as a Service (SaaS) service is available, will be relatively straightforward to move. Others, which may be core to the organisation’s daily activities, fall into the category of ‘legacy’ applications, and here the choice is more complicated.
The ‘easy wins’ are services such as corporate email and desktop productivity tools. SaaS services such as Microsoft Office 365 or Google G-Suite provide everything needed, are easy to use and have costs comparable with in-house provision. Disaster recovery also comes into this category: public cloud is an excellent and cost-effective option for most organisations’ DR, as you only pay for data stored plus servers as you use them. Public cloud providers allow you to copy data into their cloud for free, and apart from regular DR tests and any servers needed to manage data replication, all other servers can be held in a suspended state, not incurring charges, until DR is invoked.
Legacy applications can include everything from bespoke applications developed in-house to well-known applications which have been customised to organisational needs and where the software provider’s SaaS offering, if available, cannot accept the customisations. For example, local authorities typically use highly customised applications for services such as parking management and waste collection, and most organisations will have tailored their ERP applications to suit their needs and processes. Legacy applications also include older versions of applications that cannot be moved to public cloud without first carrying out several upgrades, such as applications hosted on an outdated SQL database.
Many application providers are developing their own SaaS services, but often these only support the latest version of their software and cannot accept customised applications or add-ins and extensions developed by third parties. We have investigated many such applications for our customers and all too often the vendor will simply maintain a dedicated instance of the customer’s software on a public cloud service, then charge a premium price for doing so.
Organisations who would like to move their legacy applications into the cloud have three options: cloud re-platforming onto Infrastructure as a Service (IaaS); Platform as a Service (PaaS); or managed cloud SaaS.
With cloud re-platforming onto IaaS, the organisation moves its application, as-is or with minor enhancements, to operate from a cloud provider’s infrastructure. They no longer have to own, operate and manage the infrastructure on which their application is hosted and are freed from the associated day-to-day responsibilities and costs of running it, but still maintain existing licence provision and support with the application provider. However, the cloud provider only provides hosting, including host and hypervisor patching and proactive infrastructure security monitoring. Patching, resilience, back-up, security, disaster recovery and application support and maintenance inside the instance still need to either be designed into the cloud environment or provided by a trusted third party, and the service will still need monitoring and management.
To avoid retaining this responsibility, organisations can choose Managed IaaS, offered by Fordway and a wide range of other suppliers. This typically includes provision of the operating system, monitoring, patching, authentication and specific security, including a dedicated firewall, as standard. Managed IaaS services effectively offer a legacy application back to the originating organisation as a SaaS service.
With PaaS, the cloud provider provides both hosting and a secured and patched base application, such as a database or development environment, onto which the organisation installs and manages its own tailored application or code. The in-house team retains responsibility for maintaining the application, access and authentication to the service, plus application and code patching. However, as stated earlier, public PaaS services are generally based on the current versions, and so if your application does not support or is unable to be easily migrated to the latest version it probably does not make business sense, in which case the organisation will need to use IaaS instead.
In managed cloud SaaS the organisation transfers responsibility for all aspects of the application to a third party provider. The provider customises the service to the exact characteristics required and provides a tailored service, which includes securing any client data hosted within the service. The only responsibilities which have to be retained in-house are authentication to the service and data transfer between service providers. However, this usually requires significant customisation of the SaaS offering, or the organisation has to accept the loss of the customisations and enhancements it has developed.
With a range of options available, organisations need to consider which is the best solution for their business strategy. They are likely to find themselves using private cloud or managed IaaS as a staging point for some applications until more appropriate public cloud services become available. For most, it is likely the optimum solution at present will be a hybrid of public cloud, managed cloud and in-house service provision or private cloud.
Whichever combination of cloud services is chosen, every organisation still needs to retain responsibility for ensuring that its chosen cloud provider offers and can meets the required SLAs and is suitably financially secure to continue to deliver the required service for many years to come.
For more information visit www.fordway.com
About Post Author
