Azure Migrate

 Azure Migrate :

Microsoft Azure Migrate is a centralized migration hub provided by Microsoft Azure for discovery, assessment, right-sizing, dependency mapping, and migration of on-premises workloads to Azure.

It supports migration of:

  • VMware VMs
  • Hyper-V VMs
  • Physical servers
  • Databases
  • Web applications
  • VDI environments

Core Components of Azure Migrate

1. Discovery & Assessment

Using the Azure Migrate appliance, we perform:

  • Agentless discovery
  • Dependency visualization
  • Performance-based assessment
  • Application inventory
  • Server utilization analysis

The assessment provides:

  • Azure readiness
  • SKU recommendations
  • Cost estimation
  • Right-sizing recommendations
  • Reserved Instance estimation
  • Target region mapping

Typical outputs include:

  • VM sizing
  • Storage recommendations
  • Monthly TCO
  • Azure Hybrid Benefit analysis

 

2. Migration

Azure Migrate uses replication-based migration via:

  • Continuous replication
  • Incremental synchronization
  • Test migration
  • Planned failover
  • Cutover migration

For VMware migrations, Azure Migrate leverages:

  • Appliance-based replication
  • Agentless mobility service
  • Crash-consistent replication
  • Application-consistent snapshots

 

Landing Zone in Azure — Interview Terminology

A Landing Zone is a pre-configured, scalable, secure, and governance-aligned Azure environment designed according to the Cloud Adoption Framework (CAF) and Enterprise-Scale Architecture.

It establishes the foundational architecture before workload onboarding.

 https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/?utm_source=chatgpt.com&tabs=hubspoke

 

Components of an Azure Landing Zone

Identity & Access Management

  • Microsoft Entra ID integration
  • RBAC
  • PIM (Privileged Identity Management)
  • Conditional Access Policies
  • Managed Identities

 

Azure Templates :

 

An Azure template usually refers to an Azure Resource Manager (ARM) template or newer Bicep template used in Microsoft Microsoft Azure.

It’s a way to define and deploy cloud infrastructure using code — often called Infrastructure as Code (IaC).

What it is used for

Azure templates help you:

  • Create cloud resources automatically
  • Deploy the same environment repeatedly
  • Avoid manual setup mistakes
  • Version-control infrastructure like application code
  • Standardize deployments across teams

 

Example resources you can create

Using a template, you can deploy:

  • Virtual Machines (VMs)
  • Storage Accounts
  • Databases
  • Virtual Networks
  • Kubernetes clusters
  • App Services
  • Load Balancers
  • Security rules

1. ARM Templates

JSON-based templates used to describe Azure resources.

Official docs:

https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/overview?utm_source=chatgpt.com 

Example: 

 {
  "$schema": "...",
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "name": "mystorageaccount"
    }
  ]
}

 

2. Bicep Templates

A newer, simpler language from Microsoft for Azure deployments.

Official docs:

https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview?utm_source=chatgpt.com 

 Bicep is easier to read and is now preferred by many Azure engineers.

 

Why companies use templates instead of manual creation

Without templates:

  • Engineers click through Azure Portal manually
  • Easy to forget settings
  • Hard to reproduce environments

With templates:

  • Everything is automated
  • Consistent
  • Faster
  • Auditable

 

You can generate the Template from Azure through Portal too 

Yes. In Microsoft Azure you can work with templates directly from the Azure Portal (console level).

Where you find Azure templates in the Azure Portal

1. Export template from existing resources

If you already created resources manually:

  • Open a Resource Group
  • Select Export template

Azure generates an ARM template (JSON) for the current infrastructure.

 
What is a Landing Zone ? 

Do we creating the landing zone resources 

 Yes — in most enterprise Azure migrations, you typically create the Landing Zone first before migrating workloads.

In Microsoft Azure, a landing zone is the pre-configured cloud environment that provides the foundation for workloads and applications.

What is created in a Landing Zone

Before migration, teams usually set up core components such as:

  • Management Groups
  • Subscriptions
  • Resource Groups
  • Virtual Networks (VNets)
  • Connectivity (VPN / ExpressRoute)
  • Identity integration
  • RBAC permissions
  • Security policies
  • Monitoring & logging
  • Backup & disaster recovery
  • Governance policies
  • Cost management
  • Naming standards

 

Why create it before migration

If workloads are migrated without a landing zone:

  • security becomes inconsistent
  • networking may need redesign later
  • governance is harder
  • compliance gaps appear
  • resources become disorganized
  • migration rollback is difficult

So enterprises usually:

  1. Build landing zone
  2. Validate governance/security
  3. Configure networking/connectivity
  4. Then migrate workloads

Typical migration flow

Phase 1 — Assessment

Analyze:

  • servers
  • databases
  • dependencies
  • sizing
  • costs

Tools often used:

  • Azure Migrate

 

Phase 2 — Build Landing Zone

Create:

  • networking
  • identity
  • policies
  • monitoring
  • security baseline

Framework used:

Azure Cloud Adoption Framework 

Docs : https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/?utm_source=chatgpt.com&tabs=hubspoke

 

Phase 3 — Deploy shared services

Examples:

  • Domain Controllers
  • DNS
  • Firewalls
  • Bastion
  • Key Vault
  • Log Analytics

 

Phase 4 — Pilot migration

Move small/non-critical workloads first.

 

Phase 5 — Production migration

Move:

  • applications
  • databases
  • VMs
  • storage

using:

  • replication
  • backup restore
  • database migration
  • containerization

Infrastructure-as-Code in Landing Zones

Most companies automate landing zone creation using:

  • ARM templates
  • Bicep
  • Terraform

This ensures every environment is standardized.

 

DEPLOYING AZURE MIGRATE APPLIANCE ON-PREMISE 

Deploying Azure Migrate Appliance on-premises is one of the first steps in discovering and assessing your existing servers before migration to Microsoft Azure.

The appliance collects:

  • VM inventory
  • performance metrics
  • dependency mapping
  • sizing information
  • readiness assessments

from your on-prem environment.

 

High-Level Deployment Flow

Azure Portal
    ↓
Create Azure Migrate Project
    ↓
Download Appliance
    ↓
Deploy On-Prem VM
    ↓
Register Appliance with Azure
    ↓
Start Discovery
    ↓
Assessment & Migration

 

Step-by-Step Deployment

1. Create Azure Migrate Project

In Azure Portal:

  • Go to:
    Azure Migrate
  • Click:
    Create project

Select:

  • Subscription
  • Resource Group
  • Geography

 Portal:

https://learn.microsoft.com/en-us/azure/migrate/create-manage-projects?view=migrate-classic&utm_source=chatgpt.com

 

2. Choose Discovery Type

Azure supports:

  • VMware
  • Hyper-V
  • Physical servers
  • Other clouds

You select the environment type during setup.

 

This section is explaining that when you set up migration or discovery in Microsoft Azure, you first tell Azure what kind of infrastructure you want it to analyze or migrate.

“Discovery Type” means the source environment where your servers currently run.

Azure supports these source environments:

  • VMware → Virtual machines running on VMware vSphere/ESXi.
  • Hyper-V → Virtual machines running on Microsoft Hyper-V.
  • Physical servers → Non-virtualized machines (bare metal servers).
  • Other clouds → Servers running in clouds like AWS, GCP, etc.

During setup, Azure asks you to choose one of these because:

  • the discovery method changes,
  • the required appliance/tool changes,
  • and migration steps differ depending on the environment.

Example:

  • If your company uses VMware ESXi, choose VMware.
  • If servers are on Amazon EC2, choose Other clouds.
  • If you have normal standalone servers, choose Physical servers.

This is commonly part of configuring Azure Migrate, where Azure discovers servers, collects performance data, and helps plan migration to Azure.

 

3. Download the Appliance

From Azure Migrate:

  • Click Discover
  • Download:
    • OVA for VMware
    • VHD for Hyper-V
    • Installer script for physical server

 Official docs:

https://learn.microsoft.com/en-us/azure/migrate/migrate-appliance?view=migrate&utm_source=chatgpt.com 


4. Deploy Appliance On-Prem

For VMware

Import the OVA into:

  • VMware vCenter Server

Requirements typically include:

  • 8 vCPU
  • 16 GB RAM
  • ~80 GB disk
  • Internet connectivity to Azure

 

For Hyper-V

Import VHD into:

  • Microsoft Hyper-V

 

For Physical Server

Run installer on a Windows Server machine.

 

5. Configure Appliance

After VM boots:

Open browser:

 https://appliance-name-or-ip:44368

 

You will:

  • accept prerequisites
  • run connectivity checks
  • sign into Azure
  • register appliance

 

6. Add Discovery Credentials

Provide credentials for:

  • VMware vCenter
  • Hyper-V hosts
  • Windows/Linux servers

Azure Migrate uses these to collect metadata.

Best practice:

  • use read-only accounts where possible


7. Start Discovery

The appliance begins:

  • inventory collection
  • performance monitoring
  • dependency mapping

Discovery usually starts within minutes.

8. Perform Assessment

Azure Migrate generates:

  • Azure readiness
  • VM sizing
  • cost estimation
  • dependency reports

This helps plan migration waves.

Common Ports Needed

Examples:

 

SourceDestinationPort
ApplianceAzure443
AppliancevCenter443
ApplianceESXi hosts443
ApplianceWindows Servers135, WMI
ApplianceLinux Servers22

Microsoft port requirements:

https://learn.microsoft.com/en-us/azure/migrate/migrate-appliance?view=migrate&utm_source=chatgpt.com#urls-access-ports-and-data-collection-for-appliance-access-to-azure-public-cloud 

Best Practices

Before deployment

  • Ensure outbound internet access
  • Sync appliance time with NTP
  • Verify DNS resolution

During discovery

  • Use separate discovery accounts
  • Enable least privilege access
  • Start with pilot environment

For enterprise migrations

  • Deploy multiple appliances for scale
  • Separate by datacenter/region
  • Integrate with landing zone networking


Typical Architecture

 

On-Prem Datacenter
 ├── VMware / Hyper-V
 ├── Azure Migrate Appliance
 └── Servers

        ↓ HTTPS 443

Azure Migrate Project
        ↓
Assessment Reports
        ↓
Migration Planning 

After Discovery

Next stages usually are:

  1. Assessment
  2. Dependency analysis
  3. Landing zone readiness
  4. Replication setup
  5. Test migration
  6. Production cutover


What is Azure Migrate Appliance ?

 

Azure Migrate includes a component called the Azure Migrate Appliance, which is a lightweight virtual appliance used to discover, assess, and migrate servers, databases, and applications from on-premises environments to Microsoft Azure.

The appliance acts as a bridge between your on-premises infrastructure and Azure. It collects configuration, performance, and dependency data from systems running in environments like:

  • VMware vSphere
  • Hyper-V
  • Physical servers
  • Other clouds (such as AWS or GCP in some scenarios)

Microsoft provides official details here:
Azure Migrate documentation

What the appliance does

The Azure Migrate Appliance typically performs these tasks:

  1. Discovery
    • Detects servers and workloads in your environment
    • Collects hardware/software inventory
    • Maps dependencies between applications and servers
  2. Assessment
    • Evaluates readiness for Azure
    • Estimates sizing and costs
    • Identifies compatibility issues
  3. Migration support
    • Helps replicate workloads to Azure
    • Supports agentless or agent-based migration depending on the scenario
  4. Continuous data collection
    • Gathers CPU, memory, disk, and network utilization metrics
    • Uses this data for right-sizing recommendations

How it is deployed

The appliance is usually deployed as:

  • A VM in VMware
  • A VM in Hyper-V
  • A physical server
  • Sometimes as a scripted installer for specialized environments

It connects outbound to Azure over HTTPS and uploads metadata securely.

Main appliance types

Microsoft provides different appliance builds for:

  • VMware environments
  • Hyper-V environments
  • Physical/other cloud servers

Deployment guides are here:
Azure Migrate appliance deployment guides

Common use cases

Organizations use the appliance for:

  • Data center modernization
  • Cloud migration planning
  • Server inventory discovery
  • Dependency mapping before migration
  • Cost estimation for Azure adoption

Example workflow

A typical migration flow looks like:

  1. Create an Azure Migrate project
  2. Download and deploy the appliance
  3. Register the appliance with Azure
  4. Discover on-prem servers
  5. Run assessments
  6. Start replication/migration to Azure

Requirements

Typical requirements include:

  • Internet access to Azure endpoints
  • Appropriate virtualization permissions
  • Sufficient CPU/RAM for the appliance VM
  • Supported OS/platform versions

Related services

The appliance works with:

  • Microsoft Azure Site Recovery
  • Azure Database Migration Service
  • Azure Arc
  • Azure VMware Solution

If you want, I can also explain:

  • the architecture in detail,
  • how discovery works internally,
  • VMware vs Hyper-V appliance differences,
  • sizing requirements,
  • security/network ports,
  • or a step-by-step deployment walkthrough.

 Can we call it a Virtual machine 

Yes — in most deployments, the Azure Migrate Appliance is essentially deployed as a virtual machine (VM).





Comments

Post a Comment