Enterprise workload migrations to Microsoft Azure can be a long and involved process. Architects, developers and administrators need to account for application dependencies and map out potential issues to successfully migrate workloads from on-premises data centers to the public cloud.
Microsoft offers several cloud migration tools for Azure that are intended to simplify the process. These services include Azure Migrate, Azure Site Recovery, Azure Database Migration Service and Azure Data Box. Each one is designed for a slightly different task, so enterprises will need to use the right cloud migration tool for the right job to get their workloads onto Azure.
Watch this video to walk through the steps you'll need to follow in order to use one of those tools -- Azure Migrate. See how to assess current on-premises workloads and plan for what resources those servers will need to run properly in Azure. Learn about the discovery process and how to actually create an assessment. Then, find out how to select between VM sizes based on Microsoft recommendations and how to decide on the appropriate pricing option.
From there, review the process of testing workloads on Azure and see how to conduct the actual shift of on-premises virtual machines to Azure VMs.
Hello. Today, we're going to talk about how to leverage Azure Migrate to assess and migrate workloads you might be running in your on-premises data center up into Azure IaaS. To get started with Azure Migrate, you're going to go into the Azure Portal and you're going to actually create an Azure Migrate solution, new resource. Search for Azure Migrate and select that. You go ahead to this option right here and click Create. By default, you'll see this hidden, sort of, dashboard when you sign in. That's because there's a couple of things in before, discover, assess and migrate servers. This is looking at taking your on-premises virtual machines and migrating them to Azure IaaS, assess and migrate databases, which cover doing your traditional database workloads into SQL PaaS, and then there's also information for Data Box which is essentially Microsoft sending you a drive. You copy your data over to it, ship it back and then they can put it into a storage account in Azure, which depending on the cost of your network links and how much data you have could actually be a ... which could be a more cost-effective and efficient solution for migrating large amounts of data up into Azure.
What we're going to focus on here is migration of servers. So we're going to go ahead and check out the migration goal servers. By default, you won't have anything in here except for links to add assessment tools, but I've already got some stuff prepped out for this. What you're going to have for assessment tools are several options. There's a Microsoft option and there's these, a handful of other ones from, like, a third-party marketplace. If you already have something, for example, like Turbonomics that you've been using on-prem to analyze your workloads then you can go ahead and use Turbonomics again to analyze the workloads into Azure.
What we're going to focus on here is the Microsoft one. To get started with Azure Migrate, first, you need to assess what your environment's like. So, if you click the Discover button, you're going to get this pop-up. It's going to ask you: Do you want -- if your machines are virtualized on vSphere or Hyper-V, then you can go ahead and select the appropriate version. What you need to do is grab the OVA VHD and deploy those to either ESX or Hyper-V. It's a little bit outside the scope of this, but a fairly similar process, download those, install them. Once you install those and bring those online, it'll automatically start the wizard. That wizard's just got a few things that you need to set up on that VM here. Set up pre-reqs, mostly in case of like ESX, there is a SDK that you need to download and install. It gives you a link to that when you need it. So it's fairly easy to grab. You do need a VMware account for that. When you sign into the Azure Portal in here, make sure that you're signing into the correct Azure subscription and tenant. Once an assessment VM is tied to a subscription it cannot be changed. If you want to change it, you'd have to redeploy that OVA. You're then going to authenticate to, in this case, vCenter. VCenter, it needs credentials to read data that's in the cluster. If you use a limited scope account, then there'll only be a limited scope on what the assessment can pick up. So if you actually want to do a true assessment of everything in the data center, then you need to provide an account that has everything, has a read access to everything, to actually, it can see it. Once you go ahead and set all that up, it will initiate discovery. It takes about 10, 15 minutes for the engine to actually look at your information, look at your cluster, and then start showing it off at the portal.
So after about, you know, that 15-, 20-minute period, you'll see some information in discovered servers. We can go ahead and check that out. So this will be the servers that whatever the credentials have access to. Real quick, you'll see that there are dependencies here, requires agent installation. If you want to have a very full, in-depth analysis of what your dependencies on your workloads, you can go ahead and install Microsoft Monitoring Agent on your VMs. This will actually use an LMS workspace to determine, based upon everything that is going through that box, what other boxes it's talking to. So, you can validate that: Oh, yes, Application Server 1 is actually talking to Application Server 2, 3 and then these are the databases, and actually, get a full dependent map on what those services are talking to. So you can have a very good understanding that when you get ready to migrate something to Azure that you're migrating the entire solution or you know what all your dependencies are back to on-prem resources rather than a best guess, kind of, scenario. This is not required at all. There's a bit of additional costs for having that LMS workspace and a bit of extra effort installing the agent, but it is a very nice thing to consider, especially if you have very large, complex workloads.
At this point, we're just going to go on a quick and easy. So click into this. It's going to give you the name, IP address of ... and then specs on the machines that you have enabled. What you need to do then is go ahead and create an assessment. Assessments are how you're going to determine what you have on-prem, and then what that's going to look like in terms of going into Azure. If you want to see this assessment properly, you really need to come in here and actually view all these settings. First, your target location. I'm going to go ahead and send this to South Central U.S., one of the closer data center regions to me. Automatic storage type, I'm going to go ahead and leave this set to automatic. You can change how this goes later if you have the need to, which is a better idea than just telling it you actually need premium disk maybe then when you actually don't.
The next thing up is reserved instances. It is possible to buy virtual machines all at once for a one-year or three-year period, and you get a significant discount on that. I think in terms of actually play out what the assessment is going to do and the cost that's going to be associated with it, you should have a no-reserved instances. You'd rather have a worst-case scenario on your cost criteria than having maybe a reserved instance on here for a three-year, getting that discount, and then actually, either, ending up overpaying for a year of services or not using that.
Next, with the VM size is sizing criteria. You've got performance-based and you have as on-premises basis. If you do as on-premises, it's going to go ahead and actually change some of your settings away for you. You don't have the ability to, kind of, look at that. This will be as close to it as it can be in terms of what is on-prem and two, what is available in Azure. For example, you can have a three-core VM in Azure. So if you have one of those on-prem, then you're not going to get one of those in Azure. So it's going to be upsized to whatever the next closest thing is. I highly recommend doing a performance-based configuration. All, kind of ... a lot of virtual machines on-prem are oversized and you don't want to be wasting that cost or resources in Azure if you don't need it.
So, I would also recommend you have options looking performance system history for one day, one week and one month. The longer you're able to let this sit there and analyze the environment that it's running in, the better idea of it you're going to get. There'll also be a confidence rating later that'll be impacted by how long you're looking at this. Migrating to Azure isn't something you're generally going to do over one night, so letting it sit there for, you know, a month and actually understanding what that workload is like, the peaks, and valleys, and servers is a pretty good idea. I also prefer to set the comfort factor to 1.2. I like a little bit of fudge room in there. Now, I might not necessarily actually go with that at the end of the day, but I like having that little bit of room in there just to, kind of, think about. And then also for my VM series, I suggest taking and selecting all of these. You have an idea that you only want general-purpose VMs, and you don't want memory-optimized, and you don't want computer-optimized, go ahead and remove those. But I think having general-purpose in there is a pretty good idea just so you can get an idea of what your workloads might look like and what the assessment … might need to do.
And then going down to pricing. The offer box has a ton of things in there. Pay-As-You-Go, [inaudible], Azure PaaS subscriptions, lots of options in there about ways you can consume Azure. Pay-As-You-Go is pretty good for just a flat base rate. You'll also see a discount. It's possible to have a discount on Azure services based upon commitments with your enterprise agreement. If you have that as a guaranteeing thing and you know what that is, feel free to put that in. Once again though, unless you know it's a guaranteed thing, I would leave this as zeros to ensure that you're [not] getting the possible worst outcome. The final thing to point at is this already has a Windows Server license. This is on by default. If you do not have an eligible server license that has hybrid benefit, then that's going to be a bit of a sticker to you, that's a 45% decrease or increase in pricing from hybrid benefits. So, talk with your account team, renew your license in Expert, and determine if you do have hybrid licensing. That'll save you a bit of money instead of having to pay for the licensing cost with the virtual machine. But you've got to be very careful and ensure that you're aware of that. I'm going to go ahead and click save. Now, you can put everything in a group for the first assessments, and I think you should have at least one assessment that has everything in it. That way, you just get a good idea. If you just took this entire ESX cluster, or this entire Hyper-V cluster, stuck it in Azure IaaS, how much would it cost you?
So, we're going to go ahead and do that. All right. Now, let's go look at that assessment that we have. So you'll see I've got some assessments here already. Pull up this one real quick. Real quick, you have some information here. So how many virtual machines I have that are absolutely ready to migrate to Azure? How many that have some conditions and then maybe some issues? Also, then estimated costs on compute and storage. So, you'll see that I have one VM that's very ready to go, 11 that have some conditions that might need to be fixed. It would be at $1,500 for compute and $184 a month on storage costs. It gives you a pretty good breakdown on what that's going to look like.
I'm actually digging into the readiness of this. Generally, what you're going to see is you're going to see as ready-with-conditions for anything that's running an EFI boot mode. Azure, as of right now does not have EFI booting mode support. So this would actually need to convert this VM to BIOS boot as part of the conversion process, which can be a thing. So that's actually not that big of a concern to worry about.
Now, if we look at the assessment. So, everything run down. It'll will give you a, "Hey, this is unknown." The case of that pfsense box right there that says "Unendorsed Linux distros." I mean, it's free VSD. So, that makes sense. So to, kind of, give you an idea of how many disks are there, what the storage are and give you a good all set of what that's going to look like and it's also going to tell you what VM it thinks it should be. So, you know, in the case of that DC right there, it thinks I should, a Standard_A1_v2 will be good enough to support that workload based upon what the assessments were in MS.
You actually dig into the properties of a virtual machine. Once again, you'll have that kind of high level overview, give you a, "Hey, do you want to -- you can do a migration with Azure Migrate." Based upon, currently, it's using two cores, only using 11% of that. It's got 4 gigs of RAM, only using 19% of that. Gives you an idea of what that utilization workload is in terms of operation usage. It gives you a nice idea. So you can go through and then you can have multiple assessments. Multiple assessments can be part of any environment. You'll see that I have multiple here. If you look at this one it says OutOfSync. That's because I've actually added or removed a group to it as part of the testing. So it'll give you an idea if something is out of date.
The cost details thing will just basically break down that overall ... what you saw earlier, how much that's gonna cost in terms of each VM, or compute or storage unit. It is an estimate, but you can always escalate that up and recalculate it as well. If you think that something is wrong, you can always use the Public Azure Pricing Calculator and, kind of, think about things as well. So once you have assessed your environment you, kind of, have an idea of what you're going to move to and how much that's going to cost, [when] it comes to [the] actual migration phase. So down here we have the migration tools. I already have one enabled. There are also, just like in the assessment tools, other options. There's Carbonite and Coretek. They provide some information here. What's nice about them is they have virtual machine support as well.
All right. So looking here, we've got 12 discovered servers, two servers that are replicating. We've done a test migration and then we have a migrated server. Let's look at the replicating phase 1 first. This actually uses Azure Site Recovery in the back end to replicate servers. It's going to ask you, "Are we virtualized?" So, yes. I'm going to select the appliance that we've put in. If you want to take the information from the assessment you already have, you can do that. We'll just take this group. Take that assessment, and we can take this. And we can go ahead and migrate all of that one quick ... we're just gonna do one real quick, just, kind of, give you an idea of what this looks like. Make this DC see here. All right. So we're going to select our subscription and our resource group. And we're going to select a virtual network and a subnet that we're going to put that on. It'll automatically go on a subnet if you don't have it, and it will once again tell us about Azure Hybrid benefits.
The compute's going to give us some information. So automatically based on size and config. If you disagree with what that information set to size and config was, you can come in here and manually select, you know, Basic_A1 and it will deploy that. We're going to go ahead and set that back to automatically select. Go to Next. Like I said earlier, the standard SSD will be good enough for some things and other things you may [inaudible]. If the virtual machine you select doesn't have that tier, if you select in premium one then you might actually not see all those options. And then you're going to go ahead and then just hit the Replicate button. I've already got one replicating. So we're going to take a look at that.
So, a couple of things are replicated. So you'll see that I have two that are in a healthy state, and then one of them has already been migrated. When you actually hit replicate, something might take a while for it to become in a healthy state. All of these, at one point, were in unhealthy states. I did no troubleshooting to them. I just let them sit and, kind of churn, and after an hour or two they went healthy and started migrating.
Looking at this app server here, it's in a currently Delta sync phase. What this means is that it's an initial replication, and it's done some bits for information there. You'll see here, there's been some failures here. It's all good. As long as it keeps up, we're fine. I have the option to come in here and do a Stop Application. I have an option to do a resynchronization, cleanup migration, and do a test migration. This one has already performed a test, which is why it's in a cleanup test migration state. All a test does is it actually takes a ... there's a delta sync of that data. It churns out a pre and turns on a VM in Azure. You can actually sign in into that VM in Azure and test it out in a limited amount, right, it's going to be on a different networking segment, in VLAN in Azure. But you could turn that on, test it out, and make sure that it, kind of, works a little bit, and then clean up that test migration when you're done. And then, kind of, have that good test policy to make sure it even boots and comes online the way you expect it.
Once you actually do a migration path, it's going to go ahead and actually turn off the virtual machine on prem, and do a delta sync, and ensure that it has every bit of data, and nothing's going to change after that completion. And then sync that data into Azure, our VM on, and then you're good to go. And change your DNS settings, … make sure [the] connection works, and that server will then provide whatever features it was. This is something you're going to do during a maintenance window. It may take a couple of hours between DNS propagation, and delta syncs, and your network bandwidth to actually go from shutdown, full delta, sync any changes, [inaudible] and turn on a VM. So, it's not something you're going to do in a few minutes during the middle of the day, but something you can plan during, you know, evening and get that moved in up there pretty quickly. The biggest thing with Azure Migration is ensuring that everything is done and planned out from a dependency point of view, you have your networking segments put in. So, it's really good to do that testing and make sure that servers can talk back and forth between on-prem resources that you have. Then, that the VM latency's OK and do that actual network testing. As long as you do your planning assessment and you have an idea of what your scale size is, so your network connectivity, ensure your network connectivity is good, the migration part itself is fairly easy. It's a good process to, kind of, do a lift-and-shift of those servers into Azure. All right, well, I hope you found this useful information [on] how to migrate into Azure and I wish you good luck on your migration efforts.