Chapter 10: Migrating Workloads to Azure

In the previous chapter, we examined Azure storage use, looking at the different types available, including their benefits, and how to secure them.

In this chapter, we will focus on migrating workloads from on-premises systems into Azure. The process starts with an analysis of your current environment. We will discuss the areas you must consider, including the communication, dependencies, business drivers, and tools we can use to assist in this process.

Next, we will look at the different options when considering the would-be architecture and how we can perform migrations of VMs and databases.

Finally, we will consider how to monitor the migrated systems to optimize your new platform.

With this in mind, in this chapter, we will cover the following:

• Assessing on-premises systems
• Migration options
• Migrating virtual machines and databases
• Monitoring and optimization

Technical requirements

This chapter will use the Azure portal (https://portal.azure.com) for examples.

Assessing on-premises systems

When an organization decides to migrate its existing systems from on-premises to the cloud, the migration must be well planned and well designed. An architect's role is not just limited to the end state's design; they must also be involved from the very beginning of the process and throughout.

At a high level, any successful migration consists of the following steps:

1. Assessing
2. Migrating
3. Optimizing
4. Monitoring

The fact that the actual migration is not the final step may come as a surprise to some. However, all organizations are unique – they have different requirements, infrastructure, and various reasons for migrating.

This means that there is no one-size-fits-all solution for migrating, and once the migration is complete, you cannot wholly predict how your systems will perform. Therefore, to ensure a move is successful, you must monitor and tweak your components once your applications have migrated.

The first step...

Understanding migration options

The next phase of the migration planning is to determine how your migrated services will be built. This may be a simple lift-and-shift of one VM to a new VM in Azure, or you may take the opportunity to modify the technologies you use.

This part of the process is more than just technical decisions – you need to understand the reasons for moving to Azure; therefore, you must involve the senior decision-makers to help define the scope.

Depending on the motivation for the move, you may want to move some or all of your infrastructure. This also plays a vital role in determining how your systems migrate – not from the physical move's point of view, but the actual process you choose.

The options available when choosing your end-state architecture can be grouped as follows:

• Rehost: Also known as lift-and-shift. This is the simplest – you simply move your on-premises VM to a VM in Azure. It will also be the easiest as no other...

Migrating virtual machines and databases

Depending on how you plan to migrate into Azure, determine your next steps and what tools are required.

Refactorization, re-architecting, rebuilding, and replacing are manual processes and will need to be managed as individual projects.

There are several tools available for VM migrations, and again, the Azure Migrate tool can perform this task for you.

Migrating virtual machines

The migration step consists of three stages:

1. Replicate
2. Test
3. Migrate

From the Azure portal, in the Azure Migrate blade, in the Migration Goals | Windows, Linux and SQL Server section, you can start a replication process. The following screenshot shows the portal view after you have added the Azure assessment tool:

Figure 10.4 – Azure Migrate server assessment

You can choose to replicate up to 100 VMs at a time. Therefore, if you have more than 100 VMs to migrate, you will have to perform the process in batches.

Once replication has...

Monitoring and optimizing your migration

Azure has several opportunities for enhancing performance and security that you may not have used with your on-premises systems. It is also possible that your existing servers were underutilized or even overutilized, which can impact costs.

Therefore, once migrated, you should monitor your workloads for performance trends, security enhancements, or cost optimizations.

To support these tasks, Azure provides the following tools:

• Azure Monitor
• Azure Cost Management
• Azure Advisor

Let's look at each one to see how they can help optimize your environment.

Azure Monitor

We cover Azure Monitor in more detail in Chapter 15, Designing for Logging and Monitoring; however, you can use Azure Monitor to record and report on performance metrics as a brief introduction. By analyzing trends over time, you can gain deep insights into a VM's usage, as you can see in the following example screenshot:

Figure 10.6 – Monitoring...

Summary

In this chapter, we have examined how to build a strategy for migrating workloads into Azure. We looked at the types of issues you must consider and the available tools for collating and documenting an as-is environment.

We then looked at what tools are available to perform VM and database migrations, including the different options available. Finally, we investigated the need to monitor and optimize post-migration, again looking at the other tools available to achieve this.

In the next chapter, we begin Section 4, Applications and Databases, and we start by comparing the different types of application components to choose from when building modern, cloud-native solutions.

Exam scenario

The solutions to the exam scenarios can be found on the Assessments page at the end of the book.

MegaCorp Inc. currently leases space in a third-party data center, but their current contract is coming to an end in 6 months. They have decided to migrate some of their workloads to Azure to reduce costs. However, any move must be completed before the contract end date.

Much of their server estate consists of web applications running on Windows Server 2018 with Internet Information Services server installed, file servers, and Windows SQL servers.

Some websites run on web server farms – multiple web servers built as load-balanced clusters running various websites.

Most of the SQL servers are running standard databases, but they are concerned some older databases may be using outdated features and procedures.

Develop a migration strategy, suggestion tooling, and highlight any potential issues they might encounter.

Further reading

For more information on...