Preparing Active Directory for Cloud Migration

Identity is the dependency everything else waits on. Mailboxes, files, applications, permissions: all of it hangs off the directory. Which is why a migration that skips directory cleanup does not avoid the work, it just moves the work to the most expensive possible moment, after users are live and depending on the objects you now need to change.

What actually goes wrong

The same handful of problems turn up in nearly every environment that has been running for more than a few years.

Stale accounts. Users who left, contractors who finished, test accounts from a project in 2019. Each one becomes a licensed cloud identity or an attack surface, sometimes both.
Duplicate and conflicting objects. The same person as two accounts, or a contact and a user sharing an address. These block synchronisation and surface as errors mid-migration.
Inconsistent UPNs. User principal names that do not match a verified domain are the single most common cause of a stalled Microsoft 365 sync.
Group sprawl. Nested groups several layers deep that nobody can explain, granting access nobody intended.
Unowned service accounts. Accounts with elevated rights, non-expiring passwords, and no record of what breaks if you disable them.
Attributes that were never populated. Missing email addresses, departments and managers, which downstream cloud services expect.

Good to know: the unowned service account is the one that causes outages. Nobody wants to disable it because nobody knows what it does, so it migrates with elevated rights intact. Finding out what it authenticates before you move is worth the afternoon it takes.

The sequence that works

Audit before you touch anything. Inventory accounts, groups, service accounts and their last logon dates. You cannot clean what you have not counted.
Disable, wait, then delete. Disable stale accounts and leave them disabled for a defined period before deletion. Something always turns out to have depended on one.
Fix UPNs. Every user's UPN suffix should match a domain you have verified in the tenant. Do this before sync, not after.
Flatten group nesting. Reduce layers where you can and document the ones you keep.
Claim the service accounts. Assign an owner to each one, or establish that it can be retired.
Populate required attributes. Fill the fields your target services depend on.
Run sync in report mode. Validate that objects resolve cleanly before any live synchronisation.
Then migrate. With a hybrid period planned in, because almost nobody cuts over in a single night.

Key takeaways

Directory problems do not stay behind. They become cloud identity objects.
UPN mismatches are the most common cause of a stalled Microsoft 365 sync.
Disable stale accounts before deleting them, and wait.
Plan for a hybrid period. A single-night cutover is the exception, not the rule.

What else to know before moving to Azure

Beyond identity, three questions decide how smooth the project is.

What authenticates against on-premises Active Directory? Line-of-business applications, print servers, file shares, an old ERP. Each needs a decision: modernise it, keep a domain controller for it, or replace it. This inventory is where migrations slip, because the answer is often "we do not know" and finding out takes weeks.

What does your licensing actually cover? Organisations regularly discover mid-project that the features their design assumed require a higher tier than they own.

What is your rollback position? For each workload, know what "undo" looks like and how long you have to invoke it.

A cloud migration rarely fails on the technology. It fails on the thing nobody documented that turned out to be load-bearing.

Where this fits

If you are early enough to still be planning, an IT assessment gives you the inventory this work depends on. If the migration is already scoped, our cloud migration services and Navigate Infrastructure cover the execution.

Frequently asked questions

How do you prepare Active Directory for a cloud migration?

Start with an audit: stale accounts, duplicate objects, inconsistent UPNs, nested group sprawl and unowned service accounts. Remediate those on premises first, verify every user's UPN suffix matches a verified domain, then run directory synchronisation checks before you migrate anything.

What should I know before migrating our systems to Azure?

Identity is the dependency everything else waits on, so resolve it first. Know which applications authenticate against on-premises Active Directory, which service accounts nobody owns, and what your licensing actually covers. Plan for a hybrid period rather than a single cutover.

Do we have to clean up Active Directory before migrating?

You do not have to, but the problems migrate with you. Duplicate accounts, orphaned groups and inconsistent naming become cloud identity objects that are harder and more expensive to fix once users, mailboxes and permissions depend on them.

How long does Active Directory cleanup take before a migration?

For a typical small or midsize environment, the audit takes days and remediation takes two to six weeks depending on how many stale objects and undocumented service accounts turn up. Environments that have never been cleaned up take longer.

Keep exploring

Ready for a clear path forward?

Start with a Navigate Clarity Conversation. A free 30 minute review of where you stand and what to do first.

Start with a Clarity Conversation