 Hi everybody, my name is Sarah Lean and I'm a Cloud Advocate at Microsoft. You'll often hear me talk about how you can use Azure Migrate to migrate your on-prem environment up into Azure. However, today I want to talk about how you can actually leverage Azure Migrate to look at the virtual machines that you host in AWS or another Cloud provider. Regardless of where your starting point is, if you're looking to migrate workloads into Azure, the first thing you should really be focusing on is doing a discovery or an assessment of your current environment. And that's where Azure Migrate can actually come in and help you. It can assess your current environment so it can collect information about your servers, simple things like the name, the IP address, the operating system, what level of patches that you have applied to that server, and also some of the more complex things that happen within your server, such as the dependencies. So what servers does it talk to? What services does it leverage? What ports does it leverage? How often? Et cetera. And what we want to do is actually use Azure Migrate server assessment tool within this AWS environment that we have. So let's dive into the video and I'll show you how you can do that. The thing that we want to do within the Azure portal is actually create an Azure Migrate project. So when you create an Azure Migrate project, you're asked some simple information like what resource group do you want to store this project in? What do you want to call it? And what geography do you want to use? Now, the geography is all about where that metadata is being stored. It's not necessarily about where your actual VMs will be migrated to. It's more about that metadata that you're collecting and what region will it be stored within. Now, the sixth section is to look at what tooling you want to add to this project. In this case, we're really only talking about the assessment. So we're using the Azure Migrate server assessment tool, and then we can leverage that to discover our environment. Now that the project's created, what we want to actually do is embark on that discovery journey. So what we have to do is click on the Discover icon. When we do click on that Discover icon, we're asked a bit about the machines that we're wanting to discover. Now, we're going to pick the option that says non-virtualized or other. And this is around being able to actually assess these virtual machines that live on AWS. What it'll give us here is a downloadable file, and this downloadable file will set us up for actually installing the necessary Azure Migrate server assessment tooling onto a server within our AWS environment so that we can discover the machines. So the process of installing the Azure Migrate server assessment tool is actually quite simple. All you have to do is take that PowerShell script that you've downloaded and actually execute it on your server. Now you can use a dedicated server within your environment, or you could repurpose another server. So once the PowerShell script has executed, what it'll do is automatically launch a browser session and it'll start to load the tool. Now the Azure Migrate server assessment tool is all used or interfaced through a browser session. So once the tool has launched, it'll start to work through some of the prerequisites that the tool requires, such as the licensing terms, checking that it has internet connectivity to authenticate and communicate with the Azure portal, as well as checking the time and also if it's the latest version. Now hopefully if you've just downloaded it from the Azure portal, it will be the latest version, but potentially there may be an update that you have to apply. But those first prerequisite steps are quite quick and straightforward to work through. The next stage is to actually register your Azure Migrate appliance with your Azure subscription. So at this point, you will be asked to log in to your Azure subscription, pick the Azure subscription that you have. If you have multiple ones, you'll be asked to pick the right one. You'll be asked to pick the Azure Migrate project and that is the one that we created earlier on. And then give the appliance a name and that's just so that you can look at it within the portal and identify the machine that it has identified. The next stage is to provide some information about the servers that you actually want to assess. So in this case, we're looking to discover two of the servers that we have in our AWS environment. So we provide the names of the servers and we also provide some credentials so that the Azure Migrate tool can pull some information around those servers. Once it's pulled in those details and it's authenticated that it actually can get to those servers with those credentials, it will start its initialization and discovery. Now it could take five or 15 minutes or even longer for some of this information to actually start to populate within the Azure portal. What I always say to customers is to leave the discovery running for as long as possible. So potentially you want to look at leaving the discovery, collecting information about your server environment for at least 30 days or a month. And that shows you can get an overview of what's happening within your server environment because often what you'll find is there's a one-off task that maybe runs at the end of the month, such as maybe your payroll applications and you'll get a good idea of the performance of those servers and you'll find out when they peak and when they don't peak, et cetera. So please leave the discovery as long as possible but at a minimum we genuinely say 24 hours to get the basic information that you need. After a while when we go back into the Azure portal we'll be able to see those discovered servers and we can see those two AWS servers that we asked the tool to assess. Now we've got some basic information, server name, IP address, what memory it has configured, how many disks and how much storage it has initially. What we actually want to look at is dependencies. We want to look at what these servers communicate with so that we can get a good overarching picture of what we need to move and do we need to move these servers together? Do they need to be paired together? Do they communicate? Are they part of the same application, et cetera? Diving into the dependency mapping we can start to see some more information around our servers. We get that overview again of some basic information, name, IP address, the operating system, the service package information and we can also start to see where it communicates. We can start to see those paths and what processes communicate with what ports, what other clients, what other servers, et cetera. Now the environment I'm using here is just a lab environment so it's not very detailed rich in terms of dependency mapping. Obviously, when you're using this within your production environments or even your development environments, you'll get a much richer picture of what's happening within your servers because let's face it, our servers don't work independently. There are tons of communications going between each of our servers within our environment. Now that we've got an overview and we've collected some information around our AWS environment, what we want to do is pull together an assessment that actually shows us how much it would cost if we were to move these servers into Azure. So what we want to do is create that assessment. Now we can assess these virtual machines either to host them as Azure virtual machines or we can look at hosting them as Azure VMware solution virtual machines. In this case, we just want to move them as a virtual machine so we're just gonna pick that assessment type. We need to give the assessment a name. It's really just for our purposes those that we know what that assessment does so we can leverage it later on. When we start to look at the assessment properties, this is where we can actually get quite rich and quite detailed with the data and how we assess it and how we transpose it into something that makes some sense to us. When you look at the server assessment properties, there's a lot of information that you can configure. Now what we are gonna do is actually create a performance-based report on what our virtual machines would look like if we based on how they're currently performing. Now I always say create two reports. Create one that gives you information about what it would be like if you hosted your virtual machines on Azure as they currently are with all the settings, with the configuration and see what that looks like and then run that performance-based view and see what it potentially could be like because let's face it, we were probably all guilty of actually over-sizing our virtual machines so as we avoid any performance hits. What we can do if we've collected enough performance-based data, we can actually get a proper view of what our servers would look like and potentially how much money we could save if we were to right-size them and have them size within Azure appropriately based on their performance. Now once that assessment has completed and calculated its data, we can interact with that report and we can see various things. We can see the Azure readiness of our virtual machines. We can see an overview of the cost for that virtual machine, for the compute and the storage. So the Azure readiness is actually quite an important part of the report to look at. It'll give you information around if there's any flags or any warnings that you need to deal with before you look at moving these virtual machines into Azure and that could be something like the operating system isn't supported or is a legacy one and you need to think about whether it's right to move it into Azure, et cetera. It also gives you information around what tool would be the best for migrating it and potentially if you've done a performance based report it'll give you an Azure virtual machine size which may not be the same size that you are using currently wherever it is hosted. Now you can interact with this report and have a look at the information that it's collected and is basing its sizing information on. You can look at how much CPU utilization has been used on that server while it's been doing its data collection and then understand how it's recommended certain sizes and certain migration paths as well. And obviously it gives you that indicative report about what it would cost to host these virtual machines within Azure. So hopefully that's given you a good overview of what Azure Migrate can do for you if your virtual machines are hosted in AWS and what assessment data that you should be looking at and focusing on. Now Azure Migrate can actually assess your virtual machines whether they are on VMware, Hyper-V, if they're physical and like we've just talked about in another cloud provider. So definitely don't be constrained about where your virtual machines are. Have a look today and see what Azure Migrate can do for you.