Cloud migration
Migrate to Microsoft Azurefor enterprise-grade hybrid cloud and security
Azure Migrate discovers and assesses your workloads and moves servers by several different paths. The decisions it can't make for you are identity, database target and landing zone.
Start with Azure Migrate's discovery and assessment
Azure Migrate is Microsoft's free hub for finding what you have, assessing it and moving it. Partner tools inside it may charge separately. Discovery normally runs through a lightweight appliance deployed in your data centre, which keeps sending configuration and performance data. For air-gapped or restricted networks, Azure Migrate Collector takes a snapshot without continuous connectivity.
The assessment covers readiness, right-sizing and cost, and dependency analysis shows the network connections between your servers. That last item is what we would look at first. Grouping servers by real traffic prevents the classic failure: moving an application and leaving behind the small file server or licence service it silently relies on.
The server paths differ
- VMware VMs can move agentless, using the same appliance as discovery, or agent-based, using a replication appliance.
- Hyper-V VMs use provider agents installed on the Hyper-V host.
- Physical servers, and VMs on other public clouds, are treated as physical servers and go through a replication appliance.
- ASP.NET web apps on Windows in a VMware environment can move agentless to Azure App Service at scale.
- Very large data sets can travel offline using Azure Data Box.
Databases
For SQL Server, Azure Migrate assesses instances and databases against three targets: SQL Server on an Azure VM, Azure SQL Managed Instance and Azure SQL Database. The choice matters. A VM behaves like what you have, Managed Instance keeps much of the instance-level feature set, and Azure SQL Database is the most managed and the least accommodating of features such as cross-database queries. Feature use in your code often decides this for you.
For MySQL, Azure Database Migration Service can move workloads online to Azure Database for MySQL flexible server, and Microsoft added support for migrating to MySQL 8.4 in June 2026. A jump in major version during the move adds its own risk: stricter SQL modes, changed defaults and queries that used to pass can all fail, so we test the application against the target version first.
What doesn't come from the tooling
- Identity. If you have on-premises Active Directory, decide how it relates to Microsoft Entra ID before moving the applications that use it.
- A landing zone: subscriptions, networking, policy and budgets set up ahead of the first workload.
- Windows and SQL Server licensing. Check what your existing licences allow in Azure before comparing costs.
- Application configuration that names servers or paths directly, which only surfaces when something stops working.
What we can show you
We have no published Azure migration case study. Our direct Microsoft experience is integration: websites and a WooCommerce store connected to Microsoft Dynamics for Belgian clients, and .NET desktop software for a Qatar company that was later rebuilt in Electron. Those don't amount to a data-centre move, and we won't present them as one. They do mean we understand the applications you would be moving.
Azure migration questions
Does Azure Migrate cost anything?
Microsoft describes the service itself as free for discovery, assessment, planning and migration. Partner tools may charge for their services, and the Azure resources you run during and after the move are billed normally.
Can we use this to leave AWS for Azure?
Servers, yes: VMs on other public clouds are treated as physical servers and go through a replication appliance. Managed services on AWS need separate planning, because no tool copies them across.
What runs where, and on which licences?
Tell us about your servers, your SQL Server or MySQL versions and your identity setup. We will say what we can take on and where you need a specialist partner.
We reply within one business day (IST).