Field notes · Published 10 July 2026 · Last updated 21 September 2026 · 12 min read
Hybrid Cloud Migration Strategy: A Practical Azure Migration Plan
A useful hybrid cloud migration strategy needs more than an Azure diagram: it needs a migration plan with owners, dependencies, pilot criteria, security controls, workload waves and operational validation. The sequence below is how I approach that work in practice—identity and dependencies first, controlled migration waves next, and verified operations before legacy systems are retired.
Hybrid Cloud Migration Plan: Eight Practical Steps
This eight-step hybrid cloud migration plan is the sequence I keep coming back to. Each phase has one objective, a short list of real activities, exit criteria you can actually verify, and the risk that most often derails it. If a phase cannot meet its exit criteria, the next phase does not start — that single rule prevents most migration disasters.
| Phase | Primary objective | Key activities | Exit criteria | Main risk |
|---|---|---|---|---|
| 1. Assessment and ownership | Know what you actually run, who owns it and what it depends on. | Workload and application inventory, identity and authentication dependency mapping, data classification, RTO/RPO capture, cost modelling per scenario. | A signed decision document per workload: migrate, refactor, keep on-prem or retire. | Treating a scan export as an assessment and missing the hidden dependencies. |
| 2. Identity preparation | Make Microsoft Entra ID the authoritative identity and policy plane. | AD clean-up (stale accounts, duplicate UPNs, proxyAddresses), Entra Connect or Cloud Sync design, MFA rollout, baseline Conditional Access, PIM for admin roles, break-glass accounts. | Legacy auth blocked, MFA enforced, admin roles eligible-only, sync errors at zero. | Syncing dirty AD data and inheriting every on-prem trust assumption in the cloud. |
| 3. Dependency and landing-zone design | Map dependencies and build a governed place for workloads to land. | Subscription and management-group structure, naming and tagging, RBAC model, hub-and-spoke network, NSGs/Azure Firewall, ExpressRoute or VPN to on-prem, logging into a central workspace. | Policy-as-code applied, connectivity tested both directions, cost alerts live. | Ad-hoc subscriptions created by project teams that nobody can govern later. |
| 4. Pilot and rollback validation | Prove the design with representative users, devices and workloads. | Select a small cross-functional pilot, test authentication and application paths, rehearse rollback, capture support issues and revise runbooks. | The pilot meets agreed success criteria and the rollback path has been tested. | Treating a technically successful pilot as representative when it excludes real edge cases. |
| 5. Endpoint and data preparation | Prepare devices and data before moving production workloads. | Autopilot for new devices, co-management of existing SCCM fleets, compliance policies, configuration profiles replacing GPO, app packaging, BYOD app-protection policies. | Device compliance signal trusted by Conditional Access for the whole in-scope fleet. | A device fleet that reports 'enrolled' but is not actually enforcing anything. |
| 6. Security and governance | Apply access, logging, data and cost controls before broader migration. | Validate Conditional Access, RBAC, device compliance, data classification, retention, central logging, tagging, budgets and named operational owners. | Security, governance and monitoring controls are tested against the pilot estate. | Planning to add governance after migration, when exceptions and unmanaged resources already exist. |
| 7. Migration waves | Move data and workloads in business-risk order, not vendor order. | Exchange Online first, then OneDrive with Known Folder Move, then SharePoint and Teams; server workloads to Azure IaaS or PaaS per the assessment decision; pilot, wave, cutover. | Each wave verified against its own rollback criteria before the next wave starts. | A big-bang cutover with no tested rollback and no per-wave success criteria. |
| 8. Validation and operations | Verify the new service, stabilize operations and retire approved legacy systems. | Right-sizing and reservations, review of Conditional Access and RBAC, retiring file servers, print servers and legacy protocols, planning the Active Directory sunset as its own project. | Every retired system formally decommissioned, documented and removed from backup scope. | Running both estates indefinitely — double cost, double attack surface. |
Scroll the table sideways on a small screen to see every column.
Why hybrid, not all-in
Pure-cloud looks great in a slide deck. In the field, most enterprises have a line-of-business app the vendor will not certify on Azure, a factory-floor system that must stay local, or a compliance regime that pins data to a specific country. Hybrid is not a stepping stone — it is the honest target state for the next three-to-five years.
The mistake is treating hybrid as "some servers here, some there." Real hybrid means one identity plane, one policy plane, one endpoint management plane — spanning both locations. Get those three planes right and the workloads become swappable.
Azure infrastructure assessment — before you commit
Every migration I have rescued had one thing in common: nobody did a real assessment. Someone ran the Azure Migrate scan, exported a spreadsheet, and treated it as gospel. An assessment is not a scan output — it is a decision document.
- Inventory every workload with its licensing, dependencies, RTO/RPO, and data residency requirement — not just its CPU and RAM
- Map identity dependencies: which apps still Kerberos-auth, which use LDAP, which have their own local user store
- Classify data by sensitivity before you plan storage — GDPR, HIPAA and internal IP tiers each have different Azure landing zones
- Cost model at least three scenarios: lift-and-shift, refactor to PaaS, retire. The cheapest option on paper is often the most expensive to operate
- Score every workload on business criticality and migration complexity — those two axes decide sequence, not the vendor's preferred order
Do not trust vendor documentation from 2019 as a design input. Half of it references Azure AD Connect settings that no longer exist and Intune UX that has been rewritten twice. Verify every non-trivial config in the current portal before you write it into your run book.
Identity first — Microsoft Entra ID migration
Identity is the whole game. If Entra ID is not solid, every workload you move inherits a broken trust boundary. This is the phase to over-invest in.
- Deploy Entra Connect Sync (or Cloud Sync for greenfield-ish estates) with password hash sync — even if you plan on federation, you want the fallback
- Clean up on-prem AD before you sync: stale accounts, duplicate UPNs, mismatched proxyAddresses. Bad data replicates faster than it can be fixed in the cloud
- Roll out MFA to admins first, then privileged users, then the whole tenant — never all at once
- Baseline Conditional Access: block legacy auth, require MFA for all users, require compliant device for admin portals
- Enable Privileged Identity Management for every eligible admin role — standing admin access is the single biggest blast-radius risk
Related reading: Microsoft Entra ID for small and medium businesses — the same principles, sized for a smaller estate. If you want this designed and run with you, Microsoft Entra ID consulting is one of the things I do day to day.
Moving from Hybrid Azure AD to Cloud-Only Entra ID
This is the part of a hybrid cloud migration strategy that people underestimate the most. Going from hybrid Azure AD (now Microsoft Entra ID) to cloud-only is not a setting you flip — it is a migration in its own right, with its own inventory, its own pilot waves and its own rollback plan. I treat it as a separate project that starts only once endpoints and workloads are already healthy.
1. Inventory every remaining on-prem identity dependency
Before touching synchronization, write down everything that still authenticates or authorizes against Active Directory. In practice the list is longer than anyone expects:
- Kerberos: file shares, print servers, SQL with Windows authentication, internal web apps using integrated authentication
- LDAP and LDAPS binds: firewalls, backup software, scanners, HR and ERP connectors, monitoring tools
- Group Policy: drive mappings, security baselines, certificate deployment, browser and application settings
- RADIUS / NPS: Wi-Fi and VPN authentication, network access control, often tied to AD security groups
- Legacy applications with hard-coded domain names, service accounts or on-prem group membership checks
- Certificate services: anything issued by an internal PKI that expects a domain-joined machine
Each item gets an owner and a decision: replace with a cloud-native equivalent, keep it on a small remaining AD footprint, or retire it. Anything without a decision blocks the cutover — that is the honest way to size the project.
2. Clean identities before you change synchronization
Duplicate UPNs, stale accounts, orphaned service accounts, mismatched proxyAddresses and groups nobody owns all become permanent cloud objects the moment they are converted. Clean them while AD is still authoritative: it is far easier to fix a directory you still fully control than to untangle cloud-mastered objects afterwards. Reconcile licensing and group-based assignment at the same time, so nobody loses access on cutover day for a reason unrelated to identity.
3. Plan Entra-joined devices and Intune management
Hybrid-joined devices still need line of sight to a domain controller. Cloud-only means devices are Entra joined and managed entirely by Intune. New hardware is the easy path — Autopilot handles it. Existing machines need a decision per fleet: reprovision via Autopilot, or use Windows Autopilot device preparation / reset flows. Plan for what users actually notice: profile and data migration, re-authentication to line-of-business apps, printer access and any locally cached credential habits. My Intune migration lessons from 500 users cover the practical side of that wave planning.
4. Replace GPO with Intune policy — deliberately, not by translation
Do not try to map every GPO one-to-one. Export the resultant set of policy, sort it into what is still required, what was required in 2014, and what is now handled natively. Rebuild the required settings as Intune configuration profiles, settings catalog policies, security baselines and compliance policies. Drive mappings and scripts usually turn into SharePoint/OneDrive plus Known Folder Move; certificate deployment turns into SCEP or PKCS profiles. Run both in parallel on a pilot group first, then remove the GPO scope — never remove it before the Intune equivalent is proven on real devices.
5. Test authentication, Conditional Access and emergency access
Test the flows that break quietly: sign-in from an unmanaged device, sign-in from a newly Entra-joined device, legacy application authentication, guest access, service accounts, and password reset without an on-prem writeback path. Confirm that Conditional Access still evaluates the device state you expect after the join type changes — a policy that required a hybrid-joined device will not behave the same way once devices are Entra joined. And verify your break-glass accounts work, are excluded from the policies that could lock you out, and are monitored. My practical Conditional Access guide covers the policy set I use as a baseline.
6. Validate every dependency before disabling synchronization
Before sync is disabled, walk the inventory from step one and confirm each item is either migrated or explicitly accepted as remaining on-prem. Check application sign-in logs for anything still hitting federated or synced paths, confirm no automation is creating users in AD, and make sure device compliance is green across the fleet. The cutover itself should be the least eventful part of the project.
Never simply switch off Entra Connect or Cloud Sync. Disabling synchronization converts synced objects to cloud-mastered ones, and turning sync back on does not cleanly undo that — you can end up with duplicated or mismatched objects and users unable to sign in. Treat it as a controlled, scheduled change: full directory backup, documented object counts before and after, a pilot group first, a defined rollback plan, and support staffed for the days after — not just the cutover window.
Modern endpoint management with Intune
Once identity is trustworthy, endpoints become the next enforcement point. Intune (Microsoft Intune / Endpoint Manager) replaces GPO as the primary policy plane — treat GPO as legacy from day one.
Autopilot for new devices
Every new laptop ships with Autopilot, no imaging server. The user unboxes, signs in with their Entra ID, and Intune builds the device.
Compliance policies drive Conditional Access
'Compliant device' is only meaningful if Intune actually enforces the rules — disk encryption, minimum OS, EDR present. Never trust just the enrollment flag.
Co-management, not full ripping
Existing SCCM/ConfigMgr fleets co-manage into Intune workload by workload. Compliance and Conditional Access move first; app deployment last.
BYOD via App Protection Policies
Personal phones and tablets get MAM without enrollment — the corporate data is protected inside Outlook and Teams, the device stays personal.
Field notes from the last big rollout: migrating 500 users to Intune — lessons learned.
Microsoft 365 migration strategy — workloads in the right order
With identity and endpoints locked in, workloads become almost boring — which is exactly what you want. The order matters more than any individual cutover technique.
- Exchange Online first — a mailbox migration exposes every identity, licensing and Conditional Access problem you missed. Better to find them here than during SharePoint cutover
- OneDrive for Business as the file-share replacement — enable Known Folder Move so Desktop, Documents and Pictures roam automatically
- SharePoint and Teams last — SharePoint migrations are the longest, and Teams sits on top of both Exchange (calendaring) and SharePoint (files)
- Retire on-prem Exchange when the last shared mailbox and calendar delegation is verified — not before, and keep one hybrid server for management until you fully cut sync
- Kill legacy protocols the moment you can: POP, IMAP, basic auth for SMTP AUTH. Every day they stay on is a day of brute-force attempts
Zero Trust architecture — the connective tissue
Hybrid networks quietly break every assumption of the old "inside the firewall equals trusted" model. Zero Trust is not a product — it is the operating principle that keeps hybrid safe: every request verified, no implicit trust from location.
- Verify explicitly: user identity, device compliance, location, session risk — evaluated on every access request
- Least-privilege access: PIM for admin roles, just-in-time elevation, no standing production access for engineers
- Assume breach: segment east-west traffic in Azure with NSGs and Azure Firewall, log everything to Sentinel, alert on the deltas
- Protect data at the object level: sensitivity labels in Purview travel with the file into email, chat and external shares
- Retire the VPN mindset: Entra Private Access and Global Secure Access replace the always-on tunnel with per-app, identity-aware access
Zero Trust cannot be bolted on after migration. Every workload you move should ship with its Conditional Access, its logging and its network segmentation from day one. Retrofitting these later is where most "we'll harden it in phase two" projects die.
FAQ
What is a hybrid cloud migration strategy?
A hybrid cloud migration strategy is a phased plan for running workloads across on-premises infrastructure and Azure at the same time, under one identity plane, one policy plane and one endpoint management plane. It defines what moves, in what order, what stays local and why, and the exit criteria for each phase — rather than treating the cloud as a single cutover event.
How do you move from hybrid Azure AD to cloud-only Entra ID?
Inventory everything that still depends on Active Directory — Kerberos, LDAP, GPO, RADIUS, file and print services and legacy apps — then clean up identities, move devices to Entra join with Intune management, replace GPO with Intune policies, and test authentication, Conditional Access and break-glass access. Only after every dependency is verified do you disable Entra Connect or Cloud Sync, and only with a rollback plan in place.
What should be migrated first in a hybrid cloud project?
Identity. Entra ID, MFA, Conditional Access and privileged access come before any workload. Endpoints via Intune come second, then workloads in risk order — Exchange Online, OneDrive, SharePoint and Teams. Servers and line-of-business applications move last, according to the decision made for each in the assessment.
Should I migrate everything to Azure at once?
No. A big-bang migration is where most projects fail. Start with identity, then endpoints, then workloads in order of business risk. Hybrid is not a fallback — it is the target state for most enterprises for years.
What is the biggest mistake in a hybrid cloud migration?
Treating it as a network project. It is an identity project. If Entra ID, Conditional Access and Intune are not in the right shape before you move workloads, you inherit every on-prem trust assumption into the cloud.
How long does a real Microsoft 365 migration take?
For 200–1000 users: 4 to 9 months if identity and endpoints are already modern. 12 to 18 months if you are also detangling legacy AD, file shares and mixed device ownership at the same time.
Do I still need on-premises Active Directory after migration?
Usually yes for a few years. Line-of-business apps, printers and RADIUS still lean on it. Plan the AD sunset as its own project once the last dependency is retired, not as day-one scope.
How does Zero Trust fit into a hybrid model?
Zero Trust is what makes hybrid safe. Every access request — cloud or on-prem — is verified against user, device, location and risk signals. It replaces the old 'inside the firewall = trusted' model that hybrid networks quietly break.
Key takeaways
- Do the assessment as a decision document, not a spreadsheet export.
- Identity first — Entra ID, MFA, Conditional Access and PIM before any workload moves.
- Endpoints via Intune and Autopilot; treat GPO as legacy.
- Workloads in order: Exchange, OneDrive, SharePoint, Teams — never all at once.
- Zero Trust is the operating model that makes hybrid safe. Bake it in per workload, not as a phase-two afterthought.
Related reading: more on Entra ID and Intune specialties, Microsoft cloud specialist work in Copenhagen, past enterprise migration projects, more deep dives into Microsoft 365 and Azure, and consultation on cloud readiness assessments.
Planning a hybrid cloud migration or an Azure landing-zone build? This is what I do in production.
Let's talk →Planning a Microsoft 365 or hybrid cloud move?
I work with businesses in Copenhagen, across Denmark and the Øresund region on Microsoft 365, Intune, Entra ID and day-to-day IT support.