Initially, the Azure Migrate Service offering focused on enabling users to discover and migrate to VMware virtual machines, Hyper-V virtual machines, and on-premise servers. Today, the Azure Migrate Service has evolved to accommodate more than just “lift-and-shift migration” projects. For example, the service now allows you to migrate workloads to the Azure Platform as a Service in what is known as a “replatforming migration.”
Azure Migrate’s Top 4 Use Cases
- Server Assessment: Discover and assess on-premises VMware VMs, Hyper-V VMs, and physical servers in preparation for migration to Azure.
- Server Migration: Migrate VMware VMs, Hyper-V VMs, physical servers, other virtualized machines, and public cloud VMs to Azure.
- Azure Database Migration Service: Can help you replatform your MSSQL, Postgres, and MySQL databases to Azure PaaS databases.
- Web app migration assistant: Can help you replatform your website that resided on IIS to Azure App Service .
Although it is becoming less common to use tools that are not integrated with the Azure Migrate offering, some worth noting are: Movere, which was acquired by Microsoft for server migrations, and Azure Data Box, which helps move massive amounts of data to Azure.
How Azure Migrate Service Helps
The Azure Migrate Service helps you with your migration projects using the following steps:
- Azure first acquires your data and begins testing
- Azure then identifies any blockers for migrations (both via lift-and-shift and replatforming)
- Azure finally performs the final migration on your behalf
In some scenarios, Azure Migrate can do a performance-based sizing, which provides cost estimations for running your on-premises machines in Azure. After the assessment, you can use services such as Azure Site Recovery (ASR) and Azure Database Migration Service, to migrate the machines to Azure.
The Architecture of Azure Migrate Service
When choosing the replatforming method for a migration project, you must install a VM “collector appliance” to help Microsoft discover information about your on-premises machines. This appliance collects VM metadata using various methods (e.g., VMware PowerCLI cmdlets) and discovery is agentless. Collected metadata includes information from resource cores, memory, disks, disk sizes, and network adapters.
Azure Migrate Service Flow
After performing an inventory check for all of your websites and databases, if any blockers are identified, it is then up to you and your team to resolve those issues. A replatforming migration cannot occur without those blockers being resolved. Alternatively, you can proceed via the lift-and-shift migration option, which is much more complicated but enables you to migrate all datacenters to Azure in replication stages.
Grouping and Visualization in Azure Portal
All of the data transferred into your Azure Migrate project can be viewed from the Azure Portal. From there, you can organize the discovered VMs into groups. Groups provide visualizations of the dependencies for any one machine or for all machines within the group. Once a group is formed, you create an assessment for the group.
After the assessment finishes, you can view it in the portal, download it in Excel format, or use PowerBI dashboards, like the one shown below:
Dashboard Visualization From PowerBI
Network Connections Visualization From PowerBI
Azure Migrate sends detailed reports on the state of the migration, including potential blockers and any relevant recommendations for what to do next.
The following is an example of a reported configuration error:
Line number: 122\\r\\nError: Cannot add duplicate collection entry of type 'compiler' with combined key attributes 'language, extension' respectively set to 'c#;cs;csharp, .cs'\\r\\n\\r\\n;
Message=Filename: \\\\\\\\?\\\\C:\\\\inetpub\\\\vhosts\\\\app.example.com\\\\web.config\\r\\nLine number: 108\\r\\nError: Unrecognized attribute 'enableSsl'\\r\\n\\r\\n
For massive scale data center migration, you can also review consolidated reports, like the one shown below:
Consolidated Report Example
Azure Readiness Check
You can review the readiness of your resources for migration by checking the Azure Readiness view. The most important statuses to pay attention to are: “Ready with conditions” and “Not ready for Azure.” For these VMs, Azure Migrate explains what the issues are and provides remediation steps.
Azure Migrate considers several data points when making this determination, such as: boot type, cores, memory, storage disks, networking components, and operating system.
Azure Readiness Visualization
Azure Site Recovery
After the assessment comes the migration. In the case of PaaS Services, this simply means taking the next step of the setup wizard. VMs and physical servers get migrated to Azure Site Recovery, by replicating your VMs.
Let’s first take a look at the service architecture of Azure Site Recovery which help perform the replication, before we examine any replication steps.
Site Recovery Service Architecture
The following components make up the Azure Site Recovery Service:
- Configuration server: Coordinates communications between on-premises servers and Azure; also manages data replication.
- Process server: Receives and optimizes replication data with caching, compression, encryption, and sends it to Azure storage; acts as a replication gateway.
- Master target server: Handles replication data during failback from Azure (not necessary in Migration Scenario).
- Mobility Service: Captures and forwards data-writes on a given machine to the process server.
Mobility Service can only be installed on 64-bit systems and supported Linux Systems (e.g., Debian, CentOs, Ubuntu). The Mobility Service does not support Dynamic Raid 1 disks in Windows; Secure Boot is also not fully supported. For more information, refer to this Azure guide.
The final step in your Azure Migrate journey is replication, which occurs when source machines are working properly. Replication can be controlled from the Azure Portal, PowerShell Scripts, or via the Azure API.
The replication process differs based on what is being replicated.
Replicating VMware & Physical Machines
Dedicated machines (process servers) are required for VMware and physical machines to receive information about VMs (e.g., disk sector changes) and push that information to Azure. A Mobility Agent must be installed on every source VM; for mass scaling, the agent can be provisioned automatically.
High-level Site Recovery Steps
- Download the Vault Registration Key
- Install Process Server
- Write Passphrase
- Add Account to VM, Physical Servers, vCenter, or ESXi
- Install Mobility Service on Every VM and/or physical server
Microsoft Azure Site Recovery Provider is needed for Hyper-V recovery preparation. Replication is based on the Hyper-V Replica subsystem and also works on Hyper-V Free servers and/or Core Servers. Hyper-V does not require a Mobility Agent, making it less complex to scale
High-level Site Recovery Steps
- Download the Vault Registration Key
- Install Azure Site Recovery Provider
Hyper-V Replication Flow
Site Recovery Deployment Planner
The Azure Site Recovery Deployment Planner is a dedicated command-line tool for gathering planning information that is compatible with Hyper-V and VMware servers. This deployment planner generates an Excel report containing the following information:
- On-premises summary
- VM storage placement
- Compatible VMs
- Incompatible VMs
- On-premises storage requirement
- Initial Replication batching
- Cost estimation
Deployment Planner Visualization
Site Recovery with Virtual Machine Manager
Virtual Machine Manager (SCVMM) is designed for the management of large numbers of Virtual Servers based on Microsoft Virtual Server and Hyper-V. SCVMM helps utilize Azure Site Recovery on a massive scale, even from GUI.
Virtual Machine Manager
Azure Migrate is certainly worth checking out, especially considering that the service is free. Moreover, we recommend doing the Assessment, especially for your databases (even if you do not plan any migration). Why? Because not only is Azure Migrate a great inventory tool, it’s also useful for generating database reports to detect orphaned resources (e.g., stored procedures that no longer work due to missing query tables).
Even when your architecture is not eligible for a replatforming migration, lift-and-shift migration remains an option. This can be a sensible approach for the smallest systems or a temporary solution if there is a strong business reason forcing you to leave the data center. However, it should be understood that this approach will not take advantage of any of the benefits of the cloud and will likely cost more. Lift-and-shift migrations are essentially lateral moves where the systems move from a data center, as is, to the cloud. While your architecture remains unchanged. If you would like to take advantage of auto-scaling and fault tolerance in the cloud, then replatform or even re-architecting would be recommended.