Checklist: move from Active Directory to cloud identity

Who this is for

This checklist, Checklist: move from Active Directory to cloud identity, is for founders, IT leads, and operations managers who still depend on on-premises Active Directory for sign-in. It helps when Windows desktops join a domain, file shares use AD groups, and key apps trust Kerberos or LDAP. The goal is to move identity to a cloud service such as Microsoft Entra ID without breaking daily work.

It fits a small or mid-sized company that wants fewer domain controllers, simpler remote access, and one place to manage joiners and leavers. It also fits a company that plans to keep some on-prem systems but wants cloud sign-in as the default. The work is mostly inventory, sequencing, and testing, not a single cutover night.

It is not for a company that already runs cloud-only identity or has no AD dependency. If you run factory systems, older client apps, or network gear that only supports LDAP or RADIUS, treat those as exceptions and name an owner for each. This guide uses Entra ID terms because it is the common path from AD, but the checklist gates apply to Okta or Google Workspace too.

Before you begin

Start by writing down what identity does for the business today. That includes user sign-in, device join, Wi-Fi and VPN access, file share permissions, print servers, intranet single sign-on, and every app that trusts AD. Give one person decision rights and a second person the ability to run the same commands.

Inventory before you change sync. Export users, groups, organizational units, Group Policy objects, service accounts, and computer objects. Useful commands include Get-ADUser -Filter *, Get-ADGroup -Filter *, and Get-GPOReport. Store the exports with dates and note which groups control access to money, customer data, or production systems.

Choose the identity model. Cloud-only identity is simplest for new companies, but it means new credentials and no on-prem AD trust. Hybrid identity keeps AD as the source and syncs users to the cloud with Entra Connect or Entra Cloud Sync. For sign-in, password hash sync is the easiest to operate. Pass-through authentication keeps passwords on-premises but adds agents. Federation adds another service to run. Write the choice and the reason in one page.

Set a pilot group with a mix of roles and apps, and agree on rollback. Rollback can mean re-enabling an AD path, restoring a sync rule, or moving a pilot user back to the old sign-in flow. Do not start with finance or the CEO. Pick users who can report issues clearly.

The checklist

Run the checklist in order, but treat the items as gates, not a race. Each gate needs evidence: a test sign-in, a screenshot, a ticket closure, or a named approver. If an app fails, stop that app, not the whole program.

Keep a simple tracker with columns for item, owner, test user, pass or fail, and rollback step. Review it twice a week. The list below is written for a hybrid move to Entra ID, where AD may stay for some systems.

• Name one owner and one backup for the migration, and publish a rollback contact for each phase.
• Export all AD users, groups, OUs, GPO links, and service accounts, and store the files in a controlled repository.
• Tag each account as employee, contractor, shared, service, or vendor, and remove stale accounts before syncing.
• Map every application to its auth method: SAML, OIDC, header, LDAP bind, Kerberos, NTLM, or local password.
• List every device that joins the domain, including laptops, servers, printers, and network gear, and record its owner.
• Build a pilot group of users with common apps and at least one laptop, one mobile device, and one shared mailbox.
• Configure Entra Connect or Entra Cloud Sync for the pilot OU, and confirm UPNs match routable domains.
• Enable password hash sync or pass-through authentication, then test sign-in and password change from outside the office.
• Turn on security defaults or Conditional Access with MFA for admins, then for pilot users.
• Join pilot Windows devices to Entra ID, enroll them in Intune, and confirm Wi-Fi, VPN, and printer access.
• Move pilot apps to SSO one at a time, and keep a local break-glass admin path until each app passes.
• Replace LDAP binds and Kerberos dependencies with cloud app proxies, service accounts, or vendor-supported auth.
• Set up a test group for shared mailboxes, resource accounts, and Teams or SharePoint access.
• Define what stays on AD, such as legacy apps or on-prem servers, and document the ongoing sync boundary.

What good looks like

Good does not mean every server is gone. It means users sign in with a cloud UPN, MFA is enforced for admins and pilot groups, and devices are compliant before they reach company data. Leavers lose access in one place, and joiners get access through groups, not manual mailbox permissions.

App owners can name the sign-in method for each app. Shared accounts have named owners, and service accounts use certificates, managed identities, or scoped credentials where the app supports them. Help desk can reset a password or revoke a session without remoting into a domain controller.

Watch the edges. Group Policy does not apply to cloud-only devices, so move settings to Intune configuration profiles or scripts. File shares, print servers, and legacy apps may still need AD. Document the sync boundary and review it each quarter.

What to do next

Pick the first wave by app dependency, not by department. Start with users who rely on email, Teams, and a browser app, then add one business app at a time. Run a tabletop rollback test before the first production cutover and record the result.

If you need a fixed scope before you touch production, the Discovery and roadmap sprint from Cloudverg is one option at $9,500 fixed price, delivered in two weeks. It covers stakeholder interviews, target architecture, a phased roadmap with risks, and a fixed quote for phase one. Other options include doing the inventory in-house, hiring a contractor for the pilot, or asking your Microsoft partner for an assessment.

Whatever path you choose, finish the inventory and pilot design first. A clear boundary between cloud identity and remaining on-prem AD is the difference between a controlled move and a long cleanup.

Frequently asked questions