Migrating to the Cloud

In the previous chapter, we looked at the different options for storing data in Azure— specifically, Azure Storage accounts, Azure SQL, and Azure Cosmos DB.

In this chapter, we will look at how we can best leverage Azure for our existing applications that are currently hosted on traditional infrastructure.

When migrating we sometimes need to consider servers, data, and applications separately and think about the trade-off between more work upfront versus less work and more flexibility later on. Therefore, in this chapter, we will address what options are available to us and how they differ by covering the following topics:

• Understanding migration options
• Managing servers
• Modernizing applications
• Migrating data

Technical requirements

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

Understanding migration options

When migrating applications, we have different options for virtual machines (VMs) and for data. We must also choose how much work we want to perform modernizing the application before we move it. At a high level, our choices include the following:

• Lift and shift/Rehost—Leave the application architecture as-is by simply replicating the VM into Azure. This takes a complete copy of the VM—OS, application, configurations, and data.
• Refactor—Refactoring involves re-deploying your solution with minimal (if any) code changes but to Platform-as-a-Service (PaaS) components—for example, deploying a .NET app onto an Azure web app instead of a VM or a database to Azure SQL instead of SQL on a VM (if it supports it).
• Re-architect—Take refactoring to the next level by making code changes that will enable you to leverage other cloud services. This might involve breaking up a monolithic application to use microservices...

Managing servers

The simplest way to migrate services into Azure is via the lift-and-shift methodology; this means that we simply copy our existing VMs into Azure as-is.

Although you don’t leverage Azure’s best features, the lift-and-shift option enables you to move into Azure in the quickest time and with the least amount of effort.

Before we perform a migration, even one just using VMs, we need to consider how we will manage and secure those VMs. Although Azure provides a range of tools to help with this, you must build and configure those services.

In this section, we’ll consider two of these features—update management and backups. Logging, security, and networking are also important; however, we cover these separately throughout this book.

Update management

One of the key aspects of maintaining servers in the cloud is keeping them up to date with the latest software updates and security patches. Azure Update Management is a service that...

Modernizing applications

Even older applications can sometimes be partially modernized—even if you cannot move the entire system, individual components might still be able to make use of better Azure managed services. In these cases, we should always at least consider if we can refactor.

Refactoring involves making minimal changes to the application code to adapt it to the Azure cloud environment. This approach is suitable for applications that can benefit from managed services and platform capabilities offered by Azure without requiring a complete architectural overhaul. The refactoring approach is well suited for applications that have well-defined components or modules, use common programming languages, and have relatively straightforward dependencies.

Of course, a lot depends on the age of the application you are considering and its current platform. Solutions built in the past 10 years or so have a high chance of being built as n-tier architectures, whereby it is...

Migrating data

SQL Server is one of the most common database types for older, on-premises-based solutions. In the previous chapter, we also discussed NoSQL-based databases, which include products such as MongoDB or Azure Cosmos DB. However, NoSQL databases work differently, and often, the only way to migrate NoSQL to SQL, or SQL to NoSQL, would be customizing code to read the source data and write to the destination.

Although this is, of course, possible, often your solution will be designed with the underlying technology in mind; therefore, we will instead assume you are looking to migrate from a SQL-based solution to an Azure-hosted SQL solution.

We already discussed some of the different options we have in Azure for hosting SQL databases; as a recap, they are Azure SQL Database, Azure SQL Managed Instance, or SQL Server on a VM.

When choosing our desired source, we need to consider several requirements, such as the following:

• Compatibility—Does your on-premises...

Summary

In this chapter, we looked at how we migrate our existing, on-premises workloads in Azure. We first discussed the main strategies we needed to consider—lift and shift, refactor, re-architect, or rebuild.

We then looked at the options for moving the compute portion of a solution into Azure and discussed the various options for either partially or fully modernizing our solutions. As part of this, we looked at Scale Sets and Web Apps, which are great options when you want to make minimal code changes but take full advantage of Azure’s benefits.

Finally, we looked at how we can migrate an existing SQL database into Azure, what questions we need to ask, what the potential issues were, and how we can use the DMA tool to help analyze and migrate those databases.

In the next chapter, we will look at monitoring—why we need it and how to do it. We will examine the specific monitoring and logging requirements for some different components and how we can use...