 Stay tuned today where I'm going to be talking to Barat from the Azure Migrate team. We're going to be talking about how Azure Migrate can help you with your migration projects, and also talking about some of the roadmap features coming up. Hello, everybody, and welcome to today's episode of Azure Unblogged with myself, Sarah Lean. I'm joined today by Barat Sivramon from the Azure Migrate team, and today we're going to be talking about Azure Migrate, so welcome to the show. Thank you for having me on Azure Unblogged, Sarah. It's a pleasure as always to be able to chat with you and your audience about Azure Migrate. Awesome. I know we've talked before about Azure Migrate, and people may have seen us talk about it, but for those that haven't seen any of our material, could you actually explain what Azure Migrate is for us, please? Absolutely. Azure Migrate is an Azure service that brings together everything you need for migration to Azure into one single place. Azure Migrate includes a collection of migration tools from Microsoft for your most common migration scenarios across infrastructure, apps, and data to help you plan and execute migrations to Azure. In addition to Microsoft tools, Azure Migrate also features popular migration tools from some of our ISP partners, and we bring all of this together in one place and let you track your end-to-end migration progress within that one single place, which is your Azure Migrate project. Now, in addition to tooling, you'll also find a host of other information relating to migration to Azure in Azure Migrate. So, if you're a Cloud Architect or an IT Pro that's working on Azure, then you should definitely be using Azure Migrate. Awesome. Azure Migrate is my favorite product, to be honest, in our product suite, and I love it. I think it's really beneficial, but for those that are maybe embarking on their migration projects and haven't quite been sold on why they should be using Azure Migrate, what are the actual benefits of using that within a migration project? Yeah, sure. So, when it comes to migration, as you know, right? I mean, it is, migrations can be quite complex and they require quite a bit of planning that needs to happen before you can actually start migrating applications to Azure. So, we typically tend to think of the migration phases as what I call discover, assess, and migrate. So, the first thing that you need to do is essentially discover your IT estate and identify the set of applications that are good candidates for migration. That's the first thing, that's where you kind of start off. And that's where Azure Migrate's discovery capabilities come in, right? So, you start off by creating an Azure Migrate project in your Azure subscription, download an Azure Migrate appliance, which is essentially a piece of software that's available with Azure Migrate, and deploy that virtual appliance in your on-premises data center or cloud that you're migrating from. Once you've done that, you can start discovering your entire IT estate of Windows and Linux servers and you can pretty much discover your entire data center in a matter of a few minutes, regardless of whether you're running virtualized in VMware, running virtualized in Hyper-V, running on physical servers, or even running on other public clouds like AWS or GCP. The cool thing about this is the entire discovery process is completely agentless, which means that it's very, very friction-free. And the only piece of software that you really need to install on-prem is that Azure Migrate virtual appliance that I spoke about. Now, what happens as part of the discovery process is you can have Azure Migrate inventory the list of servers that are in your data center, but not just the servers. Azure Migrate can also inventory the list of applications and roles that's enabled on each of the servers. It can identify the list of dependencies between your servers by monitoring all of the inter-server communications. And all of this, mind you, is happening completely in a completely agentless manner. So once you're armed with this kind of information, your decision-making is now much, much more easier. For example, you could, once you've done the discovery, you could look at the list of operating systems that you're running and identify list of servers that say running potentially Windows Server 2008 R2. So you know straight away that this application could be a really good candidate to migrate to Azure because of the great offers that's available in Azure for running Server 2008 with pre-extended security updates. Or you could take a look at the dependency information. So if you look at my screen, I'll just really quickly show you how that dependency information looks. What I have here in this screen is an Azure Migrate project in which I've already completed the discovery of my data center. As you can see, I have a whopping 56,000 odd virtual machines that's running on VMware that I've already discovered. I can then dive into this information, look at a whole bunch of things as to what are the servers that have been discovered, what are the various properties, what kind of operating system that they're running, et cetera, not just that. I can also look at things such as what are the list of applications that's discovered on a particular machine? So for example, I could take this particular server, click on the list of applications discovered and see what are the various applications out of there, what are the kind of roles that are enabled, is it running a SQL database, is it running a web server, et cetera. I can use this view dependencies option to plot a map of what are the various other machines that this particular server is talking to and identify all of those dependencies. Now what all of this information is really letting me do is I can really determine the, look at the dependency information and identify the groups of servers that maybe comprise one single business application. I could rate applications by their complexity by looking at the number of dependencies that they have and then figure out which ones are the easier candidates for migration. I can use them to create my migration waves, right? I could look at the kind of applications that they're running. For example, if I have a machine that's running a SQL server database, I straight away know that I have multiple options when it comes to migrating this particular machine, right? I could potentially take advantage of the database as a service offerings in Azure by migrating the database to Azure SQL or Azure SQL management instance and such. So that's really the power of the discovery and dependency capabilities that we have with Azure Migrate. So I've got this right. Azure Migrate will give you a bunch of information and you can use that discovery and dependency information, maybe augment it with something else, maybe some documentation you have lying around or information from a CMDB. Use that to kind of prioritize what's happening within your IT estate, how you want to migrate some of your applications. And then you can start to use the assessment piece that Azure Migrate has given you to properly optimize the migration plan. Have I understood that right? Is that correct? Yeah, Bingo, that's exactly right. So you spoke about the assessment. So what I've really done in the first phases, I've discovered my inventory of servers, try to tag it with applications, identify what are the set of applications that I want to start out by migrating. Now, once I've done that, the next stage of the planning aspect is to kind of look at what are the various migration options I have and form a slightly more detailed plan in terms of how do I want to migrate this particular application or piece of an application. That's kind of what we call the assessment phase, right? So for example, for most apps you could just, that's running on Windows or Linux servers, you could just straight away move them into one of the infrastructure as a service offerings in Azure, right? So to form a detailed plan around how to migrate an application that's running on a set of servers into Azure IAS, I could use Azure Migrate server assessment capability that you kind of alluded to. What the assessment does is you essentially create a group of machines on that's hosting your application or set of applications and you could run an assessment on top of that list of machines. And the assessment really gives you an optimal migration strategy by looking at various facets such as the readiness for migration, gives you optimized right sizing information on how you migrate to Azure and will also give you the predicted cost if you had to run that workload in Azure. Now, one of these information is very, very crucial for you when it comes to making that migration decision and making a choice as to how to migrate these set of servers or these set of IT assets. So let me delve on that optimized right sizing piece for a bit, right? So right sizing servers that are migrated to Azure can really, really be a significant source of cost savings and it's a highly, highly recommended optimization that you should definitely perform while migrating. In my experience, I've seen that on-premises servers are routinely oversized or over provision because capacity as you know is not really elastic on-prem like it is in the cloud, right? Capacity is hard to come by. So IT admins traditionally have hoarded capacity when it comes to their servers. In Azure, however, capacity is elastic and you can scale up or down on demand. So you don't really need to be running with a lot of slack through the year in anticipation of that maybe one week or two weeks of the year where you'll actually need that extra capacity. What you wanna do instead is you wanna write size and pay only for what you need right now and you can always scale up as you go along when you know you hit that two week sale period where you're actually gonna need that extra capacity. So what we can do with the assessment is you can perform what is called a performance-based migration assessment where we're looking not just at the server and how the servers are configured in terms of resources but we're also looking at the resource utilization on those servers. And we can tell you that a server is currently profiled over a period of a week or a month is not really running very resource heavy and you potentially have the option to downsize as you migrate that or those set of servers into Azure, right? So not only can we write size for you based on resource estimation utilization, we could also tell you what is the estimated cost of running that workload in Azure if you take the sizing recommendations. And again, when it comes to cost, if you look at the assessment options here, there's a bunch of choices you get to make in terms of the various pricing offers that's available to you. So I can take the same set of servers, perform a different set of assessments with say different pricing choices. For example, I could look at what's it gonna cost if I used reserved instance pricing, what's it gonna cost if I use pay as you go, et cetera and really make that compare and contrast to determine what's the best strategy for me to kind of migrate this. So let me show you this in a little bit more detail in a couple of assessments that I've kind of already computed. So on my screen, the first one you're looking at here is an assessment that I've performed for the set of nine virtual machines that I'm looking to migrate into Azure virtual machines, right? As you can see, the assessment when I drill down towards giving me three key pieces of information is telling me what is my readiness looking like currently in terms of how ready are these machines to be migrated to Azure as is. In certain cases, you may have certain remediations that you may need to perform before you could just move that machine over. For example, you may have disks that are too small, maybe the smallest disk size in Azure is larger than what you have on-prem or other configurations like that. So one is the readiness piece. The other couple of important pieces is the rightsizing information and the cost, right? So the first screen is kind of giving me like a cost overview, breakup across the compute cost and storage cost if I take the recommendation of this assessment and use the sizes recommended here, I can click the Azure readiness section and drill down a little bit more into each of these machines that are part of that group of servers that I've assessed, look at what the sizing recommendation for each of these machines are, right? So it'll tell me the skew, it'll tell me the break-up on a per-server basis based on the offers that I've selected, et cetera. So all of this information is very handy when it comes to making that final choice in terms of how to migrate, how to size, right-size as I migrate these machines over into Azure. So the assessment that I just showed you is an assessment for migrating to Azure Virtual Machines. This, for VMware customers, there's also an additional infrastructure option in Azure. You could choose to migrate your VMware Virtual Machines to Azure VMware solution. So if you were doing that, you could perform an assessment instead for migration to Azure VMware solution, and there the recommendations turn out slightly different. While we focus on the same set of facets in terms of readiness and overall cost and right sizing, with Azure VMware solution, you're not buying virtual machine instances, instead you're priced by the number of hosts that you need. So the assessment as you can see here is a little different, right? I mean, what we do is we try to right size by looking at the list of servers that you assess. In this particular case, my entire data center of 36,000 virtual machines, I've determined based on the assessment that I can kind of pack these machines into 304 nodes based on the parameters that I've provided in the assessment and such. So really all of these facets kind of come together to help you look at, based on considerations and parameters you provide, how you should size as you migrate to Azure and the cost that you will incur based on those choices of recommendations. Now this is as far as migration to servers are concerned, but equally, if you kind of had other migration treatments that you wanted to use, for example, migrate databases to the managed database offerings in Azure, which could be Azure SQL or Azure SQL managed instance, if you go over to the databases section in Azure Migrate, you'll find tools that can help you look into those databases, look into the compatibility of migrating a particular database to Azure SQL managed database or managed instance. Can tell you whether those databases can be more to Azure, so whether you need to make any remediations and such. So again, readiness information, but for a different style of migration. So that was the server and databases and then you can have something similar if you wanted to look at web-based applications that you potentially could migrate to Azure app service. So go over to the web app section, you'll find a set of tools that can help you run a compatibility check to tell you for particular web app that you're running on-prem is something that can be moved over to Azure app service or it can also tell you what are the remediations you need to make before you can move that application over. So I love the fact that Azure Migrate is so powerful and it gives you so much information and can help you with your decision-making along the way. So now that you've got all that information, you've convinced your leadership team that the migration path is absolutely the one to go on. How can Azure Migrate actually help you with that migration piece? Can it actually assist you with the migration? Yeah, yeah, that's a super important piece as well, right? So like I said, I mean, Azure Migrate, we really pride ourselves on being like that end-to-end tool set for your most common scenario. So migration is absolutely a very, very critical piece, especially when you're trying to migrate a lot of servers at scale. And again, just like we had for the planning scenarios in the discovery and assessment phase, we have a bunch of tools that can help you in the migration phase as well. So for example, if you look into Migrate Windows and Linux servers to Azure Virtual Machines, you would use the server migration tool in Azure Migrate. So using the server migration tool, your at-scale migration of servers is a simple two-step process. The first piece is to essentially configure what we call the application. So when you set up replication for the machines that you're looking to migrate, this sets up a continuous replication process to copy data from the servers to storage in your subscription. And after that replication is set up, you can complete the migration and cut over these machines at any point of time when you're ready. Not just that, you can also perform no-impact migration testing in a sandbox environment as many times as you like prior to doing the actual migration. Now, the other important thing is as part of the migration, you have a variety of settings that you could choose. So you could always configure where those servers should land in terms of which subscription, which resource group, which network, each of the servers that you're migrating should land in. You have the option to select your VMs queue and the disks queue to use, or you could actually import them from an assessment that you computed with Azure Migrate. You also have the ability to select advanced security and availability options, such as availability zones or manage disk encryption with customer managed keys. So you have the ability to kind of do all of this regardless of whether you're running on VMware, you're running on Hyper-V or you're running on physical servers or pretty much running on any other cloud. Any Windows and Linux server that's running in x86 or x64 architecture can easily be migrated using the server migration tool. And all of these operations can be performed using the Azure portal interface, but the server migration tool also offers a rich set of automation interfaces through PowerShell and REST API that you could use to execute at scale migration in a migration factory-based approach. Now, that is as far as migration of servers go, but just like I spoke about in the assessment, discovering assessment scenarios, if you have wanted to kind of apply a different treatment to migration in terms of, say, moving your databases to an Azure managed database offering, then we have tools for that as well, right? So you could take your SQL server, just migrate the databases over into, say, Azure SQL Managed Instance or Azure SQL DB. Similarly, if you are running web-based applications, either .NET or PHP or Java-based web apps, you could always use the App Service Migration Assistant tool that's available in the web app section to move these apps over into Azure App Service. Or if you're looking to move large volumes of data, the offline transfer into Azure, say for archival purposes or to use with the data lake for machine learning, model training, et cetera, you could do that with the data box that's, again, integrated into Azure Migrate. So what we really cover in terms of tools is the most common migration scenarios. You'll find tools that can help you perform at-scale migrations for all of those scenarios. Now, in addition to these scenarios that I kind of spoke about, there's also some other niche scenarios where you may want to take a slightly more application-centric treatment. And we've also got a bunch of useful information, useful references for that. So on my screen, I have here the Explore More section of the Azure Migrate project page. And in here, you'll find useful references for a lot of other migration scenarios, such as if you're migrating Java apps to various options in Azure, there's a bunch of guides that you could kind of use. Or if you wanted more storage-centric treatment for migration of file servers into Azure, there's the references, articles that you can kind of use here. Databases, we spoke about SQL Server, but if you wanted to look at what are your options to migrate some of the other popular relational, non-relation databases, there's a whole set of information that you could kind of leverage that's linked into Azure Migrate that can help you with that process as well. Awesome. I think it's such a powerful tool, and it's great to see some of the common scenarios covered that our customers are asking for. Although I know a lot of organizations are talking about containers and container platforms, and I'm being a little sneaky here, because I know offline, we've been talking about some of the features and the roadmap that you guys are working on to help with that. Can you share any of the plans that you've been working with to help our customers move to containers? It's a bit cheeky, sir. I wasn't really authorized to kind of talk about this, but since you brought it up anyway. Yeah, I mean, you're right, right? I mean, we've also kind of beginning to see and hear a lot of interest in modernizing applications as they are being migrated. And there's a lot of interest in migrating existing applications to containers that can be run on Azure managed container platforms and runtimes such as Azure Kubernetes Service or Windows and Linux containers on Azure App Service. So this notion of being able to build once and then deploy in a consistent manner multiple times across all of your different environments is something you can do with containers. And that's something that a lot of customers are finding really appealing. Now, being able to move legacy apps which are mostly monolithic apps by and large to a microservices-based architecture that is then deployed on containers is something that's finding a lot of interest among customers and cloud architects that are looking to migrate these apps. Also, when you look at it from an infrastructure and IT DevOps perspective, right? I mean, this approach gives them flexibility of management, easier and more consistent way of managing their infrastructure across various application types, right? They don't need to do specific things for different application types in terms of infra management. Now, while all of this is goodness, moving to kind of like a microservices model for your existing apps may oftentimes require a significant amount of investment into those apps to kind of rewrite them or even refactor them significantly. And not all classes of apps are going to be prime for that kind of investment from customers straight away because it is a significant amount of investment in terms of developer resources and time to be able to even rewrite or significantly refactor these existing applications. So what we're beginning to hear and see a lot more of is that there is an interest in finding a way to still take some of these apps and package them into a container format and run them as containers and get some of these benefits of consistent management and simplified operations as an intermediate step before you're actually able to invest in doing the more full-scale refactoring of the applications. So this is an idea that we're seeing finding ground among a lot of our customers. And you'll notice that there's certain class of applications that kind of lend themselves well to this kind of approach. And I'd say primary among them are simple web-based applications that have your presentation and application logic. These applications can oftentimes be easily repackaged and deployed as containers without making too many alterations to the application structure itself. So what we kind of done with this current preview that we have, it's still a limited preview that you could kind of sign up for to get access is we've tried to automate or help you automate the task of taking a web-based application and package it and run it as a container without having to necessarily rewrite all of the applications, right? So it may not work for all applications but it certainly works for a certain class of applications. And the tool essentially works in a no-code point and containerized fashion. So this tool currently supports ASP.net web applications that's running on Windows and Java-based web apps that's running on a Tomcat server. The tool is a standalone utility that you can run on any machine, right? So it can connect to the server that's hosting your web application over the network and identify the list of applications that you're running on those machines. The tool will then help you build out a Docker file that you can use to package the application or the web application that's hosted on that server into a container. And in the process of actually creating this Docker file, the other cool thing that the tool also lets you do is it lets you parameterize some of these application configurations as well, right? So for example, database connection strings and things like that, which are oftentimes part of the application, configuration is not something you want to hard-code into the container image. So we'll actually find out these configurations, parameterize them such that as opposed to making it part of the container image, you can actually make them a deployment time operation that you can specify when you deploy that particular image. Once that Docker file is generated, you have the option to further customize the Docker file to suit your needs and use that to build a container image. Utility will even build a container image for you. So you can actually trigger a build from that utility. We use the Azure Container Registry Cloud Build feature, tasks feature to kind of build that container image for you and push it into an Azure Container Registry in your Azure subscription. Once you have that container image for that web-based application, you're then at liberty to kind of deploy that to any container platform of your choice. Now what the utility has also done is if you wanted to deploy this to a Kubernetes cluster, specifically an Azure Kubernetes service, right? What we'll do is the utility, just like it helped you generate that Docker file, can also help you generate the Kubernetes resource manifest to YAML files that you can kind of use to then deploy the application to an AKS cluster. Once again, you kind of go through a bunch of settings that the common settings that we kind of automate, use to automate the creation of that, of those YAML files, specify those settings, click okay, we generate the YAML file for you. You can inspect it, edit it, and you can even do the deployment from right here, from within the utility, right? So, and basically get that application over into AKS. So, if this kind of scenario is of interest to you, if you're looking to kind of take your existing application, then do a minimal quick modernization on them for a certain class of applications, you should definitely sign up for this preview and try it out. To sign up, go to AK, I'll leave a link here, but go to ak.ms slash migrate to AKS, and sign up if you'd like to try out this functionality. Awesome, that sounds like it's gonna be a very useful tool for a lot of our customers. So, thank you for sharing that. And thank you for your time today. It's always good to catch up and chat. And thank you to everybody tuning in as well. And what we'll do is we'll drop some more information and links to sign up for that preview feature in the description box. So, make sure you check that out. And again, thank you everybody for tuning in.