Azure

What Is Meant by “Cloud Migration Triggers”?

Marty NickisonLeave a comment

In a previous post, you learned that the two main reasons a cloud migration is initiated are to improve performance and/or to reduce costs. While this is true, cloud migration is not a regular discussion for the bulk of Information Technology departments within enterprises worldwide.

While this topic is discussed more often than five years ago, it’s not as common as discussions about server decommissioning or system patching. So, it’s not common, just more common than usual (now say that ten times fast … No prize, sorry).

These conversations are more likely to happen after a trigger event. Basically, they take place after events that open the cloud as a potential solution. Common events that can lead to discussions about cloud migration are called ‘cloud migration triggers’.

Cloud migration triggers are the events that are likely to happen to an enterprise, which will commonly lead to a discussion about cloud migration as a solution to the issue(s) at hand.

So, what are some of these ‘cloud migration triggers’?

Some of those triggers are:

  1. Threats to the security of computers and computing resources
  2. Need for the ability to quickly scale up/down for the needs of specific applications/data sets
  3. Cost concerns, aka reductions of the going-forward budget
  4. Needs for redundancy of data sets or computational power across multiple geographies
  5. Options for avoiding renewal of datacenter contracts (e.g., the renewal comes with a substantial increase in cost for similar services)

What will happen is that one or more of the above will become a trigger for the enterprise. As a result, the company will start having internal discussions about the cloud being a possible solution to the problem(s). So, in short, cloud migration triggers are common situations that lead to a discussion about moving a company’s computer-related assets to the cloud.

What Is Meant By “Guest Machine” and “Host Machine”?

Marty NickisonLeave a comment

Imagine that you are hired to help migrate 20 servers to a Microsoft Azure cloud tenet. The servers are all VMware virtual machines running on two separate 4-host clusters and are accessible via the local vSphere 6.7 install.

At the initial team meeting, everyone introduces themselves to the group. Primary assignments are distributed afterward. Your primary assignment is to compile a list of all the guests and hosts in that instance of vSphere.

Additionally, you are to compile the following information for all the guest machines (per guest):

vCPU count
Memory size
Hard Disk 1 size (primary boot drive)
Whether the most recent VMWare Tools are installed on it

You instinctively know this is nothing more than a table. You can research this data and put together a simple Excel spreadsheet with this information … you only have one problem:

WHAT IS A GUEST MACHINE?

You pull a colleague to the side at the breakfast counter before the next workday and ask them this question. You also explain you are new to VMware and are learning the terminology.

They respond with, “It can get confusing, I know. Just remember: the guests run on hosts.”

They then run … cold vegetarian omelets are not a great way to start the day, as you know from your college dorm years.

OK, WHAT IS A HOST MACHINE?

Think of it this way. Let’s imagine you have a friend over to visit your home. You are the host, and they are the guest.

The host owns most of the stuff inside the home and also the house itself (assume homeownership). The guest can gain access to many things in the host’s home, but at that moment, the guest and what they can do is limited in some way to what the host has to offer.

This is similar to guest and host machines. The host has all the resources, and the guest is utilizing the host’s resources as much as possible and as needed. In this sense, the host is the hardware, and the guest is the combined operating system and applications.

So, in short, a guest is the operating system and the things that run on it, and the host is the computer hardware and parts that the operating system is running on.

Another way to think of this is to say, “the operating system and applications (guest) are hosted on the hardware.”

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

Marty NickisonLeave a comment

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.

CONGRATULATIONS! IT WORKED!!!

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.

WAIT! PROBLEM! OHDCFILEServEX1 is now titled “OHDCFILEServEX1(LEGACY_DELETE03272025)”…

WHAT IS THIS?!

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.

YOU GET AN ANSWER:
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 “Tenet Admin”?

Marty NickisonLeave a comment

Let’s assume you are working on a new project with a team of 10 Information Technology professionals.

A company (let’s call it Nickison II, LLC) is buying part of another company (we’ll call this company Marty’s). The deal includes a total transfer of ownership for six applications. Let’s call these applications Quickbooks Desktop, WordPress (local install and configuration], Office 365, Dynamics CRM, Microsoft SQL Server 2016, and Teams (with the phone service add-on).

The team is now assembled, and the work on planning begins. Everyone (including yourself) is excited to start this major company initiative.

In the initial discussions, the election of tenet admins takes place. No one volunteers for the task, so you and the resident Microsoft Azure cloud guru are nominated to be tenet admins.

You are now thinking, “What in the world did I just get signed up for?!”

The good news is this:
What you need to accomplish this task is not work-intensive.

The bad news is this:
Once you become a tenet admin, you have the rights to do almost ANYTHING in the tenet rights assignment arena … and with such privilege comes massive amounts of responsibility and accountability.

So, what exactly is meant by “tenet admin”?

Basically, you will grant rights in the Microsoft Azure tenet to assign rights to any resource (people, deployment, services, and so much more) and be able to change the assignment rights level at any time as you wish. In most cases, your user account to the specific Azure tenet will have its rights increased to Owner role access (in some more restrictive deployments, the account will be elevated to co-contributor level).

So, in essence, you have volunteered to be a top-level admin for the tenet.

Others will now call you when new account access to the tenet needs to be established (for new users or services). Additionally, expect to have emails sent to you when access needs to be adjusted or removed. The latter, for example, could be the result of people leaving the project or company altogether.

To be frank, a tenet admin is someone who has owner or co-contributor access to a tenet. With this right in place, the person in question can now administer access to the tenet.

What Is Meant by “The Migration Is Not Done Once All the Servers Are Migrated”?

Marty NickisonLeave a comment

Congratulations!

You have migrated the last of the servers from the datacenter into Azure VMware Solution’s Azure Private Cloud. You can see all of the migrated VMware guests listed on the new vSphere instance with three ‘virtual’ hosts load-balancing the full load of all servers that have been migrated (for now, let’s say you migrated a total of ten virtual machines). The servers are all running without operational issues in the AVS vSphere. Furthermore, you don’t see any alerts in the details tabs.

CONGRATULATIONS! YOU ARE NOT DONE!

WHAT?
WHAT GIVES?!

For anyone who plans to move into cloud migration engineering or architecture, please keep the following phase locked into your memory: “THE MIGRATION IS NOT DONE, JUST BECAUSE ALL THE SERVERS ARE MIGRATED.”

…let me explain.

Yes, getting the physical servers migrated is a major accomplishment! You should feel like a load has been lifted off of your back. However, do not be tempted to think you’ve completed your migration work just because the servers are up and running in the new environment.

Here’s the key: the migration is done when the clients are operational in the new environment.

The difference is the presence of post-migration workloads. Once the servers and related infrastructure are migrated and tested while working, you have to ensure the clients can get to the new location and that the testing results align with pre-migration results.

Specifically, the migration is done when the clients are working the way they used to before migration into the new environment with few changes to the overall work approach and execution.

Remember, we are migration engineers and architects who work to serve the clients’ needs (company, customers, etc.). IT’S ONLY WHEN THE END-USERS ARE WORKING ‘NORMALLY’ IN THE NEW ENVIRONMENT THAT WE CAN START TO CONSIDER THE CLOSURE OF THE PROJECT WITH SUCCESS.

…NEVER forget the above.

What Is Meant By “Cloud-Based Application”?

Marty NickisonLeave a comment

When an infrastructure is being migrated, one of the main goals is to clearly understand the architecture of the environment that will be migrated. Specifically, you want to know about the servers, networks, backup schemas, databases, applications, and client-access routines for all devices involved. When you have a good understanding of the general scope of migrating entities, you are in a much better position to plan the migration effectively and execute it with success.

One of the many questions that you should ask for clarity on is, “Where is the application housed?” For most applications, you will get one of the following responses: cloud-based or on-prem.

So, let’s quickly clarify the meaning behind the first answer — ‘cloud-based.’

When an application is defined as cloud-based, it has the majority of its code and related operational assets (e.g., data warehouses, related applications, licensing structures, update schemas, etc.) located in a network/data center that is both logically and geographically separated from your ‘on-prem’ network.

Other popular names for cloud-based applications include:
SaaS [Software as a Service]
Hosted Applications
Paid Service

One popular example of a cloud-based application you may be familiar with is Microsoft Office 365. For this application, you pay a rate (yearly, monthly, etc.) to use all the software and underlying infrastructure located in datacenters owned by Microsoft (servers, databases). The rate includes technical support and guarantees that you are running the ‘latest’ updated and secure program.

To keep this short, a ‘cloud-based application’ refers to an application and related data infrastructure located in a data center usually owned by the software vendor or one of their sister companies.

What Information Should an Application Portfolio Contain?

Marty NickisonLeave a comment

Imagine you are part of a team.

The task is to migrate the cold datacenter to a Microsoft Azure subscription. You have some information already. It has been determined that 10 total servers will be moved. The servers are all currently shut down (hence, the term ‘cold datacenter’).

The team’s current task is to create an application portfolio. Currently, some team members have a single question:

“What is an application portfolio, and what should it have in it?”

An application portfolio is a dataset of information about all the application ‘in scope’ (in play, so to speak). Essentially, in this case, the applications in scope are the apps that will migrate to Azure.

Now, the bigger question:
What things should an application portfolio contain?

An application portfolio can contain anything relevant for each in-scope application slated for the target migration. However, in my experience, the following information should (at a minimum) be gathered for each application:

  1. The principal professionals involved with both the migration of applications and this application in particular
    They may include Business Analyst, Project Manager, IT Consultants, Infrastructure Management, Database Manager, Network Administrator, Migration Lead and Migration Secondary OnCall, CyberSecurity Engineer, Virtualization Engineer, and more.
  2. A list of the known POTENTIAL risks that can present themselves
    These application portfolios will mature and evolve over time, and one of the goals is to resolve all known risks and assumptions.
  3. Specific information about the application
    ⦁ Is there a support contract for the application, an expiration for the contract, and a due date for it to be renewed (at a discount to the purchase price)?
    ⦁ How many users are licensed for the application and license key IDs?
    ⦁ Who is the current SME (Subject Matter Expert) for this application?
    ⦁ Is the application fully contained in a company-owned datacenter, or is it partly or fully cloud-managed or from the vendor in a SaaS design? SaaS means Software as a Service — basically, you rent the access from the vendor’s datacenter via web access.
    ⦁ What is the current version of the software available from the vendor and the current version in scope for the migration?
    ⦁ Is there a list of the names (usually NETBIOS or Fully-Qualified-Domain-Names) of all the servers related to the application, the IP Addresses for all the servers previously named, as well as any/all related database warehouse server names/IP Addresses and any access accounts used by procedures in conjunction with the application?
    ⦁ Do you have any and all ports used by the application? Any cloud-related URLs and ports?
    ⦁ Do you know the application vendor’s name, website, and addresses, both physical and email?
  4. The accounts needed to run the application, such as:
    All membership groups for users that utilize the application, any shares needed to be set up for the application to work (and what they are currently called and where to locate them), and other applications needed to help this application operate properly.
  5. Links to documentation
    These links should support a better understanding of how the application is installed, configured, maintained, and constructed.
  6. The agreed-upon plan of the steps that will take place
    This is done to properly migrate the application and related assets.
  7. The timetable of when the migration will start and complete
    A Gantt chart is a plus here.
  8. An idea of how the migration will be tested for post-migration success
    Devise a plan on what specifics need to be tested before the application goes live and how you’ll go about performing the test.
  9. Contingencies that must be resolved
    Specifically, focus on the circumstances you must sort out before the migration can begin, such as upgrading the application to the current state, upgrading the datacenter infrastructure in preparation for migration activities, etc.

Answering as many of the questions above as you can help solidify an application portfolio with the substance to support a successful migration

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

Marty NickisonLeave a comment

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.

What is meant by “Automation”?

Marty NickisonLeave a comment

One of the goals of utilizing Information Technology tools and resources is to build a process. The process is a step-by-step plan that can take you from a pre-planned state to a predetermined result. You can execute this process multiple times and usually get similar results.

Having a plan makes getting results easier. You do not have to expend time and energy remembering what worked and didn’t work, trying to replicate the results. The process gives the owner peace of mind regarding execution and the inner knowledge that they know what to do, and it will probably work as written.

Once the technology professional has a PROVEN plan/process, the next stage is to determine the tools and resources that can help reduce the amount of human interaction required to execute the tasks. Once those tools are selected and configured for the appropriate steps, the process is then verified, and more tools are found until you have the process running without human interaction as much as possible.

Automation is the practice of taking a specific process (of steps/stages) and finding tools and resources to complete steps in that process without human interaction.

A process is fully automated when no major human interaction is required to complete it fully. This is the ultimate goal of many technologists — to create the process, then fully automate it.

In short, automation is the process of removing manual/human interaction from the completion of a process with expected starting points and end results.

What Is Meant By “Control of the Tenet”?

Marty NickisonLeave a comment

One of the more commonly-discussed ideas in the migration space is “control of the tenet.” However, there is not a lot of discussion about this important aspect of Microsoft Azure migration in courses. Let’s fix that deficiency by discussing what control of the tenet means in-depth.

First, a tenet is an instance of Azure AD combined with the resources that utilize this specific Azure Active Directory instance. For each tenet in the Microsoft Azure cloud, there exists a Microsoft Azure Active Directory instance that is specifically allocated to it. All the resources (virtual machines, network security groups, M365 [Office 365], etc.) that are related to that Azure AD instance are also built as resources (members) of the tenet.

Now that we understand what a tenet is, we can quickly discuss what is meant by control of the tenet. Let me start with a short story.

Imagine you decided to learn more about Microsoft Azure. You have a credit card and sign-up for the free tier (a small subset of all the available resources in Azure that you can use for free). You name the subscription. Furthermore, you set up billing so that when the monthly bill reaches $20 USD (by accident), all the resources are turned off for the month. You are quite the cost-conscious person!

You want to share your work with three fellow IT technicians who are also learning more in Azure. You have their email addresses and full names, so you create three new Azure Active Directory guest accounts.

The next question is:
How will rights in this tenet be assigned?

You need to have ‘owner’ and ‘co-contributor’ user Role-Based Access Controls (RBAC) set up and add each account to the subscription. How will you set this up?

When we discuss control of the tenet, we refer to the person who will have owner user RBAC rights and Global Administrator resource rights in the Azure AD. In this instance, you decide that you alone will have control of the tenet. All of the other technicians will each have ‘co-contributor’ user RBAC with all the subscriptions added to their accounts with the Azure AD resource role set to ‘Global Reader.’

In this way, your colleagues can see all the data yet be unable to change it. Only you will have the right to change things across the board.

So, simply stated, control of the tenet refers to the person/people who can make any changes in the Azure tenet they desire and get the changes to save and be implemented.

This question will be important for any migrations to Microsoft Azure you run into. Who will have control of the tenet? Will it be the CISO (Cyber Security Chief Officer), CIO (Chief in Information Technology department), the Cloud Administration team or the IT Support team? Or will it perhaps be the IT Management or even a third-party MSP (Managed Services Provider)?

The answer is contingent on the perspectives of all the stakeholders.