Lift-and-Shift Cloud Migrations

There are many paths to the cloud, and the one you choose depends on your particular digital transformation requirements and resources. About a decade ago, Gartner cleverly developed an alliterative nomenclature to describe five different migration strategies: the five Rs. That list has evolved over time and there a lot of 5-, 6-, and 7-strategy variations out there. Here’s one version:  

• Rebuild—rewrite the application from scratch to be cloud-native

• Replace—swap out the application entirely with a new, cloud-native application

• Refactor—rearchitect parts of the application so it better supports the cloud environment

• Replatform—move the application with minimal upgrades to take advantage of cloud benefits

• Rehost—move the entire application as is to the cloud

Rebuild and Replace both ditch the current on-premises application with the objective of implementing business logic that enables significant strategic advantage; the difference, compared to the other options, is the time that it takes to implement it, who architects and re-writes the code, who supports it, and who selects the new cloud version.

Replacing is a move to SaaS—a top choice for many enterprises. In fact, Gartner projects worldwide SaaS spending to hit $177.78 billion in 2021. Why? Enterprises view it as the path of least resistance. Their goal is to migrate business functions not infrastructure, and to take advantage of enabling technologies that can deliver a competitive advantage (AKA digital transformation). But Replace is not always a viable option, which is why Rehost, often referred to as “lift and shift,” remains a popular approach.

The upside of lift and shift

Maintaining applications on premises necessitates a lot of undifferentiated and mundane work that adds no bottom-line value to the organization. Add in the capital expenses; complex cost and licensing schemes; software, hardware, and networking issues; scalability challenges; and the need to replace hardware every 3-5 years and you’ve got a compelling case to migrate to the cloud. By lifting and shifting your application you can:

• Move to an opex rather than capex model

• Allow for redistribution of budgets

• Pay only for what you use

• Take advantage of the cloud’s elasticity

• Avoid expensive real estate commitments

• Reduce the need for multi-discipline IT skills

• Eliminate the need to overprovision “just in case”

• Increase the range and variety of infrastructure resources available to you

• Access to cloud-native services

It’s like having your cake and eating it, too. Except it’s not.

The potential pitfalls

With lift and shift, you essentially just pick everything up on top of the operating system from an environment and move it to another. The problem is that the cloud destination is a very different environment from the on-premises starting point, and there are some dangers. Here’s a simple analogy: Let’s say you’re moving to a new house. It’s pretty easy to lift and shift your display case of hand-cut crystal from one single-family home to another single-family home. The living room may be a different size and shape, but as long as you have room for it, you shouldn’t run into any problems. But, if you are instead moving to a houseboat, you can’t just plop it down and call it a day—one small wave could tilt the whole thing and reduce your collection to a pile of smashed glass. 

When it comes to lifting and shifting to the cloud, there are a couple of potential issues. One is that your workloads may not perform as well in the cloud, sometimes creating latency problems that prevent you from preserving the original on-premises SLAs. Or, you might have solved a high I/O block storage demand challenge for a workload by running it in a physical server using multiple HBAs, but you may not realize that it will create an unexpected big cost increase in the cloud, or worse it may be unfit to run in the cloud due to unavailability of computes able to handle the aggregate of all the original I/O spread across the on-premises HBAs. And, of course, by choosing rehosting over the other Rs, you’re choosing the option that takes the least advantage of cloud-native benefits. In the worst-case scenario, your migration effort fails and you have to repatriate your workloads. Unfortunately, this is far from rare. In fact, a recent survey we conducted of 350 cloud decision makers found that a stunning 72% of respondents stated they’ve had to move at least some of the applications back on-premises after migrating them to the public cloud.

The importance of planning

Despite the risks, lift and shift is a viable option—as long as you perform a comprehensive, data-driven assessment of your workloads before embarking on the migration. At a minimum, you need to take the following three key steps:

1. Baseline assessment

2. Application dependency mapping

3. Cloud mapping and cost assessment

Baseline assessment

A baseline assessment uses time-series data captured during peak hours to understand your workloads in the current on-premises environment, such as:

• Health—Are there anomalies, such as I/O aborts or chronic overloads, affecting the workloads?

• Utilization—Are there any workloads, such as “bully” or Zombie virtual machines, that are unfit for migration? The utilization time-series data is critical for rightsizing the compute and storage services required in the cloud.

• Performance—What is the minimum acceptable latency the applications can tolerate?

The baseline assessment creates the reference point for setting utilization demands, performance requirements, and SLA expectations in the cloud.

Application dependency mapping

Before you start your migration, you need to be able to answer the following:

• Which applications can migrate to the cloud?

• What should be moved together?

• In what sequence should workloads and services be moved?

• Which workloads and services should remain on premises?

The application dependency mapping process reveals the landscape of services supporting your workloads, including the workload boundaries, external/internal communication, type of network services, port numbers, bandwidth, egress cloud traffic, etc. This information helps you fully understand your workload interdependencies and consider many “what if” scenarios so you can answer those key questions.

Cloud mapping and cost assessment

Now that you understand your workloads in their on-premises environment, it’s time to turn your attention to their final destination. A rightsizing algorithm analyzes inventory data (such as storage size and relevant utilization and temporal characteristics of the targeted workloads) as well as all relevant time-series measurements (CPU MHz, memory, read/write throughput, IOPS, and network utilization) and offers mapping options based on as-is, peak,  or 99th/95th percentile values from the time-series measurements. The mapping selections will identify the best fit for compute and storage resources for the lowest cost from the latest published options for the selected cloud service provider (CSP) regions.

If you’re going to lift and shift, you need to know before you go

The bottom line is that lift and shift is a viable cloud migration option that has benefits. But once you’ve made that decision, you need to set yourself up for success by getting data-driven information before starting implementation. Virtana can help. With the Virtana Migrate module, which is part of the Virtana unified hybrid cloud optimization platform, you can get your lift-and-shift cloud migration right the first time and every time.