The 8R’s of Cloud MigrationBy Harry Keir Hughes, Satsang Randhelia, Vikas Tatwani January 2020 | POV | 9 min read | Email this article | Download
Moving to the cloud is critical for long-term business prosperity, but it can be difficult for large corporates with complex IT architectures and many important applications on premises. Expanding on Gartner research, our 8R framework can help organizations decide which applications to move, when and how.
There’s no doubt that cloud adoption has passed the tipping point among large corporates. Early fears about security, resilience and vendor lock-in have been steadily mitigated with new technologies and techniques. The benefits of cloud technology – flexibility, scalability, development speed – now clearly outweigh the risks.“At this point, cloud adoption is mainstream,” says Sid Naig, research vice president at Gartner, who in November 2019 forecast that the public cloud service market would grow by 80% through 2022, when it would be worth $355 billion1. Thirty percent of all IT budgets are presently allocated to cloud computing, and 83% of enterprise workloads are expected to be in the cloud by the end of 20202.
Challenges of a cloud-first strategy
CIOs face a formidable set of technology, security, operational and financial challenges in their quest for cloud supremacy. A wholesale move of hundreds or even thousands of applications from a data center into the cloud just isn’t feasible. Some applications run sensitive data that should remain in-house. Other applications are barred from public networks due to ever tightening regulations. Still others must be completely rewritten to take advantage of cloud-native features such as DevOps, microservices and dynamic scaling. A heavily used and extensively customized SAP application from 1986 might be better left on premises. The cost of moving it just doesn’t make financial sense.
CIOs must take a close look at their application portfolio before deciding which applications to move and when
Before deciding which applications to move and when, CIOs must take a close look at their application portfolio. Complex applications or those that have a high impact on business processes should be grouped together. Simpler or smaller applications that carry less business risk can be placed in another bucket. The simpler applications can be moved first, inspiring confidence, before tackling more risky data-sensitive applications. Timing of the moves must also be based on other modernization programs, software upgrade timelines and hardware refresh cycles.
What is certain is that there must be a clear-eyed consensus on the right route to take. Seventy-four percent of large corporates have moved a cloud-based application back on premises after failing to achieve the anticipated benefits of a migration3.
Many paths to the cloud
In 2010, Gartner identified five paths to the cloud, the 5R’s4. The framework helps assess which applications should be moved and how. Each R requires a different amount of upfront investment and business sponsorship.
The 8R’s extend Gartner’s thinking to factor in hidden migration costs and risks, as well as invasive code and licensing changes
Infosys’ 8R framework extends Gartner’s thinking so that hidden costs and risks, as well as less invasive code and licensing changes, are factored in.
R#1 – Retain
The application remains on premises due to technology or regulatory constraints. Or it’s found that legacy applications work well enough with low cost of ownership.
R#2 – Retire
The application isn’t meeting its objectives and retiring the application saves costs. If the application is critical to the business, it can be retired and rebuilt from scratch in the cloud to take advantage of cloud-native features.
R#3 – Rehost
The application is dropped onto the infrastructure of the cloud service provider (CSP). The enterprise still looks after web servers, virtual machines and middleware, reducing subscription costs.
This migration path is often used when an application is running well on premises (i.e., is healthy) and no further code changes are needed to do a similar job in the cloud. It might also be used when code modification is impossible, the workload is not certified for cloud, or the data center lease is expiring and a quick migration is needed. Because the platform is still owned by the organization, rehosting cannot take advantage of cloud-native features such as monitoring, security and governance.
R#4 – Remediate
Remediate is a more invasive and costly migration. The enterprise upgrades operating systems, databases, web servers or app servers in the cloud. This improves functionality, security and performance, while reducing vulnerabilities. Ongoing operating costs drop as enterprises no longer pay a premium for support services on older operating systems and databases.
R#5 – Replatform
Rather than simply upgrade, replatforming is a wholesale transformation of the underlying database (e.g., Oracle to SQL) and operating system (e.g., Windows to Linux). The app server or web server may also be changed (e.g., Apache to IIS web server). This path is often used when the licensing solution of a database or operating system is very expensive in the cloud.
Replatforming provides immediate, modest cloud benefits without much investment risk.
R#6 – Refactor
Significant code changes are made to the application to retain its uniqueness in the cloud. This path takes advantage of operating systems and middleware – typically Apache or IIS web servers – from the CSP. Because the application is optimized for the platform of the CSP, it can utilize cloud features such as dynamic capacity, horizontal scaling and DevOps.
R#7 – Rearchitect
The application is built from the ground up on the public cloud. The code must be written in a cloud-native language using expert programmers.
Enterprises often choose to rearchitect when remaining on premises is too high risk, either because it’s too difficult to patch old systems (and thus reduce security vulnerabilities) or there are no longer any programmers who understand how the application works. By rearchitecting, cloud features such as tamper detection and data encryption come as standard, while superior performance is attained through horizontal scaling.
It is worth noting, however, that only a quarter of cloud migrations use this method, possibly due to the time and effort needed5.
R#8 – Replace
The application is replaced for a comparable software as a service (SaaS) equivalent, such as ServiceNow or Salesforce. The business will not only need to make modifications to the application, but it must reengineer the entire business process.
Replacement is best when the application doesn’t do anything particularly unique, such as a CRM system. Notably, a tech poll by IDG found that 73% of companies will have replaced 80% of their applications with SaaS products by the end of 20206.
Figure 1. The optimal cloud migration strategy is based on three factors
Source: Infosys Consulting
Each R can be plotted against three factors. The first is the amount of upfront investment needed. The second is the amount of business value that will be achieved from the migration. Also important is the third, the level of business-IT collaboration necessary to carry out each R. (Figure 1)
- Investment: The time, effort and skill needed to move the application, along with the risk of remaining on premises or failing to adapt the application properly to the cloud.
- Value-add: What is the business looking to achieve from the migration? Does the application need to have higher levels of resiliency, availability and performance (speed and agility, for instance)? Or do operating costs need to drop significantly so that more exciting business critical applications get executive sponsorship?
- Level of business-IT collaboration: For more invasive R’s such as rearchitect and replace, business leaders must work hand-in-hand with IT. HBR Analytics found that with business involved, systems move more quickly and are more integrated with current business processes7. “In the quest to do a data-based analysis for migration, this step is often overlooked by IT leaders,” says Satsang Randhelia, cloud advisor at Infosys Consulting.
Once plotted out, it’s clear that those R’s in the middle of the matrix provide the best balance between risk and value-add. In fact, when we see that replace provides the best value for a moderate amount of investment and risk, it’s no surprise that the SaaS market is booming. Indeed, half of global cloud service revenues come from SaaS alone8. Here, everything from upgrading and patching software to running the data center is cared for by the CSP, reducing operating costs while maintaining application health. “Subscribing to a SaaS service versus provisioning your own environment is like buying an airline ticket versus buying and flying your own Boeing 777,” says Richard L. Villars, research vice president for data center and cloud at IDC9.
Collaboration between business and IT is vital, regardless of which R is chosen
The challenge with replace, however, is that the enterprise can be locked into a vendor. This is a key issue if that vendor falls behind the pack in terms of future innovation or cost-effectiveness.
That’s why it’s important to choose the right R depending on specific needs, whether that be increased automation, decreased time to market or the need to retain the unique features of a cutting-edge application. Whichever R is chosen, it’s apparent that the biggest determinant of success is the collaboration between business and IT. Whether the migration is outsourced or a firm decides to do it in-house – getting the change management and collaboration right is a sure-fire path to migration success.
- Gartner Forecasts Worldwide Public Cloud Revenue to Grow 17% in 2020
- Cloud Adoption Statistics for 2020, Hosting Tribunal
- 5 ways your cloud migration may fail - and 5 ways to succeed, InfoWorld
- Migrating Applications to the Cloud: Rehost, Refactor, Revise, Rebuild, or Replace?
- Making a secure transition to the public cloud, McKinsey
- Adopting Hybrid Cloud Becomes a Strategic Imperative, HBR
- See reference 5
- See reference 7