Active Directory Migration Readiness: What Must Work Before You Retire a Domain Controller

An Active Directory migration checklist should start with dependencies, not the date the old server is switched off. Identify what authenticates against the domain, how devices are managed, which applications use service accounts and how people reach files. Then choose the destination and prove representative workflows in a pilot. A working Microsoft 365 sign-in does not establish that every domain-dependent application can operate without Active Directory.

This is a readiness guide for business owners and IT teams planning a domain change, hybrid identity redesign or retirement of aging infrastructure. The actual procedure depends on the topology and destination. For platform selection first, read Microsoft Entra ID versus Active Directory.

1. Name the migration you are planning

Replacing a domain controller, moving users between domains and changing devices to a cloud-led identity model are different projects. Write down what will remain, what will move and what will be retired. Include the current and future authority for users, groups, passwords and device policy.

Define the business outcome in observable terms: remove an unsupported dependency, simplify administration or support a new operating model. Avoid treating retirement of every local server as a success criterion when a justified application dependency remains.

2. Build a dependency register

Ask application owners how staff actually work. Look beyond interactive logins to scheduled jobs, scanners, printers, mapped drives, remote access, certificates and services running under named accounts. Record DNS and network dependencies as well as the username shown on a sign-in screen.

3. Choose retained AD, hybrid identity or cloud-led devices

The right design follows the dependencies. Some businesses can move most user work to cloud services while keeping a limited domain for an application. Others need a domain migration or server refresh before considering a wider change. A hybrid design is a deliberate architecture when ownership and operating tasks are clear.

Microsoft's Entra join planning guidance calls out identity infrastructure, device management, applications and on-premises resources. Use those compatibility questions when choosing the device model. Do not assume that changing the sign-in screen also migrates application permissions or management policies.

4. Map identities and access before the pilot

Agree how existing people and groups correspond to the destination identities. Identify duplicate accounts, obsolete groups and administrative access that should not be carried forward. Business owners should approve access changes; a migration engineer should not guess that similarly named groups have the same purpose.

Document emergency access and recovery ownership separately from everyday administration. Keep credentials out of the migration workbook. The plan should point to the approved secure storage and recovery process, including who can authorize its use.

5. Pilot complete working days, not just logins

Select users with different roles and a representative mix of devices. Include remote staff, shared workstations and an application with a known dependency. Test their normal work: sign-in, printing, opening and saving files, approved application actions and recovery after a restart or network interruption.

For each test, record the starting state, expected result, actual result and evidence. Include negative tests: a person outside the finance group should remain unable to open finance data. A migration that makes every folder accessible has solved the wrong problem.

6. Set retirement and rollback gates

Before retiring a component, confirm that its intended replacement works, dependent services have been moved, recovery has been considered and monitoring no longer shows an unexplained dependency. Keep an unresolved-item list with an owner for each exception. Time elapsed since the pilot is not proof that the old component is unused.

Specify the last safe rollback point and who makes that decision. Once users create new records or passwords change across systems, returning to an earlier state may require reconciliation. The change plan must address that state, not merely say that a backup exists.

Questions to bring to an assessment

Can we remove Active Directory because we use Microsoft 365?

Possibly, but only after the application's authentication, device-management and resource-access requirements are established. Microsoft 365 usage by itself is insufficient evidence.

Do all devices need to move at the same time?

Not necessarily. A staged plan may reduce disruption, provided that identity ownership, access and support remain clear during coexistence. The appropriate sequence depends on the chosen design.

What should the project handover contain?

At minimum, the agreed architecture, identity/access mappings, test evidence, remaining exceptions, operating tasks and recovery contacts. Request these deliverables in the scope before the migration starts.

Plan the next step

Bring your server and application inventory to an Active Directory and Entra migration assessment. NetSys can help establish the dependencies, pilot plan and acceptance evidence before retirement decisions are made.