-Welcome to Azure Essentials. I’m Matt McSpirit, and in the next few minutes, I’ll give you an overview of your options for migrating and modernizing almost any workload as you move it to the cloud in Azure. In fact, the sheer act of migration, whichever path you choose, whether Infrastructure as a Service or Platform as a Service, this opens the door to the modernization of your workloads. But more on that in a second.
-The good news is we have numerous programs and tooling experiences for migration and modernization that come together in the free Azure Migrate Tool. It’s the hub for large scale migration of your servers, databases, web apps, and even virtual desktop infrastructure. This includes streamlined discovery of the resources you want to migrate, assessment of their readiness for migration, along with the act of migration itself. Additionally, built-in extensibility with popular existing tool sets help to ease your learning curve. Now, the Azure Migrate experience is designed to be a central place to track your progress as you move to the cloud. In fact, in the next few minutes, I’ll go through some of the essential things to know as you go down your migration and modernization path, and share a few real world examples along the way.
-So, let’s start with virtual machines. Migrating VMs means moving their operating systems, installed applications, and any data contained in them, intact into Azure Infrastructure as a Service. This is sometimes referred to as lift and shift. And once you’ve migrated to Azure, you’ll continue to have control over how you manage your VMs in a similar way to how you’re currently managing your VMs on-premises. Now, there are other options I’ll get to later where the contents of your VMs, like your web app front-ends, can be extracted and directly migrated onto our managed Platform as a Service options, like Azure App Service or Azure Kubernetes Service. And the contents of your VM back-ends can be moved to PaaS databases or managed instances in Azure.
-But before I go there, let me explain how the virtual machine migration process works and some of the basics of Azure Migrate. So here, everything starts with a migration project. Within that project, you have a discovery and assessment phase that’s followed by a migration phase. For the discovery phase, bringing this back to our VMs, in most cases you’ll be using a virtual machine appliance to find or discover your virtual machines. And there are specific appliances or scripts for VMs running on VMware, Hyper-V or physical servers, along with virtual servers running in other clouds. The appliance is granted access to read details about server size, as well as running processes. And this information, including software inventory, dependencies, and more is then logged up into the Azure Migrate Service in Azure. And under the covers, the appliance measures utilization over time for VM sizing recommendations as part of the assessment.
-Speaking of which, once the discovery period is complete, from the Azure Migrate Experience in the Azure Portal, we’ll then create an assessment. And the assessment comprises a few things; Azure readiness, which is a measure of which servers are suitable for migration to Azure. Sizing recommendations for the appropriate virtual machine type if you bring your VM over to Azure, which helps to right size your VM and avoid paying for more than what you need. And finally, monthly cost, to estimate how much compute and storage costs will be post-migration.
-You’ll then use the information from the assessment phase to target the machines to migrate into Azure. When you’re ready to migrate, the process then starts by replicating running machines into Azure storage. Once the initial replication for a VM is complete, the service will continue to replicate those delta changes, and this process is block level and near continuous.
-When you’re ready to cutover and put the migrated virtual machines in Azure into production, to prevent any data loss, the final process will shut down your virtual machines on-premises and do one more replication sync into Azure. And once that’s complete, the Azure hosted VM is started up and it’s migrated. You literally just have to point your network traffic to it. Now, while I walked through the process of migrating a handful of VMs, organizations all over the world are using the same tools and processes at scale.
-For example Celcom, a telecommunications leader in Malaysia, use this process to assess more than 800 machines and migrate 50 VMs per week, while maintaining business continuity. You can find out more about Celcom at aka.ms/CelcomMechanics. And the American Cancer Society were able to cut their number of provisioned VMs by nearly 2/3, from 900 to 350, using the information from the discovery and assessment process. They then used Azure Migrate to move those 350 servers to the cloud. And you can see their full story at aka.ms/ACSmigration.
-Now that you understand the basics of Azure Migrate’s discovery, assessment and migration process, let’s move on to database migration. Now, of course, using the options I just highlighted for VMs, you can migrate a database running in a VM in the same way, except there are additional options with SQL Server to migrate just a single database or a database instance to Azure without bringing over the operating system. And this move to PaaS has a lot of benefits. So, here the assessment process begins by downloading the Data Migration Assistant or DMA, which is a Windows application that connects to your SQL Servers. Once you connect it to your source servers and your target in Azure, DMA helps you assess your database migration and find potential compatibility issues. It also logs discovered information into Azure Migrate’s database assessment, so you can manage migrations at scale. And from the Azure Portal, you can see all the details about each database instance, all the way down to individual databases, with any migration blockers, breaking changes, readiness evaluations, and compatibility levels.
-Now, when you’re ready to migrate your database or managed instance to Azure, you start by creating the service in Azure as an empty vessel to receive your data. And from there, you use the Azure Database Migration Service or DMS, to migrate your SQL database or instance. You can migrate the data while it’s online or offline. And once you’ve securely connected your source server to your target in Azure and selected which databases you want to migrate, DMS will then access database backup files and replicate those into Azure Storage. Similar to the VM replication process from before, DMS will continually replicate new backup files.
-And once you’re ready to cutover, you’ll stop incoming traffic to your database, perform one last backup, a tail log backup in SQL Server Management Studio. And once that’s complete, you perform the migration cutover, and then the production database will be running in Azure. And then you just need to make any required database connection string changes, and you’re fully migrated. And using this process versus lifting and shifting an entire VM running SQL Server means you won’t need to worry about managing, patching, or securing the underlying host OS. So, you can just focus on the data. And again, this process is proven to work at a massive scale. Capita Reading Cloud in the UK, helps manage 8,500 school libraries, and they use these processes to migrate more than 100 databases per day and 10,000 total, with just one person at the helm. Hard to believe? Well, you can check it out at aka.ms/CapitaMechanics for more details.
-Similar to the process for SQL Server migration, your web apps are likely running on servers as either .NET apps running on Windows Server or Java apps running on Apache Tomcat. So, let’s walk through that process. Starting in the Azure Migrate Portal, you use the same discovery process for VMs to inventory your on-prem servers, .NET web apps, it’ll look for Windows servers with the Internet Information Services or IAS roll installed and log that information into Azure Migrate. From there, you can create an assessment to find which apps are ready to migrate, and any issues or conditions to correct before migration. It also gives you a detailed cost estimate to run targeted apps in the Azure App Service.
-Now, for the migration itself, you have two primary options to not only migrate, but also modernize your web apps for the cloud. The first option is to use the Azure App Service Migration Assistant. It automates the creation of site resources, and then extracts and migrates web app content into the Azure App Service. And from there, it configures the required connections to backend data services, whether they are located on-prem or in the cloud. The second option, as mentioned earlier, is containers. Take for example, Eltes, a digital risk management company in Japan that modernized their server-based app infrastructure with minimal downtime by shifting their app front-end to containers in AKS, so they could easily add new functionality and scale more dynamically without having to manage the underlying infrastructure. In Azure Migrate, you can containerize your current web app servers running Windows Server with IAS or Apache Tomcat on Linux, using the App Containerization Tool to repackage them as containers. And once you’ve done that, you can then easily bring them into AKS to take advantage of the broader orchestration and scaling capabilities it provides.
-So, that was a quick overview of your options for migrating to Azure, with help from Azure Migrate. Whichever path you choose, whether Infrastructure as a Service or Platform as a Service, this opens the door to the modernization of your workloads. Now, to go deeper on all the options I presented today, along with guided tutorials, check out our migration and modernization playlist at aka.ms/MechanicsAzureMigrate. And for hands-on assistance from experts for your project, check out our Azure migration and modernization program at azure.com/ammp. And keep watching Microsoft Mechanics for the latest updates. Bye for now.