Learning about the industry patterns for cloud migration

Cloud migration moves workloads from a source environment to a target environment. In most cases, the source environment is an on-premises data center, and the target environment is the cloud. This section will present the nine most used cloud migration patterns, known as the nine Rs.

Re-Host

Enterprises use the Re-Host strategy to move workloads (applications, databases, and so on) from an on-premises server to a virtual machine (VM) in the cloud without making significant changes. Re-Host is an overall strategy and is also known as lift and shift. Although this strategy makes the cloud migration process faster and cheaper, it prevents enterprises from benefiting from cloud readiness and can increase management costs even more than on-premises. Furthermore, as with other patterns, Re-Host is not always suitable for every type of workload migration to the cloud. Table 1.1 shows the benefits and limitations of a Re-Host strategy to move workloads:

Table 1.1 – The benefits and limitations of the Re-Host pattern

Re-Factor

This approach introduces cloud readiness to applications and databases to scale on demand and adopt cloud readiness features such as security, speed, and resilience. According to Gartner, the Re-Factor pattern restructures and optimizes existing code without changing its functional and non-functional behavior to remove technical debt, which later needs to be refactored. This strategy requires changing the code of existing applications, redesigning the integration between components, or replacing existing components with modern alternatives. For example, significant code needs to be changed to modernize a monolithic application to a set of microservice applications or replace a SQL database with a NoSQL database.

Figure 1.9 shows the simplified list of activities to migrate a workload from on-premises to the cloud using the Re-Factor migration pattern. Here is a list of activities to transform an as-is platform into a to-be platform:

• Containerize existing monolithic applications.
• Automate processes for data discovery, data and application dependency mapping, data movement, and synchronization.
• Replace the on-premises database with an appropriate database as a service (DBaaS), based on the data characteristics.
• Configure the application.
• Establish a DevOps pipeline.

Figure 1.9 – The activities to migrate a workload using the Re-Factor pattern

The benefits and challenges of the Re-Factor migration strategy are described in Table 1.2:

Table 1.2 – The pros and cons of the Re-Factor cloud migration strategy pattern

Re-Platform

Re-Platform is the middle ground between Re-Host and Re-Factor. Instead of moving a large set of workloads, only a few are moved to the cloud to take advantage of it. So, for example, instead of using an on-premises-hosted Db2 warehouse, which is very difficult to manage, enterprises can use the IBM Db2 WareHouse as a service on the IBM public cloud. The main benefit of Re-Platform is that it provides the capabilities to use managed services to reduce the cost and effort of operations significantly. In addition, no additional skill is required for the cloud alternative, as the components are included as a managed service. This pattern maximizes the benefits of the cloud and helps to enforce standard security for the managed service. As a trade-off, this pattern is comparatively more expensive than relocate base patterns, such as Re-Host and Relocate.

Figure 1.10 shows that applications, databases such as Oracle, SQL Server, and other middleware deployed on on-premises infrastructure can be moved to the cloud using the Re-Platform migration pattern:

Figure 1.10 – Migrating workload from on-premises to the IBM cloud using the Re-Platform pattern

Some of the aims of Re-Platform can be described as follows:

• To simplify and automate the movement from Oracle to other RDBMS (such as Postgres) on IBM Cloud data services or Cloud Pak for Data
• To adopt best practices to optimize the target database configuration for performance, HA, resiliency, and other non-functional requirements
• To containerize applications and deploy them on PaaS over the IBM public cloud

Replace

Replace is a very early stage of cloud migration. By the end of 2020, only 26% of the worldwide workload had moved to the cloud. The remaining 74% were still in on-premises data centers. Thus, enterprises are at an early stage of their cloud journey. Every step, they are learning and reinventing themselves. Therefore, it is common for enterprises to just drop existing platforms and rebuild their workloads on a public cloud environment. The benefits and challenges of the Replace migration strategy are described in Table 1.3:

Table 1.3 – The pros and cons of the Replace cloud migration strategy pattern

Re-Architect

Applications are rebuilt from scratch on public cloud infrastructure. Re-Architect can be explained as materially altering application code to shift it to a new application architecture, such as a PaaS on the cloud, and fully exploiting the application platform’s new and better capabilities from the cloud. Re-Architect pattern development can start by breaking apart application monoliths into smaller packages or microservices surrounding a more significant containerized workload, but this usually involves more significant code rewrites and, many times, a complete rethinking of how the application should be structured. Cloud-nativeness is a crucial goal for new applications.

Relocate

This strategy moves the on-premises workload to the public cloud. The difference between Re-Host and Relocate is that Re-Host ensures some optimization of the target platform through minor configuration changes, whereas Relocate does not focus on optimization. The main goal of Relocate is to move quickly to the cloud.

Retain

Enterprises often have legacy applications with complex dependencies that require major refactoring or are no longer valid for business cases. Retain is a suitable strategy for such workloads where they are identified and kept in the source environment for further processing.

Retire

Enterprises adopt this strategy to decommission legacy workloads that no longer have business requirements. In most cases, if an existing workload is not compatible for containerization or refactoring, it can be a suitable candidate for the Retire pattern – for example, they migrated the physical server on-premises to a VM on the cloud.

Figure 1.11 describes the workflow of the Retire migration pattern. Once the migration criteria are established, based on business requirements, DevOps culture, and other dependencies, workload migration takes place in multiple stages, such as planning, workload discovery, and design. Once the high-level design of the target platform is completed, the next step is to build the landing zone for the to-be platform and test its operational readiness. A continuous management operation ensures that the target platform is functioning, and the performance of the target platform is continuously measured and improved over time. Until the operation on the target platform is running at full capacity, sometimes, both the old and new target platforms are used to serve requests through load-balancing capabilities. In this transition phase, when both the old and new platforms co-exist, the KPIs and metrics for the new platform are established, using the KPIs for the old platform as a reference. Now, it is time to decommission the old VM and other legacy workloads no longer in use:

Figure 1.11 – Retiring a physical server by replacing the VM

Re-Innovate

In some cases, enterprises use the opportunity of cloud migration to re-invent themselves. For example, during the discovery phase of cloud migration, which we will discuss later, organizations might find out that AI SaaS solutions or workflow engines can replace some applications. Figure 1.12 shows that as-is workloads are modernized through Re-Innovation in the to-be state in the cloud:

Figure 1.12 – The as-is and to-be states of Re-Innovation

Let’s take the Landorous use case to understand the use case for different migration patterns. The migration strategy selection process is primarily driven by the cloud maturity model. Once the current workload is categorized, it can be planned for migration in multiple phases. In Table 1.4, we describe the cloud migration pattern selection for the Landorous use case:

Table 1.4 – The migration pattern for the Landorous use case

The key to migrating a workload to the cloud is to define a complete roadmap with detailed planning for every aspect of workload migration modernization. The next task is to define an end-to-end roadmap for the cloud migration project.