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.