What Does the Phrase “Migrations Are Not in a Silo” Mean?

Imagine this…

You have joined a team that will migrate an entire (one) VMware vSphere instance to Azure with the Azure VMware Solution. It has been six months, but a lot of progress has been made with the team (including you, of course).

You have:

  1. Created a scope of all servers included and cross-referenced those servers to applications each supports
  2. Designated Azure Infrastructure tenet admins and created co-contributor access accounts in Azure AD to support this project
  3. Created a special owner group in Azure AD called “Security Oversight Azure” and included everyone who is a current member of the “SECOps Private Share 1” group
  4. Created a Windows 10 VM ‘jump box’ and ensured all team members could access it
  5. Worked with the IT Network Engineering Team to construct a valid design for access to the new private cloud for the AVS (Azure VMware Solution) vSphere instance
  6. Had Microsoft start a new AVS Private Cloud instance in the company production Azure tenet
  7. Coordinated with the Network Engineering Team to have Express Route devices and configurations set up from the physical datacenter where the hosts are located (in this instance, let’s say the datacenter is located in Ohio, United States) to the Azure datacenter where you are going to have AVS ‘stood up’ in (in this instance, let’s say the target AVS’s primary location is Virginia, United States)
  8. Used the information provided by the Network Engineering Team to configure the AVS instance in Microsoft Azure
  9. Downloaded and installed the HCX appliance in your local vSphere instance with the proper configurations
  10. Performed a test migration using HCX on some legacy “not in use/scheduled to be decommissioned” virtual machine guests in the vSphere at the Ohio datacenter. The guests contained a mixture of operating systems — including Microsoft Windows 2019 DataCenter and Oracle Linux 8.x.


Now, you are tasked with assisting the team in moving more servers. In compliance with the schedules of the application portfolio sub-team, you are going to migrate five more servers next weekend. In this instance, these servers (guests) are:

1. OHDCFileServGP1 File Server in Ohio Datacenter for non-executives 1

2. OHDCFileServGP2 File Server in Ohio Datacenter for non-executives 2

3. OHDCFileServGP3 File Server in Ohio Datacenter for non-executives 3

4. OHDCFileServGP4 File Server in Ohio Datacenter for non-executives 4

5. OHDCFileServEX1 File Server in Ohio Datacenter for C-Suite executives 1

As a proactive migration professional, you make sure all the servers above are currently listed in vSphere as running, and you can currently log into them.



Well, you start asking your team members about this via group chat in Microsoft Teams. Furthermore, you provide pictures of what you see (THANK YOU, SNIPPING TOOL). The team was not aware of this, so they use the team liaison to reach out to the onsite System Engineering team.

Change Management Record CR010272008 was completed 33 days ago. The fileserver was moved to Azure Storage and placed in a blob storage container with multi-factor authentication. Apparently, an executive’s account was compromised, and swift and decisive action was taken to assure the future security of all executive data.

Why was the team not aware of this emergency change, and WHO IS RESPONSIBLE FOR UPDATING THE TEAM ON SUCH WORK?!

Questions are asked, and in the future, team members are designated to join the Change Management weekly approval call to keep aware of the changes coming for anything that might impact the project plan.

Now — Here’s how that whole story fits into the question:

What does the phrase “migrations are not in a silo” mean?

In the illustration above (as with many special projects in general), the team was focused on the objective at hand — migration to Azure VMware Solution. They spent time and resources to make sure they were continually moving towards that goal. In this respect, the team was doing what they should have done.

However, Information Technology is a continually changing entity in corporations.

While the team is working hard to accomplish the goal(s) at hand, other information technology projects and initiatives are being accomplished in real-time. Any IT project team needs to keep an eye on other projects that can potentially impact the project at hand. Failure to do so can potentially bring CATASTROPHIC results to the project, for instance:

  1. Task accomplishment delays
  2. Significant increase in cost waste for the project
  3. Required redesign of the project plan
  4. COMPLETE INVALIDATION OF THE PROJECT — Basically, making the project irrelevant

Essentially, you have to keep an eye on other projects that are going on while you work on your own project(s). MIGRATIONS ARE NOT IN A SILO — other projects and changes can affect the migration in multiple ways.

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.