Enterprise Azure Migration Strategy: How to Move Legacy Systems to Microsoft Cloud Without Breaking Compliance, Governance, or the Business

(00:00:00) The Cloud Migration Fallacy (00:00:06) The IT Project Mindset Trap (00:00:36) Legacy Beyond Hardware (00:01:12) The Amplification of Chaos (00:01:45) Measuring Migration Success (00:02:55) The Pitfalls of Lift and Shift (00:03:15) The Governance Blind Spot (00:04:58) The Cutover Illusion (00:07:39) Defining Azure Correctly (00:10:59) The Landing Zone Misconception Most enterprises still talk about “moving to Azure” as if it were a datacenter project. Turn off old servers, turn on new services, hit the cutover date, don’t break production, and declare victory. But at scale, migrations are not infrastructure exercises. They are operating model changes that rewire how identity, access, policy, evidence, and change itself work inside your organization — and when those dimensions are treated as afterthoughts, Azure migrations create more entropy than they remove.In this episode of M365.FM, Mirko Peters examines why large Azure migrations in regulated and complex environments so often underdeliver: workloads move, costs rise, complexity increases, and nobody can explain why the new world feels harder to run than the old one. This is not a conversation about choosing the perfect VM size or checking boxes on a readiness checklist. It is a conversation about turning migration from a one-time “move everything and hope” project into a repeatable onboarding pattern built on platform-first design: landing zones, Microsoft Entra ID, network and segmentation strategy, policy, logging, and evidence by default.The organizations that will actually win with Microsoft cloud are not the ones that finish “the move” the fastest. They are the ones that treat Azure as a control plane, not a hosting location, and that design their migration so financial, security, and compliance intent are encoded into the platform before the first production workload lands. That means identity designed around least privilege and role clarity, network boundaries that reflect real blast radii, policies that deny what the organization is not ready to own, and landing zones that make the right thing the default thing for every project that follows.WHAT YOU WILL LEARN- Why most Azure migrations fail at the operating model level, not the technical level — and how that shows up in day-2 operations.- How to recognize migration “entropy signals”: identity drift, exception sprawl, policy bypasses, and one-off architectures that cannot be standardized.- What a platform-first migration strategy looks like: building Azure landing zones, Entra ID patterns, and policy baselines before scaling workload movement.- How to design management groups, subscriptions, and landing zones so that compliance, cost, and security boundaries are built into the hierarchy, not bolted on later.- Why treating Azure as “someone else’s datacenter” is the fastest way to recreate all of your on-premise problems with additional complexity and higher cost.- How to approach legacy systems that cannot simply be “lifted and shifted,” and what it means to migrate their operating model, not just their compute.- How to design evidence, logging, and audit trails into the migration so you can prove control to regulators, internal audit, and your own leadership.THE CORE INSIGHTEvery migration decision is an operating model decision in disguise. When you choose where an application lands in Azure, you are choosing its blast radius, its identity surface, its policy coverage, its cost behavior, and its compliance story. When you allow “temporary” exceptions for that application — bypassing policy, relaxing network rules, skipping tags “just this once” — you are deciding how much entropy you are willing to inject into your future platform. None of those decisions show up in a Gantt chart. They all show up in how hard Azure is to run three years later.Mirko argues that this is why so many migrations feel done on paper but never stabilize in reality. The project ends when the workloads are running in Azure, but the operating model needed to run them safely, repeatedly, and economically has not been built. Identity is still a patchwork of old groups and new roles. Policy is a mixture of global standards and local exceptions. Monitoring is noisy but untrusted. No one owns the platform as a product; everyone owns “their” application. The result is a cloud estate that is technically migrated but strategically unfinished.LATFORM FIRST: LANDING ZONES BEFORE LIFT-AND-SHIFTA platform-first migration in Azure starts with constraints, not capacity. Before you move the first critical workload, you define how environments will look and behave: which landing zones exist, which subscriptions they map to, what policies are mandatory, and how identities and networks are structured. You decide which freedoms you will grant to application teams — and which freedoms must never exist because they cannot be governed at scale.Landing zones are not slideware. They are opinionated, enforced starting points that encode your risk appetite, compliance obligations, and operating model directly into Azure. A good landing zone tells you where a workload belongs, what it can do, how it is observed, and who is accountable when something goes wrong. A weak landing zone lets every project improvise its own architecture, governance, and evidence model — and then wonders why nothing looks the same after two years of migration.DENTITY, ACCESS, AND NETWORK: THE HIDDEN SOURCE OF MIGRATION ENTROPYMost migration pain is not caused by virtual machines, databases, or storage accounts. It is caused by identity and network decisions made under time pressure and never revisited. “Temporary” direct permissions become permanent. Legacy service accounts come along for the ride because nobody knows what they break. Flat networks replicate old trust zones in a new cloud, making segmentation and Zero Trust an afterthought.Mirko breaks down how to design Entra ID, RBAC, and network segmentation so that migration reduces identity debt instead of importing it. That includes using role-based access instead of ad-hoc assignments, minimizing exceptions, aligning network boundaries with real business and risk domains, and ensuring that every connectivity decision (VPN, ExpressRoute, private endpoints) aligns with a clear, documented model of how traffic is supposed to flow. This is not about perfection. It is about choosing defaults that make future change easier, not harder.EVIDENCE, COMPLIANCE, AND “PROVABLE CONTROL”In regulated environments, a migration is only finished when you can prove that control exists — not just that workloads are up. That means auditors and regulators can see how policies are enforced, how exceptions are governed, how access is reviewed, and how incidents can be reconstructed from logs. If your migration creates a world that runs but cannot be explained, you have traded one kind of risk for another.This episode explores what it means to build an evidence model into Azure from day one. That includes logging that is centrally collected and tied to identities and policies, change tracking that shows who altered what and when, and governance processes that can be demonstrated, not just described. The payoff is not just audit readiness. It is the ability to change the platform with confidence because you can see and prove how it behaves.WHO THIS EPISODE IS FOR- CIOs, CTOs, and transformation leaders planning or rescuing large Azure migrations- Cloud platform and Azure architects responsible for landing zones, Entra ID, and governance- Enterprise and solution architects who need to bridge legacy application realities with Microsoft cloud architectures- Compliance, risk, and security leaders who must ensure that migrations strengthen, not weaken, provable controlBecome a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.