In earlier blogs we have discovered the agility inherent in Cloud, but how do organisations manage to tap into this, with all their legacy systems? In this blog we will cover the strategy and issues involved in migrating a large systems estate.
We will start by assuming foundational Cloud concerns for financial organisations such as regulator engagement, user and data management, systems placement strategy, project charge-backs, cyber monitoring and operations (such as OS standards, anti-virus, utilisation, failover etc.) have all been addressed. In reality each of these is a major area of work in its own right, but we will skip these for today, so we can think about migration itself.
The 6 Rs – a standardised approach for migration strategy
While financial organisations have been cautious in embracing Cloud, an unexpected benefit is that the experiences of other companies provide learning on how to perform a successful migration. This approach is commonly called the 6 Rs: Retain, Retire, Rehost, Replatform, Repurchase and Refactor.
Let’s start with the easiest – Retain and Retire.
It is not a given that all systems should be deployed on Cloud. There are many underlying reasons: some may be too mission-critical; they may be required to run in a specific location; their operating costs might be very low; their software might not run on Cloud (mainframe solutions), etc. Whatever the reason, these systems will continue to operate on-premises.
Other systems could just be turned off, but no-one has been able to do so previously. These may have been workarounds or point solutions which already have replacements available, but the cost/effort of the work to move to the replacement has never been prioritised due to the low relative ROI.
Having identified the systems to omit, the rest should be migratable. In deciding how to move each one, there are basically four choices:
- Rehost (commonly termed “Lift and Shift”), where Cloud is used only for its IaaS benefits. The system is moved with no change to its software or any of its dependencies (such as databases and integration). This can seem the simplest approach, but can be problematic, as we will discuss below.
- Replatform is an extension of Rehost, which takes more advantage of Cloud by changing some of the system to use PaaS services. A common modification is to switch to a managed RDBMS service rather than run the existing database on virtual machines and continuing to yourself manage scaling, failover, backup and recovery.
- Repurchase represents a decision to switch products entirely, typically to a SaaS solution. These are usually “cloud native” with high availability, scaling and global reach built in. As an example see Clarus Charm.
- Refactor (or Re-architect) is a full or significant rebuild of the existing system, to transform it into a cloud native equivalent. This is generally the highest risk (and costliest) approach but it can offer more flexibility to meet future business strategies. For example, monolithic and difficult to change solutions could be recreated as a set of microservices providing distinct, clear features, allowing reuse and accelerating the pace of change across the organisation.
Migration Scheduling
Having identified the right approach for each system, the next stage is to plan the migration sequencing itself.
Each of the 6-Rs requires different steps to migrate a system, with their own costs, management and delivery implications:
Additionally, each organisation will have its own view on the investment available and operational risk appetite for the migration.
By categorising the inventory of systems that can be migrated along dimensions such as migration complexity, regulatory complexity, costs, systems integration, data classification, user base etc., it is possible to collate systems into tiers of low, medium, moderate and high overall migration risk.
Typically, organisations start with a small number of the low risk systems (i.e. those with no major regulatory, reputational or technical challenges) to demonstrate the feasibility of migrating, whilst establishing standard approaches (or patterns) that can be followed by similar systems. These initial migrations also prove out that the foundational elements mentioned earlier work as intended or if not, can be modified with low impact.
This method can then be repeated with the next tier of systems, again identifying the patterns for migration and modifying foundational elements as needed. Formalising the migration via successive risk tiers in this way helps (and informs) conversations with regulators, by providing transparency and demonstrating that controls are in place both for the migration itself and subsequent normal operations.
In addition, the patterns can be followed by many IT and business teams across the organisation, allowing multiple systems in a tier to be migrated concurrently and shortening the overall time to move to Cloud.
Rehosting challenges
Whilst Rehosting appears the simplest approach to migration, legacy vendor systems can present significant challenges:
- They are typically supported on a limited range of hardware and operating systems and often require specific database and other products. Any one of these might not be supported in Cloud, which necessitates working with the vendor to build, test and support a new version of their system. The vendor might insist this new version is only available as an update to their latest software, necessitating the organisation first upgrade prior to a cloud migration.
- The system (or one of its dependent technologies) may have licensing clauses that prohibit deployment on Cloud. Perhaps the licensing cost model considers the physical hardware rather than virtual hardware, or might not consider Cloud install ephemerality (e.g. short-lived Dev and Test environments). Renegotiating can take time.
- Mature vendor systems will have been integrated into the organisation using middleware (e.g. MQ) that is not cloud native. Post migration, the organisation will be building cloud native solutions, so further work is necessary to abstract and hide this middleware whilst ensuring its scalability, data consistency and failover.
- As an IaaS migration, the system and its dependencies are still managed and operated by the organisation’s staff. This provides limited or negative IT cost benefits: hardware cost saves are offset by the need to create and support new processes to handle failovers, scaling and backup.
In such situations, it is often helpful to think about the functionality of the vendor system that is actually being used, and whether this can be partially or fully replaced by one or more SaaS solutions (i.e. adopting a hybrid rehost/repurchase migration).
Removing reliance on some of the vendor system features can reduce the integration and IT management effort post migration, as well as simplifying discussions with the vendor on licensing and the scope of software changes.
Summary
Adopting a structured migration approach supports a low risk, learnings-based way to adopt Cloud, that can scale out across the organisation.
The 6-R model provides a successful way to select the appropriate migration for each system, and risk-based tiering helps drive the timing of migrations.
Migrating legacy vendor systems can present significant challenges due to the dependency on the vendor(s) to assist, given their own commercial interests.
SaaS vendors such as Clarus are built natively for the Cloud and offer significant advantages in ease of use, scale, availability and cost.