What Is the Meaning of “Lift and Shift”?

Picture this:

You are working with a team of people tasked with migrating the supply chain servers and related applications, databases, websites, and more from the datacenter in Atlanta, Georgia, to a Microsoft Azure tenet. There are ten servers in total, and all were built in 2020. They each:

Run Windows Server 2019 Datacenter
Are Dell PowerEdge R820 16-Bay Servers containing four 2.20Ghz E5-4607 Six Core Processors and a total of 64 GB of Memory
Have a local RAID-5 configuration of two sets, each of 3 drives per set of 500MB SSDs for a total of 2 logical drives per server, each having 1TB of logical space

It is determined that we will use the Azure Migrate Tool to move each server to a suitable Azure VM in the new tenet named ‘Supply_Chain_202202.’

The latest information pertaining to this migration is that it will be a ‘lift and shift’ for all ten servers.

So, the grand question is:
What is the meaning of ‘lift and shift’?

Let’s assume for the sake of clarification that you have a portable fireproof safety box (like a SentrySafe 1200 Fireproof Box) which contains twenty 100-USD bills and ten 500-EUR bills. You have to move all the bills (USD and EUR) to a storage facility owned by a national conglomerate.

In the example above, taking the locked SentrySafe 1200 to the storage facility and locking the box with the bills inside the storage facility is ‘lift and shifting’ the dollar bills. The other main methodology is ‘re-homing,’ which is taking the dollar bills out of the SentrySafe 1200 and placing the bills by themselves directly into the storage space.

Essentially, ‘lift and shift’ is moving the server ‘in one whole piece’ to the new location (in this case, Microsoft Azure). In this instance, it can be done using the Azure Migrate Tool process.

To clarify, ‘lift and shift’ moves the complete entity as one piece, while ‘re-homing’ refers to creating a new entity in the new location and just shifting the data and configurations.

What Is Meant by ‘New Builds’ When Discussing Cloud Migration?

Let’s assume we plan to move two applications from the local datacenter into a Microsoft Azure subscription. We will call the applications “LiftAndShift” and “NewBuild.” For the purpose of simplicity, let’s assume each application is hosted on one server: “LiftAndShift1” and “NewBuild1”.

First, we create a space for these servers and applications to live on.

Since they share data and talk to each other via shared folders on each server, we decided to create a single tenet that will ‘house’ both servers above.

Next, we meet with the application portfolio team, stakeholders, and power users.

This meeting happens so that we can agree on a sequence of events for moving these two applications. This agreement is CRITICAL as both servers need each other, and we must minimize the risk of downtime while this migration takes place. Furthermore, we must test as many things as we can as we go through this process.

We decide to use the Azure Migrate Tool to move “LiftAndShift1” first. This server is currently a virtual machine hosted on a VMware EXSi cluster of hosts running ESXi 6.5 Update 3 (build 13932383). We then download the Azure Migrate Tool from the Microsoft Azure tenet we created.

Next, it is installed as an appliance (*.ova file) into vSphere. Finally, it is configured with an Admin-level account for both SQL on-prem and the Windows Active Directory (SPECIFICALLY USED JUST FOR THIS PURPOSE — AS DIRECTED BY LEADERSHIP, NAMELY THE CISO).

A cutover weekend plan is established.

The prior weekend, we ran an assessment for “LiftAndShift1” using that functionality in the Azure Migrate section of the Microsoft Azure portal. Since this application is very ‘lean’ (small), the VMware virtual server on which the application ‘sits’ is also quite small.

The Azure Migrate Tool successfully completes the initial assessment and recommends two drives and a B2s target to migrate this virtual server directly into the Azure Tenet.

The cutover of “LiftAndShift1” is a success, and the afterward testing completes with no major concerns.

In compliance with the plan created above, the “NewBuild1” server will not be migrated. Instead, we will move the server via a ‘new build’ process.

Now we commence with a ‘new build’ migration.

What does this mean? Simply stated, a ‘new build’ migration is when you first create a new server in the cloud with more than enough resources to run the application, data, etc.

Next, you install the most current version of the software the server will run on. There is one pre-requisite, though; you need to engage the vendor to assure you have access to the most current software. You’ll also need to get the support contracts and proper license structures for it.

Finally, you set up another cutover weekend where all the data is copied to the new location, and the new server is configured to work with the new data copy. It then needs to be tested by the power users to assure functionality.

So, when the expression ‘new build’ is used in the context of cloud migration (e.g., migrating a server to Microsoft Azure), it refers to creating a new server so house data will be updated and then copied to that new server. The base server (operating system, etc.) will NOT BE MIGRATED using tools like Azure Migrate Tool and the HCX appliances.