Moving from Active Directory to the cloud sounds straightforward on paper. You have your users in one place. You want them in another place. How hard can it be?
Pretty hard, it turns out.
The reality is that most organisations do not do a clean cutover. They end up in a hybrid state for months or even years. On-premises AD is still running. Cloud identity is being built out. Both are active at the same time. And somewhere in the middle, identity gets complicated.
This post walks through what actually makes this migration difficult and what teams can do about it.
What Hybrid AD Actually Looks Like in Practice
When people say hybrid AD, they usually mean a setup where on-premises Active Directory and a cloud identity provider like Azure AD (now called Microsoft Entra ID) are both in use and connected.
Users might authenticate on-prem for some things and use cloud credentials for others. Applications might trust one directory but not the other. Some resources have been migrated. Some have not.
Azure AD Connect is the most common tool used to synchronise identities between the two environments. It copies user accounts and attributes from on-prem AD into the cloud directory and keeps them in sync.
This works reasonably well for a while. But it also means you are maintaining two systems in parallel. Changes made in one have to flow through to the other. And not everything syncs cleanly.
The Identity Challenges That Come Up Most Often
Password Hash and Authentication Confusion
In a hybrid environment, how authentication actually works can get confusing fast.
With password hash synchronisation, a hash of the user’s password is synced to the cloud. Authentication can then happen in the cloud even if the on-prem environment is unavailable.
With pass-through authentication, the cloud passes the authentication request back to an on-prem agent to verify credentials. The password hash never leaves the building.
With federation, a separate federation service like ADFS handles authentication entirely.
Each approach has trade-offs. Teams often pick one without fully understanding how it behaves under different failure scenarios. And when something breaks, figuring out where in this chain the problem actually sits takes time.
Group Policy Does Not Translate
On-premises AD relies heavily on Group Policy Objects. GPOs control everything from password requirements to software deployments to desktop configurations.
Azure AD does not use GPOs. It uses a different mechanism called Intune policies for device management and Conditional Access policies for authentication rules.
This means everything your organisation has built up in Group Policy over the years does not simply migrate. It needs to be rebuilt in a different format using different tools. And some things that were easy to do with GPOs are either not possible in the cloud or require a completely different approach.
This is one of the more underestimated parts of the migration. Teams often focus on moving user accounts and then discover late in the process that all the configuration that went with those accounts also needs to be rebuilt from scratch.
Legacy Applications That Only Speak LDAP or Kerberos
A lot of older applications were built to authenticate against AD using LDAP or Kerberos. They were never designed with cloud identity in mind.
When you start migrating to cloud-based identity, these applications become a problem. Azure AD does not natively support LDAP or Kerberos in the same way that on-prem AD does.
There are workarounds. Azure AD Domain Services provides a managed domain service that does support these protocols. But it is not a direct replacement for on-prem AD and it has its own limitations.
For applications that cannot be updated or replaced, this can become a blocker. Many teams end up keeping a portion of their on-prem AD infrastructure alive specifically to support a handful of legacy applications, which extends the hybrid period further than originally planned.
Stale and Duplicate Identities Surface During Migration
When you start a proper migration, you get a clear look at the state of your identity data for the first time in years.
And it is often not pretty.
Accounts for former employees. Multiple accounts for the same person. Service accounts with no clear owner. Groups that have not been updated since the team they supported was reorganised.
All of this needs to be cleaned up before or during the migration. If you sync a messy AD to the cloud, you get a messy cloud directory. The migration does not fix bad identity hygiene. It just moves it to a different location.
Doing an identity audit before you start syncing is worth the time. Teams working with identity management tools that include discovery and reporting features often find this phase much more manageable than trying to audit everything manually.
Role and Permission Mapping Does Not Always Carry Over
On-prem AD has security groups. Cloud identity has roles, groups, and a whole different permissions model depending on what services you are using.
Migrating a security group from AD to Azure AD is technically straightforward. But whether that group still makes sense in the new environment is a different question.
The migration is a good opportunity to revisit what access each group actually grants and whether the membership is still appropriate. But that review takes time and requires someone to own it. A lot of teams skip it under migration pressure and end up recreating the same permission sprawl they had before, just in a different system.
What Helps Make the Migration Go Better
Plan the Authentication Method Early:
Before you start syncing identities, decide how authentication is going to work. Password hash sync, pass-through authentication, or federation. Each one has different implications for security, user experience, and what happens if something fails.
Do not leave this decision until late in the project. It affects how you configure the sync tool, what your users experience, and how you handle edge cases.
Clean Up On-Prem AD Before You Sync:
This bears repeating because teams consistently skip it and regret it.
Audit your AD before you start the migration. Disable accounts that are no longer active. Remove users from groups they should not be in. Document service accounts and what they are used for. Archive or delete groups that serve no current purpose.
The cleaner your source directory, the cleaner your cloud directory will be. And cleaning things up after the fact, once users are already synced and applications are already connected, is significantly harder.
Map Out Your Applications and Their Authentication Requirements:
Make a list of every application that uses AD for authentication. For each one, note what protocol it uses and whether it can be updated to use modern authentication methods like SAML or OpenID Connect.
Sort them into categories. Applications that can migrate easily. Applications that will need some work. Applications that are going to be a problem.
This map tells you where to focus your effort and it helps you set realistic timelines. If you have twenty legacy applications that rely on Kerberos, you need to factor that into your plan.
Use Conditional Access Early:
One of the real benefits of cloud identity is Conditional Access. It lets you set rules about when and how authentication is allowed. Require MFA when logging in from outside the corporate network. Block access from certain locations. Require a compliant device for sensitive applications.
A lot of teams set this up as an afterthought after the migration is mostly done. It is better to start building these policies early in the process, even if initially they are just in report-only mode.
Report-only mode lets you see what the policy would have blocked without actually enforcing it yet. This gives you confidence to turn policies on without worrying about accidentally locking people out.
Have a Clear Rollback Plan:
Migrations go wrong sometimes. A sync issue. An application that breaks unexpectedly. A configuration that does not behave as expected in production.
Before you flip any major switches, know how you would roll back. What would you do if the sync tool caused problems? What if a critical application stopped working after a change?
Having a rollback plan does not mean you expect to use it. It means that if you do need it, you are not making decisions in a panic.
The Hybrid Period Is Normal, Plan for It
A lot of organisations set out to complete their AD migration within a tight timeframe. Then the legacy application issues come up. Or the GPO rebuild takes longer than expected. Or a business freeze prevents changes during a critical quarter.
The hybrid period stretches out.
This is normal. Most organisations that have migrated successfully did not do it in a straight line. They moved in phases, hit obstacles, adjusted the plan, and kept going.
What matters is that the hybrid period is actively managed rather than just left to drift. That means keeping the sync healthy, monitoring for identity conflicts, and continuing to push applications over to cloud authentication rather than letting everything sit in a permanent half-migrated state.
Teams using cloud identity platforms that give visibility across both on-prem and cloud environments tend to manage this period better because they can see what is happening in both places without jumping between tools.
The Part Nobody Talks About Enough: Change Management
Technical problems in an AD migration are solvable. They take time and skill but there are known solutions.
The harder part is often the people side.
Users who have logged in the same way for ten years now have a different experience. IT staff who know on-prem AD deeply are now working with a system that behaves differently. Helpdesk teams need to handle a new category of authentication issues they have not seen before.
Communicating changes clearly before they happen matters a lot. Training for the teams managing the new environment matters. And having a good support channel for users who run into problems during the transition makes a real difference in how the migration is perceived.
Getting to the Other Side
An AD to cloud migration is a significant project. It touches nearly every user, nearly every application, and a lot of the infrastructure that holds day-to-day work together.
It is also genuinely worth doing. Cloud identity opens up better security controls, easier access management, and the ability to support users wherever they are working without depending on VPN or on-prem infrastructure.
The organisations that get through it cleanest are the ones that go in with realistic expectations. They know it will take longer than planned. They invest time in the cleanup work before they start. They plan for the hybrid period to last a while. And they treat identity as something worth managing carefully rather than just a technical checkbox to tick on the way to the cloud.
That mindset is what turns a difficult migration into one that actually sticks.
