TL;DR. Azure migration spans five phases, each with dedicated tooling: discovery (Azure Migrate), assessment (Azure Migrate Assessment for sizing and cost), migration (Azure Site Recovery for VMs, Database Migration Service for databases, Data Box for bulk data), optimisation (Azure Advisor), and governance (Terraform plus an IDP like Cycloid for Day 2 ops). Most teams over-invest in phases 1-3 and under-invest in phase 5, which is where the operational cost compounds.
Azure migration involves at least five tool categories, and using a phase-1 tool for phase-3 work is where projects lose weeks. Gartner forecasts that 75% of enterprise workloads will run in cloud or edge environments by 2028, up from 52% in 2024, so the tooling question has moved from “if” to “which, and when.”
This guide maps Azure migration tools across each phase and workload type – from Microsoft’s native tooling to third-party alternatives – and covers what most migration guides treat as an afterthought: how to govern the migrated estate once workloads are running in production.
Azure migration phases: which tools cover which phase?
Migration projects fail when teams treat the whole process as a single event. It isn’t. Azure migration breaks into five distinct phases, each with dedicated tooling.
Phase 1: Discovery
Azure Migrate handles discovery. It scans on-premises environments – VMware, Hyper-V, physical servers, AWS VMs – and builds an inventory of servers, applications, and dependency mappings. Microsoft added SAP systems discovery in public preview during 2025 (documented in the Azure Migrate release notes) and expanded coverage for Linux distributions, so discovery now reaches a wider range of enterprise workloads than it did a year ago.
What Azure Migrate produces at this stage: a map of your servers, their interdependencies, and the applications running on them. Without it, assessment is guesswork.
Phase 2: Assessment
Azure Migrate Assessment takes the discovery inventory and evaluates readiness. It calculates sizing recommendations, compatibility checks, and cost estimates for each workload. The application-aware assessment feature groups all resources in an application together, providing both technical readiness and business insights (ROI and TCO) for migrating entire applications with their dependents.
Microsoft added sustainability insights to the Business Case tool in 2025 (public preview), which estimates carbon emissions savings when migrating on-premises resources to Azure. For organisations reporting under CSRD, that data matters at the board level.
Phase 3: Migration
This is where tooling fragments by workload type:
| Workload | Tool | What it does |
| VMs (lift-and-shift) | Azure Site Recovery (ASR) | Replicates on-prem VMs to Azure with minimal downtime. Recent updates include UEFI boot servers and expanded AWS guest OS coverage. |
| Databases | Azure Database Migration Service (DMS) | Online and offline migration for SQL Server, MySQL, PostgreSQL to Azure SQL, Managed Instance, and Azure Database services. |
| Large data transfers | Azure Data Box | Physical device for shipping terabytes or petabytes when network transfer isn’t practical. |
| Web apps | App Service Migration Assistant | Assesses and migrates .NET and Java web apps to Azure App Service. |
| Data pipelines | Azure Data Factory (ADF) | Moves and transforms data at scale from on-prem or other clouds into Azure data services. |
No single tool covers every workload type. A typical enterprise migration uses three or four of these in parallel, which is why the discovery and assessment phases matter so much – they tell you which tool to apply where.
Phase 4: Optimisation
Once workloads land in Azure, Azure Advisor provides recommendations across reliability, security, performance, cost, and operational excellence. Azure Cost Management tracks spending against budgets and flags waste. Both are reactive: they surface problems after deployment. They don’t stop misconfigurations from happening in the first place.
Phase 5: Governance
Phase 5 is where the operational cost compounds. Azure Policy and Azure Blueprints handle basic guardrails (allowed regions, required tags, denied SKUs), but they operate at the Azure resource layer only. For organisations running hybrid or multi-cloud estates, or teams that need IaC-driven governance across the full stack, you need a platform layer above the cloud provider.
That layer is an Internal Developer Platform. Cycloid’s IDP sits above the cloud provider and governs the migrated estate through Terraform and Ansible-based Stacks, self-service provisioning via StackForms, drift detection, and cost visibility across providers. It becomes the single control plane for Day 2 operations: who can deploy what, where, and at what cost. Migration is a separate problem with its own tools.
Azure migration tools by workload type
If you already know what you’re migrating, start here. The phase-based model tells you when to use each tool; this section tells you which tool matches your workload.
VM migration centres on Azure Site Recovery. ASR handles replication from VMware, Hyper-V, physical servers, and AWS. For agentless migration, Azure Migrate’s integrated migration tool handles VMware VMs without installing anything on source machines. If you’re containerising instead of lifting-and-shifting, look at App Service Migration Assistant for web apps or a re-architecture approach using AKS.
Database migration runs through Azure Database Migration Service. It supports SQL Server to Azure SQL Database (or Managed Instance), MySQL to Azure Database for MySQL, PostgreSQL to Azure Database for PostgreSQL, and MongoDB to Azure Cosmos DB. SQL Server Migration Assistant v10.5, released February 2026, adds AI-assisted code conversion for Sybase (via Copilot) and expanded Oracle PL/SQL to T-SQL coverage.
Data migration at scale uses Azure Data Box for physical transfers or Azure Data Factory for network-based movement. Data Box makes sense when you’re moving tens of terabytes or more and network bandwidth would make transfer impractical – the crossover is typically around 10 TB, depending on bandwidth and timeline.
Native Microsoft Azure migration tools vs third-party
Microsoft’s native tools have two clear advantages: they’re free (included with Azure subscriptions) and deeply integrated with the Azure control plane. Azure Migrate’s discovery feeds directly into assessment, which feeds into ASR or DMS. The data flows without export/import steps.
The trade-off is lock-in. Native tools are Azure-only by design. If you’re running a multi-cloud strategy – or might be in two years – the migration tooling doesn’t transfer. That matters more now than it did a year ago: Gartner expects 20% of current workloads to move from global hyperscalers to local cloud providers, driven by sovereignty and cost.
Third-party tools like AWS Application Migration Service (formerly CloudEndure), Carbonite Migrate, and Zerto offer multi-cloud support and, in some cases, more automation around cutover orchestration. They add cost, and they add flexibility if your migration isn’t exclusively Azure-bound.
Where does Cycloid sit in this picture? Not as a migration tool. Cycloid enters after migration, as the governance and orchestration layer for the migrated estate. Terraform-driven compliance and policy-as-code enforcement apply whether you migrated with native tools or third-party ones.
Post-migration governance: how to manage the migrated estate with IaC
Migration projects share a well-documented pattern: intense focus during the move, then a governance vacuum once workloads are running. Teams spend months planning the migration and days planning how to operate the result. Six months later, the Azure bill is over forecast, three teams have deployed resources outside approved patterns, and nobody knows which Terraform state files are current.
The numbers back this up. IDC reports that 38% of cloud migrations exceed their original budget, with an average overrun of 23%. Most of that overrun shows up post-migration, in the form of orphaned resources, oversized VMs, and shadow IT that no one tagged.
IaC-driven governance closes the gap. The principle: every resource defined in code, provisioned through approved templates, visible in a single inventory.
In practice, this means:
Golden paths for provisioning. Instead of giving developers raw Azure portal access, you define pre-approved deployment templates (Cycloid calls these Stacks) that encode your organisation’s standards – naming, tagging, networking, security groups. Developers self-serve through a portal. They get autonomy. You get consistency.
Drift detection. Resources change after deployment – manual console edits, emergency fixes that never get committed to code. An IDP continuously compares actual state against declared state and flags deviations before they compound.
Cost visibility tied to projects, not just subscriptions. Azure Cost Management tracks spending by subscription and resource group. An IDP maps costs to projects, environments, and teams – the unit your organisation actually budgets against. Cycloid’s FinOps capabilities add cloud cost estimation before deployment, so teams see the price tag before they provision, not after.
For organisations managing a hybrid cloud environment post-migration – some workloads in Azure, some still on-premises or in another cloud – this governance layer is where operational complexity either gets managed or spirals.
Azure migration for MSPs: building a repeatable framework
MSPs face a specific version of the migration problem: every client has different source environments, compliance requirements, and Azure subscription structures, but the migration approach needs to be repeatable to protect margins. We’ve seen this firsthand with MSP partners like OBS and Valiantys, who use Cycloid to turn per-client setup into a templated workflow rather than a bespoke project.
A repeatable Azure migration framework standardises three things:
Parameterised IaC templates. One set of Terraform modules that accept client-specific variables (subscription IDs, networking CIDRs, compliance tags, region constraints). The infrastructure pattern stays consistent; the configuration changes per client.
Per-client governance boundaries. Each client needs isolated environments with their own RBAC, cost tracking, and policy enforcement. Cycloid’s multi-tenancy model (child organisations) supports this natively – each client operates in their own organisational boundary while the MSP keeps visibility and control across the portfolio.
Consistent post-migration handoff. Once migration completes, the client’s team (or the MSP’s operations team) needs a self-service portal to manage Day 2 operations without rebuilding tooling from scratch. StackForms provide that interface layer – the IaC complexity stays hidden behind forms that match each client’s approved options.
Without a framework like this, MSPs build bespoke tooling per client. That eats margins and doesn’t scale.
Frequently asked questions
What are the best migration tools for Azure?
It depends on what you’re migrating. Azure Migrate handles discovery and assessment across all workload types. For the actual migration, Azure Site Recovery covers VM lift-and-shift, Azure Database Migration Service handles database migrations (SQL Server, MySQL, PostgreSQL), and Azure Data Box manages large-scale physical data transfers. Third-party options like Carbonite and Zerto add multi-cloud flexibility. Post-migration, you need governance tooling – Azure Policy for basic guardrails, or an IDP like Cycloid for IaC-driven governance across the full estate.
What is Azure Migrate used for?
Azure Migrate is Microsoft’s free, centralised hub for discovering and assessing on-premises workloads before migration. It scans VMware, Hyper-V, physical servers, and AWS environments to build a server inventory with dependency mappings. It then assesses Azure readiness, calculates sizing and cost estimates, and generates business cases including ROI, TCO, and (since 2025) carbon emissions estimates. Azure Migrate also integrates migration tools for VMs and databases, though the actual migration uses ASR or DMS under the hood.
How do you use Terraform for Azure migration?
Terraform doesn’t perform the migration itself – ASR and DMS handle the actual data movement. Terraform’s role starts during and after migration: defining the target Azure infrastructure (VNets, NSGs, storage accounts, managed databases) as code before workloads arrive, then managing that infrastructure through its lifecycle. Post-migration, Terraform becomes the primary governance mechanism – all changes go through code review, state is tracked, and drift gets detected. Pairing Terraform with an IDP adds self-service provisioning and policy enforcement on top.
What tools do you need for an Azure migration project?
A typical Azure migration project uses tools across five phases. Discovery and assessment: Azure Migrate. VM migration: Azure Site Recovery. Database migration: Azure Database Migration Service. Data transfer: Azure Data Box or Azure Data Factory. Post-migration optimisation: Azure Advisor and Cost Management. Post-migration governance: Azure Policy for basic rules, plus an IaC-driven platform (Terraform with an IDP like Cycloid) for self-service provisioning, drift detection, and cost control across the migrated estate.
Govern your Azure migration with Cycloid IDP
Migration gets your workloads to Azure. Cycloid’s IDP governs them once they’re there: self-service provisioning, drift detection, cost visibility, and policy-as-code enforcement across your estate.
