Azure migration spans five phases with dedicated tools: (1) Discovery – Azure Migrate, (2) Assessment – Azure Migrate Assessment for sizing and cost, (3) Migration – Azure Site Recovery for VMs, Database Migration Service for databases, Data Box for large transfers, (4) Optimisation – Azure Advisor, (5) Governance – Terraform and an IDP like Cycloid for ongoing management. Picking the wrong tool for the wrong phase is the most common migration mistake.
Azure migration involves at least five tool categories, and picking the wrong one for the wrong workload creates expensive rework. With 62% of organisations now operating a formal migration and modernisation strategy, and Azure running significant workloads in nearly half of all enterprises, the tooling question has moved from “if” to “which, and when.”
This guide maps migration tools for Azure across each phase and workload type – from Microsoft’s native tooling to third-party alternatives – and covers the part most migration guides skip: 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. Confusing the phases – or using a Phase 3 tool for Phase 1 work – is where projects lose weeks.
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. The 2025 updates added SAP systems support (public preview) and expanded coverage for Linux distributions, so discovery now covers a wider range of enterprise workloads than it did a year ago.
What Azure Migrate produces at this stage: a complete map of your servers, their interdependencies, and the applications running on them. Without this, assessment is guesswork.
Phase 2: Assessment
Azure Migrate Assessment takes that inventory and evaluates readiness. It calculates sizing recommendations, compatibility checks, and cost estimates for each workload. The newer application-aware assessment feature groups all resources in an application together, providing both technical readiness and business insights (ROI and TCO analysis) for migrating entire applications with their dependent workloads.
Microsoft also added sustainability reporting to the Business Case tool in 2025 – it now 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. Now supports 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, or Azure Database services. Expanded to new Azure regions in 2025. |
| Large data transfers | Azure Data Box | Physical device for shipping terabytes or petabytes of data 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 all workload types. 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 identifies waste. These are reactive tools – they flag problems after deployment. They don’t prevent misconfigurations from happening in the first place.
Phase 5: Governance
This is the phase most migration guides treat as an afterthought – and it’s where the real operational cost sits. 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.
This is where an Internal Developer Platform like Cycloid’s IDP fits. It doesn’t migrate workloads – it governs the migrated estate through Terraform and Ansible-based Stacks, self-service provisioning via StackForms, drift detection, and cost visibility across providers. The IDP becomes the single control plane for Day 2 operations: who can deploy what, where, and at what cost.
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 consider 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. Microsoft released SQL Server Migration Assistant v10.5 in early 2026, expanding support for SQL Server 2025 upgrade assessments.
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 the 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.
Third-party tools like CloudEndure (now AWS Application Migration Service), Carbonite Migrate, and Zerto offer multi-cloud support and, in some cases, more automation around cutover orchestration. They add cost, but they also add flexibility if your migration isn’t exclusively Azure-bound.
Where does Cycloid sit in this picture? It’s not a migration tool. It doesn’t compete with ASR or DMS. Cycloid enters after migration, as the governance and orchestration layer for the migrated estate. Think of it as the difference between moving furniture into a house and actually running the household – different job, different tooling. 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 have 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 40% over forecast, three teams have deployed resources outside approved patterns, and nobody knows which Terraform state files are current.
IaC-driven governance closes this gap. The principle: every resource should be defined in code, provisioned through approved templates, and 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 conventions, 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 – which is how your organisation actually thinks about budgets. 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.
Building a repeatable Azure migration framework means standardising 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 maintains 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 this kind of framework, MSPs build bespoke tooling per client. That eats margins and doesn’t scale.
Frequently Asked Questions
What are the best migration tools for Azure?
The answer 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, 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, cost visibility, and policy-as-code enforcement across your entire estate.
