Mistakes in Azure & Fabric Cloud Migration

The failure patterns in cloud migration are consistent across industries. These are not failures of ambition or budget — they are failures of architecture, sequencing, and engineering discipline. The five mistakes documented here account for the overwhelming majority of migration cost overruns, timeline slippage, and post-migration performance degradation. Each section covers root causes, detection signals, and the technical remediation pattern that resolves them.

Mistake 1: Skipping or Shortcutting the Discovery Phase

The most destructive mistake in any cloud migration program is initiating workload movement before the application portfolio is fully understood. Discovery is not an administrative checkbox — it is the engineering input that determines every subsequent architectural decision: network topology, identity integration model, data sovereignty zoning, licensing model selection, and migration wave sequencing. Organizations that skip it discover their architectural constraints mid-migration, when the cost of correction is an order of magnitude higher than upfront investment.

What a complete discovery actually requires. A production-grade discovery engagement for an organization with 50–500 servers requires four workstreams running in parallel over 2–4 weeks:

• Application inventory and dependency mapping — Deploy Azure Migrate: Discovery and Assessment agents on all on-premises servers. The agent captures installed software, running processes, network connection telemetry (TCP connections with source/destination IP and port), and performance counters (CPU, memory, disk IOPS, network throughput) over a minimum 30-day observation window. A 30-day window captures monthly batch jobs, month-end reporting cycles, and backup windows that a 7-day window misses. Output: dependency visualization grouped by communication pattern, which defines migration wave groupings. Applications with tight inter-dependencies must migrate in the same wave — cross-environment latency will break them otherwise.
• Database inventory and schema analysis — For SQL Server workloads, run the Data Migration Assistant (DMA) against every database instance. DMA outputs a compatibility assessment identifying features used that are unsupported in Azure SQL Database or Azure SQL Managed Instance (linked servers, cross-database queries, CLR assemblies, SQL Agent jobs, Service Broker). This determines the target SKU: Azure SQL DB (PaaS, lowest overhead), Azure SQL MI (near-full SQL Server compatibility), or SQL Server on Azure VM (full compatibility, highest management burden). Run the SKU Recommendation tool against the 30-day performance baseline to right-size the target compute and storage tier — avoid migrating peak-spec on-premises hardware to equivalent Azure VM SKUs without rightsizing.
• Compliance and data residency mapping — Classify every data store by regulatory regime: HIPAA PHI, PCI DSS CHD, GDPR personal data, SOC 2 in-scope systems. Map classification to Azure region constraints (data must remain in specific geography), encryption requirements (customer-managed keys via Azure Key Vault for regulated data), audit logging requirements (Diagnostic Settings → Log Analytics, minimum 90-day hot retention for PCI, 1-year for HIPAA), and network isolation requirements (Private Endpoints mandatory for regulated data stores).
• Identity and authentication audit — Document every authentication mechanism in use: Kerberos (on-premises AD), NTLM (legacy applications), SAML (federated SaaS), Basic Auth (legacy APIs), certificate-based auth (device or service authentication). Applications using Kerberos require either Entra Kerberos (for hybrid scenarios), Entra Domain Services (managed AD DS in Azure), or full Entra ID modernization via MSAL/OAuth 2.0. Identify these constraints in discovery — not after a VM is running in Azure and users cannot authenticate.

Microsoft Fabric-specific discovery. For organizations migrating data platforms to Microsoft Fabric, discovery must additionally cover: existing Power BI Premium capacity utilization and report inventory (use the Power BI Activity Log API to identify reports accessed in the last 90 days — delete or archive the rest before migration), SSIS package inventory and complexity assessment (Azure Data Factory pipeline equivalents require rewrite for complex SSIS control flow), on-premises SQL Server Integration Services catalog (SSISDB) dependencies, and existing Azure Data Factory pipeline inventory if migrating to Fabric pipelines.

Mistake 2: Lift-and-Shift as Default Strategy

Lift-and-shift — rehosting on-premises VMs as Azure IaaS VMs without modification — is architecturally valid for a narrow set of workloads: applications with complex installers that cannot be containerized within the project timeline, applications with strict vendor support requirements tied to specific OS versions, and applications scheduled for decommission within 18 months where modernization ROI is negative. For everything else, lift-and-shift recreates on-premises technical debt in a more expensive operating environment.

The cost arithmetic. A 16-core, 64GB RAM on-premises server running at 8% average CPU and 22% average memory utilization — typical for many application servers — costs roughly $8,000–12,000 to purchase and $2,000–4,000 per year in power, cooling, and maintenance. The equivalent Azure VM (Standard_D16s_v5) runs approximately $560/month ($6,720/year) at on-demand pricing. Rightsized to actual consumption (Standard_D4s_v5 + autoscale), the same workload runs at $140/month ($1,680/year) — a 75% cost reduction. Lift-and-shift without rightsizing delivers the $6,720 bill, not the $1,680 bill, while eliminating the hardware capex savings that justified the migration business case.

Migration strategy decision framework. Apply the 6 Rs taxonomy to every workload identified in discovery:

Microsoft Fabric migration strategy. For data platform migrations, the equivalent decision is: Power BI Embedded → Fabric capacity (replatform), on-premises SSAS tabular → Fabric semantic models (replatform), SSIS → Fabric Data Pipelines or Azure Data Factory (refactor — pipeline logic must be rewritten), on-premises SQL Server data warehouse → Fabric Warehouse or Lakehouse (re-architect — schema and ETL patterns change significantly for columnar/Delta storage). Fabric’s OneLake storage layer consolidates all data assets into a single logical lake — plan the namespace structure (workspace → lakehouse → folder hierarchy) during discovery, not during migration.

Mistake 3: Treating Networking as an Afterthought

Azure networking architecture is the most technically complex workstream in any enterprise migration and the area most consistently deferred until workloads are already being moved. Retrofitting network design after workload migration is not an inconvenience — it causes production downtime, requires redeployment of resources into correctly-configured subnets, and invalidates DNS configurations that application connection strings depend on.

Hub-and-spoke topology design. Enterprise Azure environments require a hub-and-spoke virtual network topology. The hub VNet contains shared networking services: Azure Firewall (or third-party NVA), Azure VPN Gateway or ExpressRoute Gateway, Azure Bastion (RDP/SSH over TLS — eliminates public IP exposure of management ports), Azure Private DNS Resolver, and Azure Monitor network diagnostics. Spoke VNets contain workload subnets and peer to the hub — spoke-to-spoke traffic routes through the hub firewall for east-west inspection. Design hub-and-spoke topology, address space allocation (use RFC 1918 space that does not overlap with on-premises ranges — overlapping address spaces break VNet peering and ExpressRoute routing), and subnet sizing (allocate minimum /26 per subnet to accommodate Azure-reserved addresses plus future scaling) before any workload deployment.

DNS resolution architecture. On-premises environments use Active Directory-integrated DNS. Azure environments use Azure-provided DNS (168.63.129.16) by default, which resolves Azure public FQDNs and Private DNS zones but has no knowledge of on-premises hostnames. Applications that reference on-premises resources by hostname (not IP) will fail name resolution after migration unless DNS forwarding is configured. The correct architecture:

Mistake 4: No Cost Governance Architecture

Azure’s consumption-based billing model is its greatest operational advantage and its most dangerous trap for organizations without cloud financial management discipline. On-premises infrastructure has fixed costs that accrete slowly — hardware refresh cycles measured in years. Azure costs accrete continuously, by the second, and a single misconfigured resource can generate thousands of dollars in unexpected charges before the next billing cycle. Organizations that treat cost governance as a post-migration concern — “we’ll set up budgets after we’re stable” — consistently overspend by 2–4x in the first six months.

The governance architecture. Cost governance is not a dashboard — it is an architectural pattern implemented at resource provisioning time:

• Management Group hierarchy and policy inheritance — Structure Azure management groups in a hierarchy that reflects your organizational and environment model: Tenant Root → Platform (connectivity, identity, management) → Landing Zones (corp, online) → Sandboxes. Apply Azure Policy at the Management Group level to enforce: required tags (CostCenter, Environment, Owner, Project), allowed VM SKU lists per environment (prevent accidental D64s_v5 provisioning in dev), allowed regions (data sovereignty), and mandatory diagnostic settings routing to centralized Log Analytics workspace.
• Tagging enforcement via Azure Policy (Deny effect) — Assign the built-in “Require a tag and its value on resources” policy with Deny effect at the subscription level for mandatory cost attribution tags. Deny-effect policies block resource creation rather than flagging non-compliance after the fact. Use the “Inherit a tag from the resource group if missing” policy to propagate resource group tags to child resources automatically.
• Azure Cost Management budgets with action groups — Create budgets at three scopes: subscription (overall spend), resource group (per workload or team), and resource (individual high-cost resources like Azure OpenAI or GPU VMs). Configure alert thresholds at 50%, 75%, 90%, and 100% of budget. At 90%, trigger an Azure Action Group that emails the resource owner and posts to a Teams channel. At 100%, consider triggering an Azure Automation runbook that deallocates non-production VMs automatically during off-hours.
• Reserved Instances and Savings Plans — After 30–60 days of production operation, analyze Azure Advisor cost recommendations for Reserved Instance (RI) candidates. VMs with consistent utilization (>70% hours/month) are RI candidates. 1-year RIs deliver 30–40% savings over on-demand; 3-year RIs deliver 50–60%. Purchase RIs at the shared scope (applies across all subscriptions in the billing account) for maximum flexibility. Azure Savings Plans cover compute spend across VM families and regions with 15–37% savings — complementary to RIs for variable workloads.
• Dev/test licensing — Azure Dev/Test subscriptions provide significantly discounted pricing (up to 55% on Windows VMs) for non-production environments. Visual Studio subscribers qualify. Ensure non-production environments are provisioned under Dev/Test offer — not pay-as-you-go. This single configuration change can reduce non-production VM costs by half.

Microsoft Fabric cost governance. Fabric uses a capacity-based billing model (F SKUs: F2 through F2048, priced per CU-hour) rather than per-resource consumption. Key governance controls: enable capacity auto-pause on development capacities (pauses after 2 hours of inactivity, eliminating idle costs); set per-workspace storage quotas; monitor CU consumption via the Microsoft Fabric Capacity Metrics app — identify which workspaces and operations are consuming the most capacity units; use Fabric Trial capacities for POC and development workloads before committing to paid F SKUs.

Mistake 5: Neglecting Network Segmentation and the Blast Radius Problem

The fifth mistake is architectural, not operational: migrating workloads into a flat Azure network with no segmentation between environments, tiers, or workload classifications. A flat network is the cloud equivalent of leaving the office door unlocked — any compromised workload has network-layer access to every other workload in the environment. This dramatically amplifies the blast radius of any security incident and is trivial to remediate before migration and extremely difficult to remediate after workloads are running.

Subnet segmentation design. Every VNet must implement subnet-level segmentation aligned to workload tier and sensitivity classification. Minimum subnet structure for a workload VNet:

Application Security Groups (ASGs) extend NSG segmentation to the workload level without IP address management overhead. Define ASGs for logical groups (asg-web-servers, asg-app-servers, asg-sql-servers) and reference ASGs in NSG rules rather than IP ranges. When VMs are added or removed from a workload, assign them to the appropriate ASG — NSG rules require no modification. This is especially valuable in autoscaling scenarios where VM IPs are ephemeral.

Just-in-time (JIT) VM access. Enable Microsoft Defender for Cloud JIT VM access on all VMs. JIT closes management ports (3389, 22, 5986) at the NSG level by default and opens them on-demand for approved IP addresses for a defined time window (maximum 3 hours, recommend 1 hour). This eliminates the attack surface of permanently open RDP/SSH ports — the leading vector for brute-force and credential stuffing attacks against Azure VMs. JIT requests are logged in the Defender for Cloud audit trail and can trigger Sentinel alerts for after-hours or unusual-IP access patterns.

Azure Defender for Cloud Secure Score. Use the Microsoft Defender for Cloud Secure Score as a continuous governance metric for your landing zone security posture. Target a minimum score of 75% before declaring migration complete. The Recommendations view prioritizes controls by impact on score — remediate high-impact, low-effort findings first. Enable Defender for Cloud enhanced security plans on all production subscriptions: Defender for Servers (MDE integration + JIT + adaptive application controls), Defender for SQL (SQL vulnerability assessment + threat detection), Defender for Storage (malware scanning + sensitive data discovery), and Defender for Key Vault (anomalous access pattern detection).

The common thread across all five mistakes is sequencing: each error stems from deferring an architectural decision that should have been made before migration began. Cloud migrations do not fail because of inadequate technology — Azure and Microsoft Fabric are mature, capable platforms. They fail because the engineering work required before migration is underestimated, underfunded, or skipped in favor of moving faster toward a go-live date that ultimately slips anyway. Invest 4–6 weeks in architecture and discovery; save 4–6 months of post-migration remediation.