Listen to this article
Most Azure cloud migration guides tell you the same things: assess your workloads, pick a strategy, use Azure Migrate, and optimise post-migration. That advice is accurate, but it stops short of what decision-makers practically need. It’s important to provide the reasoning behind the sequencing, discuss the costs that don’t appear in vendor calculators, and describe what your migration looks like twelve months in.
In this guide, we aim to provide a comprehensive overview of Microsoft Azure cloud migration.
What is Azure cloud migration?
Azure cloud migration is the process of moving your organisation’s workloads from on-premises infrastructure or another cloud environment to Microsoft Azure. The workloads can include servers, applications, databases, and data. For most enterprises, it is a structured programme that unfolds in phases over months. Different workloads may move at different speeds depending on their complexity, compliance requirements, and business criticality.
A migration covers three distinct scenarios:
- On-premises to Azure: The most common path, moving datacentre resources to Azure IaaS or PaaS services
- Cloud-to-cloud: Migrating workloads from AWS or Google Cloud to Azure, typically as part of a vendor consolidation or Microsoft ecosystem alignment strategy
- Hybrid migration: Retaining selected workloads on-premises for regulatory or latency reasons while moving others to Azure
How to decide which workflows move first during an Azure cloud migration?
Most migration content skips directly to strategy frameworks without addressing the harder question: in what order do you migrate, and why does that order matter?
Migration sequencing is not a technical decision. Instead, the order needs to be strategic. The sequencing choice determines how much risk you carry at any given moment, how quickly your team builds cloud operational competence, and whether your most critical systems migrate under proven conditions or experimental ones.
Don’t migrate by business unit or infrastructure type. A more practical way is to organise workloads into waves based on two dimensions:
- Business impact (what breaks if this fails?)
- Migration complexity (how many dependencies, integrations, and constraints does this workload carry?)
| Migration Wave | Characteristics | Examples |
|---|---|---|
| Wave 1: Prove it | Low complexity, low business impact. Disposable if something goes wrong | Dev/test environments, internal tools, archived data |
| Wave 2: Build confidence | Moderate complexity or impact. Demonstrates capability to the business | Non-critical web apps, collaboration workloads, monitoring systems |
| Wave 3: Core systems | High business impact. Migrate after your team demonstrates Azure operational competence | ERP, CRM, production databases, core line-of-business apps |
| Wave 4: Mission-critical | Highest risk. Migrate last, with extended testing and rollback planning | Core financial systems, patient data, real-time transaction processing |
One underused tactic from Microsoft's Cloud Adoption Framework is to include one or two complex workloads in early waves. This approach surfaces dependency and compatibility issues before you deal with production-critical systems.
Azure cloud migration strategy: How to choose the right approach per workload?
Microsoft's Cloud Adoption Framework uses the 6Rs to categorise migration strategies. In practice, it's about understanding when each approach is and isn't appropriate.
| Strategy | When to use it |
|---|---|
| Rehost (Lift-and-Shift) | Best when speed is the priority, and the workload runs cleanly on virtual machines (VMs). Avoid for workloads with known performance or architecture problems; migration carries technical debt into Azure |
| Replatform | The right call when you want cloud-managed services without a full rebuild. For example, moving from self-managed SQL Server to Azure SQL Managed Instance. A strong middle path for most mid-market organisations |
| Refactor | Worth the investment when cloud-native patterns like containers or microservices will improve long-term cost or performance. Budget more engineering time than you think you'll need |
| Rearchitect | Appropriate when the current architecture is actively limiting scalability or reliability, and a workaround isn't realistic. Higher investment needed, so reserve this for systems with a long-expected lifespan |
| Replace (SaaS swap) | Makes sense when a SaaS alternative meets your functional requirements with less operational overhead. Common candidates include HR platforms, CRM systems, and collaboration tools |
| Retire | For workloads with no active users or clear business justifications. Discovery exercises usually identify 10–15% of an estate as retirement candidates |
It is worth noting that strategy assignments are not permanent. They should be revisited if modernisation timelines shift, if a SaaS alternative matures, or if the workload's usage profile changes materially after migration.
How does the Microsoft ecosystem advantage change your migration economics?
If your organisation already runs Microsoft technology, migrating to Azure becomes an extension of the infrastructure you already own and manage. This scenario carries specific economic and operational implications.
Azure hybrid benefit
Organisations with existing Windows Server and SQL Server licences covered by Software Assurance can apply those licences to Azure VMs and Azure SQL services. Therefore, there is no cost of purchasing new cloud licences. This benefit is frequently underutilised because it requires intentional licence tracking during migration planning, which Azure Migrate does not automate.
Identity continuity via Microsoft Entra ID
Organisations running Active Directory on-premises can achieve native hybrid identity with Microsoft Entra ID. User accounts, group policies, and conditional access policies extend directly into Azure. There is no need to rebuild identity infrastructure from scratch, which is a migration dependency that costs significant time and risk on other cloud platforms.
Copilot and AI readiness as a migration outcome
Microsoft's Copilot capabilities across M365, Dynamics 365, and Azure services are native to the Azure environment. Organisations that complete their Azure cloud migration are positioned to activate AI features across their Microsoft stack without additional infrastructure work. For decision-makers evaluating AI adoption timelines, Azure migration and AI readiness are now effectively the same programme.
What is the cost of an Azure cloud migration?
Azure migration does reduce infrastructure costs for most organisations over a 3 to 5-year horizon. But the costs incurred during and immediately after migration are routinely underestimated. This gap creates budget surprises that damage the programme's credibility internally.
According to Flexera's 2025 State of the Cloud Report, 17% organisations exceed their cloud budgets. Some of the common culprits are:
Egress fees
Network egress charges are an underestimated cost driver during initial migrations. These do not appear in pre-migration estimates based solely on compute and storage.
Skills gap costs
Cloud expertise remains one of the most contested skillsets in enterprise IT. Training existing staff takes time and temporarily reduces productivity; bringing in external expertise adds direct cost. Either way, it needs a line in the budget.
UK organisations bringing in contract expertise should also factor in IR35 assessments, which can add cost and administrative overhead beyond the day rate itself.
Organisations that consider skills development as a post-migration concern will face slowing down of the optimisation work that delivers ROI.
Licence complexity
Migrating Windows Server and SQL Server without upfront auditing of Hybrid Benefit eligibility creates either unexpected spend or compliance risk. Don’t leave licence reconciliation for post-migration.
Parallel run costs
During migration, organisations run both on-premises and Azure environments simultaneously. If this dual-running period becomes longer than planned, it means paying for both environments at once. Budget for it explicitly.
Storage sprawl
Without a clear tagging strategy and data lifecycle policies in place before cutover, environments collect duplicate and orphaned data fast. It starts small and compounds. The fix is straightforward, but it has to happen before migration, not after.
A practical way to structure your budget
Split it into three buckets:
- One-time migration costs cover tooling, outside expertise, and the period where both your on-premises and Azure environments are running at the same time
- Ongoing Azure run costs include compute, storage, networking, and licences once you're fully in the cloud
- Set aside an optimisation buffer of roughly 15–20% of your Year 1 run costs for adjustments in the first few months after migration
Check actuals against all three on a monthly basis for the first six months after cutover.
What is the role of Azure migration tools?
Microsoft provides purpose-built tools for planning and executing migration. Knowing what each tool does, and what it doesn't, helps you avoid overestimating how much the technology will handle on your behalf.
| Tool | What it does |
|---|---|
| Azure Migrate | The main hub for migration. Discovers your infrastructure, maps application dependencies, checks cloud readiness, and estimates costs. AI-powered agents added in 2025 can generate migration plans and recommend resource sizes. Note that it won't apply Hybrid Benefit licences, fix compatibility issues, or make judgment calls on complex workloads |
| Azure Database Migration Service | Handles database migrations for SQL Server, Oracle, MySQL, PostgreSQL, and MongoDB with minimal downtime. Run it in offline mode for a one-time move, or online mode if the database needs to stay live during cutover |
| Azure Data Box | A physical device Microsoft ships to you for large offline data transfers. You load your data, ship it back, and Microsoft uploads it to Azure. Best suited for datasets above 10 TB |
| Azure Site Recovery | A disaster recovery tool, not a migration tool. Azure Migrate has replaced it for migration purposes, but some teams still default to it out of habit. Worth clarifying with your team before you start |
What a successful migration looks like: Months 1 to 6 post-cutover?
Most migration guides treat cutovers as the finish line. However, this is not reality. The first 90 days after cutover are when migrations either deliver value or surface problems.
Set your success metrics before you migrate. Here's what to track:
- Cost vs. forecast: Compare actual Azure spend against your pre-migration projection, broken down by service and workload. A gap of more than 20% in Month 1 needs investigating
- Application performance: Track latency, throughput, and error rates against your pre-migration baseline. Azure Monitor and Application Insights handle this natively
- Incident frequency: Compare the number of serious incidents in the cloud against your last six months on-premises. A spike usually points to something that wasn't caught during testing
- Team capability: Track certifications completed and how many operational issues the team resolves without outside help. This tells you whether the skills gap is closing
- Reserved Instance coverage: Check what percentage of steady workloads are on Reserved Instances rather than on-demand pricing. Most organisations wait too long to commit and leave real savings on the table
- Optimising actions: Count how many rightsizing recommendations from Azure Advisor have actually been acted on. A long backlog of ignored recommendations is a sign that things are drifting
What are common Azure cloud migration risks?
Most migrations fail because of planning gaps that show up as technical problems during execution.
Dependency discovery gaps
Azure Migrate maps the dependencies it can observe on the network. It won't catch undocumented integrations, infrequent batch jobs, or connections running through older middleware. Always validate with the people who own each workload before finalising your wave plan.
Security shortcuts under time pressure
When teams are rushing to hit a deadline, security configuration often gets deprioritised. The result is a cloud environment that works but isn't properly secured. Azure is responsible for securing the infrastructure. Your organisation is responsible for how everything running on it is configured. Azure Security Center and Microsoft Defender for Cloud should be active from day one.
UK organisations should also confirm that workloads are hosted in Azure UK South or Azure UK West to satisfy UK GDPR data residency requirements and ICO accountability obligations. Additionally, those holding Cyber Essentials or Cyber Essentials Plus certification should note that misconfigured cloud environments post-migration can put that accreditation at risk. The NCSC's cloud security guidance is a useful reference alongside Microsoft's own security baseline.
Timeline misalignment with stakeholders
Migrations almost always take longer than the first estimate. The reason is dependency mapping, compliance approvals, and change management take time that often isn't accounted for in the original plan. Set realistic timelines upfront. A missed deadline does more damage to stakeholder trust than a longer one does.
How to evaluate an Azure cloud migration partner?
It is common practice for mid-market organisations to outsource Azure cloud migration. And evaluating the right partner should be part of the planning process.
Look for partners with a current Azure Solutions Partner designation, specifically in Infrastructure or Digital and App Innovation. The old gold and silver competency model was retired in 2022 and is no longer a reliable signal.
Ask these questions to separate capable partners from generalists:
- Can you walk me through a dependency mapping process you used on a similar migration, including what the automated tools missed?
- How do you handle licence reconciliation for Hybrid Benefit eligibility during the assessment phase?
- What does your wave planning process look like for an environment of our size?
- How do you transfer knowledge so our team can operate independently once the engagement ends?
Starting Azure cloud migration: What to do next?
Azure cloud migration should not be handled as a one-time project. Organisations that approach it with clear sequencing, a realistic budget, and defined success metrics get better results than those who focus only on moving workloads quickly.
Where you start depends on where you are right now:
- If you don't have a full picture of your current workloads, start with a discovery assessment using Azure Migrate
- If you have the inventory but no migration sequence, wave planning is the priority
- If migration is already underway, but costs are higher than expected, focus on Azure Cost Management and work through the Azure Advisor recommendations
Visionet's Microsoft-certified team has helped organisations across manufacturing, financial services, and retail plan and execute Azure migrations,from assessment to post-migration optimisation. If you're ready to get started or want a second opinion on your current approach, get in touch with the Visionet team.
Frequently asked questions – Azure cloud migration
What is the biggest mistake organisations make when planning an Azure cloud migration?
One of the biggest mistakes is poor sequencing. The order in which you migrate workloads determines how much risk you're carrying at any point, and whether your critical systems move under proven conditions or untested ones. Most organisations either migrate in the wrong order or skip wave planning entirely and then spend months fixing problems that proper sequencing would have avoided.
How long does an Azure cloud migration typically take?
It depends on the size and complexity of your environment, but most mid-market migrations take 6 to 18 months from assessment to full cutover. Dependency mapping, compliance sign-off, and getting stakeholder alignment on timelines are what extend most programmes. Building that time into your plan from the start is more effective than trying to recover a slipped schedule mid-migration.
We're already running Microsoft 365. Does that make Azure migration easier?
Yes, in a few impactful ways. Your user identities, group policies, and access controls can extend directly into Azure via Microsoft Entra ID, which removes one of the complex setup steps that organisations on other platforms must work through from scratch. You may also be eligible for Azure Hybrid Benefit if you have existing Windows Server or SQL Server licences under Software Assurance, which can significantly reduce your compute costs in Azure. Neither benefit is automatic, but both are worth auditing before you begin.
