Migrate Virtual Machines On-Premise to Azure Cloud | VMware Cloud Migration Azure | Step by Step

Subscribe here, new videos posted weekly.
/ @cloudinspired
This video will cover a complete step by step guide and tutorial showing moving to the cloud with a migration from VMware virtual machines on-premise to azure cloud using azure migrate tools and site recovery.
We will discover our server environment using azure migrate appliance and then we can use this discovery for either a migration to the azure cloud or could be used for disaster recovery keeping our server enviroment "as is" on-premise or in another datacenter and using Azure as a failover site in case of any issues with our current enviroment for DR.
The following content is covered in this video.
0:38 Intro diagram and architectual components
03:21 VMware ESXi host
03:53 VMware Windows Server 2019 virtual machine for ASR
04:14 Create Azure Migrate project in portal
04:42 Discover Virtual Machines using physical appliance
05:42 Generate project key
05:56 Download Azure Migrate appliance
06:07 Install Azure Migrate appliance using PowerShell
06:48 Configure Azure Migrate appliance
08:06 Discover Windows Virtual Machines and set target region
08:45 Download replication appliance (configuration server) for Windows
09:22 Install replication appliance on Windows Server
10:23 Discover and select configuration server to register
10:37 Disable UEFI secure boot on Virtual Machine
10:53 Install mobility service agent on Virtual Machine to migrate
12:09 Create Azure Virtual Network in UK South target site
12:52 Replicate VMware Virtual Machine from On-premise to Azure Cloud
14:32 View Migration Vault and Synchronization Progress to the Cloud
15:09 Troubleshooting process server and VM replication for issues
16:12 View process Server health
16:37 View protected and replicated VM in UK South vault
17:27 Changing replicated compute and network target properties
17:57 Perform a test failover
18:19 Add public IP to test failover VM
18:38 Add NSG to VNET for test failover VM
19:10 RDP to test VM
19:30 Test failover cleanup
19:50 Perform a real failover
Links:
Migrate machines as physical servers to Azure
learn.microsoft.com/en-us/azu...
Azure Site Recovery pricing
azure.microsoft.com/en-gb/pri...
Troubleshoot the process server
learn.microsoft.com/en-us/azu...
Shop for Merch here
cloudinspired.myspreadshop.co...
#cloudmigration
#vmwarecloud
#onpremise

[@ThatDevOpsKid]

Quite a good demo here. 👏🏾 👏🏾👏🏾

[@CloudInspired]

Thanks @ThatDevOpsKid

[@abdalrahman6124]

thank you for this effort, sir, I have a question please:
what's the best way to know the best storage type that I need to use for the replication ?
and to avoid any future latency "churn", how can I know the appropriate target Disks type "HDD, SSD, premium " ?
and how to know the best number of configuration servers needed for the replication if I have a lot of servers?
thank you in advance!

[@CloudInspired]

Hi Abd, Thanks for your comment and questions.
For storage type you would need to measure current IOPS, throughput and compare to the five disk types to help you decide which to use. For example, HDD, Premium SSD, Standard SSD, Ultra disk, Premium.
Below is a table to help you compare max IOPS and throughput.
learn.microsoft.com/en-us/azure/virtual-machines/disks-types#disk-type-comparison
Heres is are some other links to help measure the right number of configuration and process servers to deploy.
Sizing and capacity requirements
learn.microsoft.com/en-us/azure/site-recovery/vmware-azure-deploy-configuration-server
Azure Site Recovery Deployment Planner tool.
learn.microsoft.com/en-us/azure/site-recovery/site-recovery-deployment-planner
Plan capacity and scaling for VMware disaster recovery to Azure
learn.microsoft.com/en-us/azure/site-recovery/site-recovery-plan-capacity-vmware

[@phillipgilligan8168]

So first off, thank you so much for the very informative video. I do have questions, I have watched many videos on this topic and none of them have done the failover method you outlined.
1. Is it correct to assume during this process, when you click failover, that's the official cutover? So, at that point as an example, that's when you would have your cutover window, then swap over DNS records?
2. In most of the videos on this topic that outline a lab demo, they install the migrate appliance on the target VM. Can we install this migrate appliance essentially on any server that would via network have access to the other VMs? Or do we need a dedicated VM for said appliance? Is it ok to use a target VM to install said appliance if we are unable to install a dedicated VM for said appliance? I'm just used to the term appliance being used for a dedicated NVA as an example or appliance in the context of VCSA for VMware where it's a dedicated appliance.
3. Many videos outline a sync process before cutover, where once syncing is completed, it continues to delta sync until you are ready to cutover. Comments on this?
4. Did I understand correct that on day of cutover, we will want to turn off the target VM BEFORE the migration? Or after? Sorry I didn't understand that clearly.
Bonus Question if you have the expertise and time:
5. Thoughts on VMs that are AD joined? I have thought about this in detail. If we say build new domain controllers, replicate to them, and then ensure that said domain controllers have access to the network our target VMs will be migrated to, THEN migrate said target VMs, this would break their join to the domain wouldn't it? We would need to rejoin them since they are considered different objects now by the domain controller. So would it then be wise to unjoin said VM first from the domain controller, migrate, then have the rejoin to the new domain controllers?
I greatly appreciate the content you uploaded and how it was clear and concise and would also greatly appreciate if you find the time to answer these questions. Thank you!

[@CloudInspired]

Hi Phillip, thanks for your comments and these are all good questions! Please see response below.
1. During a failover (or migration), the source VM is shutdown and the destination DR VM is then powered up i.e cutover.
In this case in another Azure region. For Active Directory DNS, if there are AD Domain Controllers/DNS in the DR region then the VM would be able to resolve DNS once failed over. For other DNS (i.e external public facing from the internet) yes you would either change DNS records to a new public IP or use something like Azure Traffic Manager (DNS traffic load balancer) which would also allows you to distribute traffic to your public facing applications.
During a test failover the source VM normally stays powered up.
2. You either create a replication appliance through a OVF template then import this into your hypervisor as a VM. i.e VMware, HyperV etc. Or you can download the installer and setup the appliance through Powershell. Further details here on Microsoft article here:
learn.microsoft.com/en-us/azure/site-recovery/deploy-vmware-azure-replication-appliance-modernized
For disaster recovery on on-premises physical servers, you deploy the configuration server manually.
learn.microsoft.com/en-us/azure/site-recovery/vmware-physical-azure-config-process-server-overview
3. The first recovery point that's generated has the complete copy. Any successive recovery points have delta changes.
A near-constant data replication process makes sure copies are in sync.
learn.microsoft.com/en-us/azure/site-recovery/site-recovery-faq#are-all-the-recovery-points-a-complete-copy-of-the-vm-or-a-differential-
Hyper-V: Hyper-V VMs can be replicated every 30 seconds (except for premium storage) or five minutes.
Azure VMs, VMware VMs, physical servers: A replication frequency isn't relevant here. Replication is continuous.
learn.microsoft.com/en-us/azure/site-recovery/site-recovery-faq#how-often-can-i-replicate-data-
4. As in question 1. During a failover (or migration), the source VM is shutdown and the destination (target) VM is then powered up i.e cutover on the secondary Azure region. During a test failover the source VM normally stays powered up.
5. In a hub and spoke network topology. The hub hosts services that can be consumed by the different workloads hosted in the spoke virtual networks. Shared services such as Active Directory Domain Services, DNS, firewalling, VPN gateways exist in the hub network. On the failover region, the hub network would contain Active Directory Domain Services, and once the domain joined VM was failed over in the spoke network then the VM would have access to Domain Controllers in the hub. Check out video in the Cloud Inspired channel which covers Hub Spoke Architecture in more detail th-cam.com/video/Y9rvAGEikx8/w-d-xo.html

[@varunt5856]

I want to know if this Azure Site Recovery of Process/CS server Migration tool is still used in Azure or there is any other new technology replaced under Azure Site Recovery . Please do let me know

[@CloudInspired]

Hi Varunm, yes Azure migrate and Azure Site Recovery is still a valid tool to use for migration, replication, DR for native disaster recovery as a service (DRaaS), or failover of Virtual Machines in the Azure Cloud. Site Recovery is automatically updated with new Azure features as they’re released.

[@SPHoneycomb]

Sorry to say this. Honestly, you are going way too fast, and for beginners like me who want to understand this migration is quite difficult.

[@CloudInspired]

Hello, I'm sorry you felt this way. However the video is at an advanced level. Prerequisites and a good understanding
of VMware and Azure environments would be required to understand the content being discussed in this video.
I would recommend you study some basics around VMware and Azure and the tooling used (i.e networking, virtual machines, azure migrate, DR/Migration concepts) before watching this video. Thanks and good luck!