How to Migrate From Active Directory to the Cloud — Step-by-Step
On-premise Active Directory was built for a world where every device sat inside one office network — it doesn't naturally extend to a distributed workforce on Mac, Windows and Linux, spread across a hybrid-work Indian company with employees connecting from home broadband and mobile hotspots. Migrating to a cloud directory removes that mismatch, but rushing the cutover breaks logins for everyone at once. Here is the phased approach that avoids that.
Steps
Step 1 — Inventory what actually depends on AD today: List every system authenticating against AD: file shares using NTFS permissions, legacy LDAP-bound applications, Wi-Fi 802.1X authentication, VPN, and any application with AD-integrated single sign-on. This list determines your real migration complexity — a company with only SaaS apps and no legacy file shares migrates in weeks; one with deep NTFS-permission file shares needs a longer parallel-run period.
Legacy LDAP-bound applications are the most commonly forgotten dependency — audit application configs, not just user memory
Wi-Fi 802.1X and VPN authentication often depend on AD indirectly via RADIUS — trace this explicitly
File shares with deep NTFS permission structures are usually the longest-running dependency to retire
Step 2 — Set up bidirectional sync as a parallel-run bridge: Install a directory sync agent (JumpCloud's AD Sync is the standard tool for this) that keeps your existing AD and the new cloud directory in sync — user accounts, group memberships and password changes flow both ways during the transition, so nothing breaks for users while you migrate systems one at a time.
Test sync with a small pilot OU (organisational unit) before syncing the full directory
Confirm password changes sync correctly in both directions before wider rollout
Keep sync running throughout the entire migration — don't cut it early
Step 3 — Migrate SaaS app authentication to the cloud directory first: Move SaaS application SSO (SAML/OIDC-based apps) to authenticate against the new cloud directory first — this is the lowest-risk, highest-value migration step, since SaaS apps have no NTFS/file-share complexity and users experience an identical login flow through the new provider.
Migrate apps in batches, starting with lower-risk/lower-usage apps to catch issues early
Keep the old AD-based SSO path available as a fallback during each app's transition window
Communicate each app's cutover date to users in advance, even though the login experience shouldn't visibly change
Step 4 — Enrol endpoints into cloud-based device management: Move device management (previously via Group Policy) to the cloud directory's MDM/policy engine — Mac and Linux devices typically migrate cleanly since Group Policy never fully supported them anyway; Windows devices need policy mapping from Group Policy Objects (GPOs) to the new policy engine's equivalent settings.
Audit your current GPOs before migration — many accumulate years of unused or conflicting settings worth retiring, not migrating
Mac and Linux devices are usually the easiest win — migrate them first to build confidence
Pilot Windows device policy migration on a small group before full rollout
Step 5 — Migrate LDAP-bound and RADIUS-dependent systems: For legacy applications that specifically require LDAP, and for Wi-Fi/VPN authentication via RADIUS, most cloud directory platforms offer LDAP-as-a-Service and RADIUS-as-a-Service that let the legacy system point at the new directory without being rewritten. This is usually the trickiest technical step — test thoroughly before cutting over production Wi-Fi authentication.
Test RADIUS/Wi-Fi authentication cutover after hours or on a guest network segment first
Confirm legacy application LDAP queries actually work against the new service before retiring AD LDAP
Keep a documented rollback plan specifically for this step — it has the highest risk of a visible outage
Step 6 — Address file-share permissions last: File shares with deep NTFS permission structures tied to AD security groups are typically the longest-running dependency — either migrate file storage to a cloud-native alternative with its own permission model, or maintain a minimal AD footprint specifically for file-share authentication until the underlying storage is also migrated.
Consider whether migrating file storage itself (to SharePoint, Google Drive, or similar) removes this dependency entirely rather than just relocating it
A minimal, tightly-scoped AD instance kept alive only for file-share auth is a legitimate interim state, not a failure
Document explicitly why any residual AD dependency remains, with a target retirement date
Step 7 — Retire AD once every dependency is confirmed migrated: Don't decommission AD until you've actively verified — not assumed — that every system from your Step 1 inventory now authenticates against the cloud directory. Run a final audit against the original dependency list, keep AD in a stopped-but-recoverable state for a defined grace period, then fully retire it.
Cross-check the final state against your original Step 1 inventory line by line
Keep a recoverable (not deleted) AD backup for a defined grace period after cutover, in case something was missed
Document the completed migration and dependency map for future reference
Frequently Asked Questions
How long does a full AD-to-cloud migration take?
For a 200-user organisation with a moderate SaaS footprint and some legacy dependencies: 8-16 weeks end to end. Companies with minimal legacy file-share/LDAP dependencies can complete significantly faster; those with deep NTFS permission structures or many legacy LDAP-bound applications should budget toward the longer end.
Can we migrate gradually, or does it have to be all at once?
Gradual is strongly recommended and is how this guide is structured — bidirectional sync keeps both directories consistent throughout, letting you migrate systems in order of risk (SaaS apps first, file shares last) rather than a single cutover weekend that risks breaking everything simultaneously if something goes wrong.
What happens to existing user passwords during migration?
With bidirectional sync properly configured, password changes made in either directory propagate to the other during the parallel-run period, so users don't need to reset passwords or learn a new login process until their specific systems have fully cut over — and even then, the login credential itself typically stays the same.
Do we lose Group Policy functionality entirely?
You lose classic on-premise Group Policy Objects specifically, but cloud directory platforms provide policy engines covering most of what GPOs commonly enforced — password complexity, disk encryption requirements, application restrictions. A handful of very Windows-specific, deeply customised GPO settings may not have a direct cloud equivalent and need a workaround, which is worth auditing in Step 4 before committing to a full cutover date.
WhatsApp +91 98119 98370 for an INR quote with GST invoice, deployment support, and ongoing service from National IT Service.