Azure migration is one of the most impactful infrastructure decisions a mid-sized organisation can make — and one of the most reliably mismanaged. The technical capability is rarely the problem. Azure can host almost any workload. The problems are almost always in planning, sequencing, and the assumptions that go unchallenged until they cause a production incident.
After working through dozens of migration projects across Danish and European organisations, we have identified five mistakes that appear so consistently they might as well be industry norms. Each one is preventable. None of them require exotic technical skill to avoid — they require deliberate process.
Why Migration Failures Are So Costly
A Gartner report found that through 2025, more than 50% of enterprise cloud migrations will fail to meet their intended outcome due to poor planning and governance, not technical limitations. The cost of a failed or stalled migration is not just the remediation work — it is the opportunity cost of business objectives delayed, security debt accumulated during a “temporary” hybrid state, and staff burnout from extended crisis management.
Understanding the patterns that lead to failure is the first line of defence.
Mistake 1: Skipping the Discovery and Assessment Phase
The most expensive mistake in migration is also the most understandable: organisations want to start moving things, not spend three weeks in spreadsheets documenting what they have.
The result is predictable. A workload gets lifted to Azure and immediately fails in production because:
- It has a hard dependency on a legacy DNS configuration that wasn’t documented
- The application communicates with an on-premises SQL instance over a specific port that isn’t open in Azure
- The application expects a specific latency profile that doesn’t match the Azure region’s network topology relative to dependent services
What to do instead
Use the Azure Migrate service to perform automated discovery of your on-premises environment. Azure Migrate agents install on Hyper-V or VMware hosts and collect dependency maps, performance data, and application compatibility signals over a two-to-four week observation period.
The output gives you two critical things: an accurate inventory of what you have, and a dependency map that shows you what talks to what. Never plan a migration wave without the dependency map in hand. It will tell you which workloads must move together, which must move last, and which are simpler than you thought.
Mistake 2: Lift-and-Shift Without Rightsizing
“Lift and shift” — moving virtual machines to Azure without modification — is a legitimate migration strategy. It is fast, low-risk from an application perspective, and minimises the skillset required. The problem is that organisations frequently lift their on-premises VM specs directly into Azure without rightsizing.
On-premises VMs are typically over-provisioned. IT teams bought hardware for peak load three years ago and have been running it at 20-30% utilisation ever since. When you move that VM to Azure without rightsizing, you pay Azure compute prices for resources you don’t use.
A Standard D8s v5 VM (8 vCPU / 32 GB) in West Europe costs approximately 0.384 USD per hour, or roughly 280 USD per month running continuously. If the actual workload only needs 4 vCPU / 16 GB, a Standard D4s v5 at approximately 0.192 USD per hour (140 USD/month) would suffice. Over 20 VMs, that is a 3,360 USD per month unnecessary spend — more than 40,000 USD annually.
What to do instead
Run performance data collection for a minimum of 30 days (ideally 90 days, capturing end-of-month and quarter-end peaks) before sizing Azure VMs. Azure Migrate’s assessment feature uses this performance data to recommend right-sized Azure VM SKUs and calculates projected cost.
Apply Azure Reserved Instances for any VM that will run continuously — one-year reservations typically offer 30-40% savings compared to pay-as-you-go pricing. Three-year reservations save up to 60%.
Mistake 3: Treating Security as an Afterthought
Security is the most common area where migration projects accumulate debt. In the pressure to hit a cutover date, security configurations get deferred with the promise of “we’ll harden it after go-live.” After go-live, the team is focused on stabilisation. Two months later, the environment is in production and the security debt is now much harder to pay down.
The specific security gaps we see most often:
- No network segmentation — all Azure workloads sitting in a flat virtual network with broad inbound rules
- Storage accounts with public access enabled — a default that should be disabled at the subscription level from day one
- No Microsoft Defender for Cloud (previously called Azure Security Center) enabled — basic threat detection that comes free with every Azure subscription but is not enabled by default
- No resource tagging strategy — makes cost attribution and security ownership audits nearly impossible later
What to do instead
Before the first workload lands in Azure, establish your Azure Landing Zone. Microsoft’s Cloud Adoption Framework describes this in detail via the Landing Zone documentation, but the minimum viable version includes:
- A management group hierarchy and policy assignments
- Azure Defender for Cloud enabled at the subscription level
- A network architecture with hub-spoke topology or an equivalent segmentation model
- Storage account public access disabled via Azure Policy
- Diagnostic settings configured to send logs to a Log Analytics workspace
This setup takes one to three days. It prevents months of security remediation later.
Mistake 4: Ignoring Application Dependencies and Migration Sequencing
Even when a discovery phase is completed, migration waves are frequently sequenced based on team convenience rather than technical dependencies. The result: a workload goes to Azure, its dependent service is still on-premises, and latency or connectivity issues immediately surface.
A common example: a web front-end is migrated to Azure, but it calls an on-premises API on the company’s internal network. In the on-premises environment, that call took 2 milliseconds over the LAN. After migration, the call goes from Azure West Europe to an on-premises data centre over an ExpressRoute or VPN connection, adding 20-40ms of latency. An application that was never optimised for this level of latency begins timing out or performing poorly under load.
What to do instead
From the dependency map produced in the assessment phase, build migration waves that group tightly coupled workloads together:
- Identify clusters of workloads with high interdependency — these form wave candidates.
- Sequence waves so that dependencies move before the workloads that depend on them.
- For workloads with unavoidable on-premises dependencies during the transition, document the latency assumptions and test under load before go-live.
Use Azure Site Recovery for VM replication during migration — it gives you a controlled cutover with the ability to test the migrated workload while the original is still running, and to roll back if testing reveals issues.
Mistake 5: No Governance Model After the Migration
The migration completes. The workloads are in Azure. The project team disbands. And within six months, the cloud environment begins accruing governance debt: orphaned resources, unconstrained spending, unclear ownership, and a proliferation of manually deployed configurations that drift from their intended state.
This is the most underappreciated failure mode in cloud migration — not the migration itself, but the absence of a governance model to operate the environment after it is live.
Specific symptoms:
- Azure costs grow 15-20% per month without corresponding business growth
- Nobody can clearly explain what a given resource group contains or who owns it
- Security alerts in Defender for Cloud accumulate unread
- A developer deploys a resource manually and introduces a configuration that conflicts with network security policy
What to do instead
Before you close the migration project, establish the following:
1. A resource tagging standard — Every resource must have at minimum: Environment (prod/dev/test), Owner (team or individual), CostCenter, Application. Enforce this with Azure Policy in deny mode.
2. Azure Cost Management budgets — Set budget alerts at 80% and 100% of your projected monthly Azure spend. Assign budget owners.
3. A designated Azure platform owner — One person or team is responsible for the landing zone, policy, and cross-cutting concerns. Without clear ownership, governance erodes.
4. Infrastructure as Code (IaC) for all future changes — Use Bicep or Terraform for new resource deployments. This is the single most effective way to prevent configuration drift and ensure changes are reviewed before they are applied.
Azure Policy documentation and the Cloud Adoption Framework’s governance section are the practical starting points for a sustainable governance model.
What This Means for Your Business
Azure migrations that follow these five recommendations are not necessarily faster — the upfront assessment and governance work takes real time. But they are consistently cheaper and less stressful over the full project lifecycle.
The projects we see fail most expensively are the ones that skip the assessment, over-provision, skip security hardening, ignore dependencies, and have no plan for what happens after go-live. None of those are complex technical problems — they are process problems.
At inciro, we help organisations prepare for Azure migration with a structured approach: discovery and assessment using Azure Migrate, a landing zone built to Microsoft’s Cloud Adoption Framework standards, a sequenced migration plan with dependency-driven waves, and a governance model that the operations team can actually run.
We have seen what happens when each of these steps is skipped. We prefer not to repeat those experiences.
Book a strategic conversation — we will assess your on-premises or hybrid environment and give you a concrete migration roadmap, including realistic timelines and cost projections.