Azure migration: how to move servers, databases and files to Azure

Create a project in a resource group, and choose the geography where its discovered metadata is stored. Microsoft says the geography is only for metadata: you can still assess and migrate to other regions. Full steps are in set up the Azure Migrate appliance.

Download the OVA (VMware), VHD (Hyper-V) or PowerShell installer (physical and other clouds). Register the appliance with the project key, add credentials for vCenter, hosts or servers, and add SQL Server credentials so databases are discovered too. Select Start discovery. One appliance discovers up to 10,000 VMware servers, 5,000 Hyper-V servers or 1,000 physical servers.

Leave the appliance running over a representative period, including month-end or seasonal peaks. Assessments are a point-in-time snapshot, and performance-based sizing is only as good as the data behind it.

Assess servers for Azure VMs, SQL Server for Azure SQL targets and web apps for App Service. Choose the target region, sizing (performance-based or as-is) and comfort factor (a buffer for peaks and growth). Microsoft calculates readiness first: a server that fails readiness is marked unsuitable and gets no size or cost.

Use agentless dependency analysis to see which servers talk to each other. Microsoft says dependent workloads cause outages if they are not migrated together, and to group them when in doubt.

Choose Modernize with PaaS (prefers managed services) or Migrate to all IaaS (lift and shift). The business case compares on-premises and Azure total cost of ownership over several years and includes savings from Azure Hybrid Benefit and Extended Security Updates. Many on-premises costs are Microsoft defaults; replace them with your real figures in the assumptions. Check the vendor's current pricing for anything you quote.

Microsoft's strategies are: retire (switch off), rehost (move with minimal changes), replatform (move to a managed platform with minimal code changes), refactor, rearchitect, rebuild, replace (with software as a service) and retain (leave as is). Use the table below for the common routes, and the decision helpers for which Azure SQL target and which VMware exit path.

Put development, test and low-risk internal workloads in the first waves, and critical systems later. Microsoft suggests adding one or two complex workloads to early waves to expose problems, planning only the next wave in detail, and avoiding busy business periods such as financial close.

Decide the management group hierarchy and which subscriptions hold shared services (connectivity, identity, management) and which hold workloads. Microsoft says this is the decision that matters before workloads migrate. A subscription per workload makes cost allocation easier but is not required.

Microsoft says its accelerators (infrastructure as code templates for platform and workload landing zones) are the fastest path for most organisations. Deploy with Bicep, Terraform or another repeatable method rather than one-off portal changes, so the next environment matches.

Apply only the policies that prevent risk during migration: restrict allowed regions, deny unmanaged public internet exposure and require diagnostic settings for central logging. Set budgets and alerts with a named owner. Do not let a perfect tagging scheme delay the build.

az group create --name rg-migrate --location <region>
az consumption budget list --output table

Create a hub virtual network for shared connectivity and spoke virtual networks for workloads, with subnets per tier, plus an isolated network for test migrations. Microsoft warns against one network with one subnet holding everything. Check nothing overlaps your on-premises address ranges.

az network vnet create --resource-group rg-migrate --name vnet-workloads --address-prefix 10.20.0.0/16 --subnet-name snet-servers --subnet-prefix 10.20.1.0/24
az network vnet create --resource-group rg-migrate --name vnet-test --address-prefix 10.99.0.0/16 --subnet-name snet-test --subnet-prefix 10.99.1.0/24

Choose VPN Gateway or ExpressRoute on throughput, latency, compliance and lead time. Microsoft says not to use the Basic VPN SKU for production migrations, and that ExpressRoute can take weeks or months to arrange, so run a VPN in parallel if dates are fixed.

Make on-premises names, Azure private DNS zones and any private endpoints resolve from a spoke network, and name an owner for forwarders and zones.

Resolve-DnsName app01.contoso.com

Create Entra ID groups for platform admins and an emergency access account. For servers that still need Kerberos, LDAP or Group Policy, decide whether domain controllers and Active Directory sites must exist in Azure before cutover. The longer-term move of users and devices is in Active Directory to Entra ID.

VMware: choose agentless migration through the discovery appliance. Hyper-V: install the Hyper-V Replication provider on every host or cluster node. Physical servers, other hypervisors and other clouds: build a separate replication appliance (not the discovery appliance and not a source server) and install the Mobility service on each server. Choose the size, disk type, network and Azure Hybrid Benefit for each VM.

Always test into the isolated test network, because the test VM is a full copy with the same name. Sign in, check services and run the application's smoke tests. Then select Clean up test migration.

Stop the application, choose to shut down the source so a final copy runs, and select Migrate. Then update DNS and firewall rules for the new private IP address.

Check readiness for Azure SQL Database, Azure SQL Managed Instance and SQL Server on Azure VMs, and the recommended service tier and size for each.

Managed Instance link (needs Azure Arc on the SQL Server) replicates in near real time to Managed Instance, so downtime is only the final cutover. Azure Database Migration Service does offline copies to all three targets and online copies to Managed Instance and Azure VMs. Backup and restore to SQL Server on an Azure VM is offline: downtime lasts until the restore finishes.

Recreate logins, SQL Agent jobs and other server-level objects on the target before cutover, then stop writes, complete the copy and change connection strings.

Windows Server 2016 or later: install Azure File Sync in place. NAS or Linux SMB shares: Azure Storage Mover (SMB 2 and 3; SMB 1 is not supported) or Robocopy. Very large data over a slow link: Azure Data Box (offline, by shipping a device). AzCopy suits small, simple copies only, because Microsoft says it may lose some file fidelity and handles up to 10 million files per job.

Set the Windows ACLs on the root of each share before the bulk copy. Microsoft warns that root permission changes made after a large copy can take a long time to apply. For a quick one-off copy with AzCopy, see copy files with AzCopy.

azcopy copy 'C:\myDirectory' 'https://mystorageaccount.file.core.windows.net/myfileshare?<SAS-token>' --recursive --preserve-permissions=true --preserve-info=true

Run repeat copies so only changes move (Robocopy /MIR, Storage Mover re-runs, or Azure File Sync), make the source read-only, run a final pass, then repoint drive mappings and paths.

The appliance discovers ASP.NET web apps on IIS (VMware and physical environments). Assess them for Azure App Service. Apps rated ready or ready with conditions can be migrated in bulk.

For many apps in a VMware estate, use Azure Migrate's at-scale web app migration, which Microsoft says handles up to five App Service plans per run. For apps on a single Windows server, use the App Service Migration Assistant or its PowerShell scripts, linked from Microsoft's page.

Test the app on its azurewebsites.net address, add your custom domain and certificate in App Service, then change the DNS record in the change window.

Microsoft says to set rollback criteria and procedures before any migration, get written stakeholder approval and name who can decide on a rollback. Schedule cutovers in maintenance windows or off-peak hours.

Lower the TTL on every record you will change a few days before the window, so clients pick up the new addresses quickly.

Stop the application, run the final copy for each server, database and share in the wave, then repoint DNS, connection strings and drive mappings. Run acceptance tests with each owner.

Turn on backup, update management and Defender for Cloud for every migrated VM, database and share, and confirm a first backup completes.

Advisor suggests resizing or shutting down underused VMs. It looks at 7 days of data by default; change the lookback to 30, 60 or 90 days under Configuration > Resources > VM/Virtual Machine Scale Sets right sizing so month-end peaks count. Its savings use retail rates and ignore reservations and savings plans.

az advisor recommendation list --category Cost --output table

After the rollback window, complete each migration so replication stops. Power off and remove source servers, remove them from backup jobs, and update documentation.