Active Directory On-Prem to Cloud: Migration Checklist for Indian MSMEs

The typical Indian MSME's on-prem Active Directory (AD) deployment is not what the Microsoft documentation imagines. It is a Windows Server 2016 (or 2019, if you're lucky) machine in a cupboard somewhere, running on a single power supply, on a subnet that was set up by a vendor who hasn't picked up the phone since 2022. It holds about 40 user accounts, 12 of which belong to ex-employees. Its backups are a BackupExec job that last ran successfully in November. The admin password is in three WhatsApp chats.

This is not a judgement — this is what shipping an IT budget looks like at a growing company. But it's also exactly why the migration off on-prem AD is nerve-wracking: the domain controller (DC) is load-bearing in ways nobody documented, and nobody wants to be the person who breaks Monday-morning login for 60 people.

This article is the checklist we use when helping Indian MSMEs move to a cloud-hosted AD-compatible service. It assumes a 15–200 person team, a single (maybe two) physical DC, and no dedicated IT team. If you're running multi-forest enterprise AD with Exchange, ADFS, and Hyper-V clusters, this isn't your article — you need a full Microsoft-certified migration partner.

Why migrate at all?

Three things typically force the question for Indian MSMEs:

• Hardware is dying. Your 2016 Dell tower has been fine for six years, but it's throwing SMART warnings and the replacement quote is ₹1.4L before Server 2022 licensing.
• Compliance is biting. Clients are asking for ISO 27001, SOC 2, or DPDP-Act-aligned access audits, and a Windows DC in an unlocked cupboard doesn't clear the room.
• People are the single point of failure. The one engineer who knows the domain is thinking about leaving, and the cost of not knowing how the domain works is about to be realised.

If none of these apply, don't migrate yet — on-prem AD is fine when it works. But if two of three are true, you're on the clock.

For the full cost comparison between keeping the on-prem setup and moving to a cloud service, we wrote the Active Directory cost breakdown for Indian MSMEs article separately.

Before you touch anything: the pre-flight audit

This is the part most teams skip, and it is the part that causes 80% of migration weekend pain. Block out two afternoons for it.

1. Inventory everything the DC is doing

AD is never just AD. On the same Windows Server box you will typically find:

• Group Policy Objects (GPOs) — which machines get which wallpaper, which drive mappings, which USB restrictions
• DNS — internal name resolution for server1.company.local, printer.company.local
• DHCP — IP address handout for the office LAN
• File shares — the legendary \\server\shared\ mapped as Z:\
• Print queues — the office Xerox pointed at the DC as its spooler
• Certificate Services — a sneaky one, often silently issuing internal TLS certs
• WSUS — Windows Update distribution
• A backup job — that may or may not still be running

Run through each role in Server Manager and write it down. You'll migrate AD itself, but the rest need homes: DHCP moves to your router or a new box, file shares move to cloud storage or a NAS, print queues get re-pointed, certs typically get retired in favour of public CAs.

2. Audit users and groups

Export everyone. In PowerShell on the DC:

Get-ADUser -Filter * -Properties Enabled,LastLogonDate,Title,Department |
  Export-Csv C:\ad-users.csv -NoTypeInformation

Every Indian MSME audit I've run has produced the same numbers: ~20% of accounts are ex-employees who never got offboarded. Another ~10% are service accounts nobody can explain. Tag each row before migration: keep, disable, delete.

Do the same for groups. The "IT_Admins" group that has seven people in it, five of whom haven't worked at the company in two years, is not rare.

3. Map every machine that joins the domain

Get-ADComputer -Filter * -Properties LastLogonDate |
  Export-Csv C:\ad-computers.csv -NoTypeInformation

Anything that hasn't logged on in 90 days is probably gone — a laptop that left with an employee, a desktop that was replaced, a VM that was decommissioned. These need to be dropped before migration; otherwise they clutter the new directory.

4. Document your GPOs

Back up every GPO (Backup-GPO -All -Path C:\gpo-backup) and actually read them. Most Indian MSMEs have 5–15 GPOs; of those, only 3–4 matter. Identify which policies are load-bearing (screen lock, password policy, USB restriction, drive mapping) and which are cargo-cult (dating from a vendor setup in 2017).

5. Test your backup. Actually test it.

Do not start a migration without a verified, recent, restorable backup of the existing DC. Not "the tape light blinks" — an actual test restore to a spare machine, confirmed. This is your rollback plan.

The migration runbook (9 steps)

Schedule the cutover for a Saturday when the office is empty. Most Indian MSMEs can compress this into 4–6 hours if the audit is solid.

1. Pick your target service. For a 15–200 person Indian team, a cloud-managed Samba-based AD (like Warden) is the pragmatic choice — full AD protocol compatibility, no Windows Server licence, optional built-in VPN. If you want exact costs before going further, run the numbers through the Warden calculator.
2. Provision the new cloud directory. Create the domain (usually corp.yourcompany.com), set the admin account, enable MFA on it before you do anything else.
3. Pre-create users. Bulk-import your cleaned CSV from step 2 of the audit. Set a one-time password flag so every user is forced to rotate on first login.
4. Pre-create groups and assign members. Mirror the on-prem group structure. This is also your chance to delete the "Old_Sales_Team_2019" cruft.
5. Set up the new VPN. A cloud-hosted AD isn't usefully reachable without a VPN tunnel from the office subnet. Warden bundles WireGuard; other services use OpenVPN or IPSec. Test the tunnel from one machine before cutover day.
6. Cutover weekend — disconnect the old DC from DNS/DHCP authoritative roles. Point clients at the new DNS (either the cloud service's DNS or your router). Migrate DHCP to the router or a new small box. Document the old DC's IP — you'll want to keep it up for 30 days as a fallback reference.
7. Re-domain-join each machine. This is the slow part. Un-join from the old domain, reboot, join the new. Scripted via PowerShell it takes about 10 minutes per machine; manually it's 15. Plan ~6 machines/hour/person.
8. Migrate GPOs. Import the Windows GPO backups into the new directory (most Samba-AD services support standard GPO format), or reduce them to the 3–4 that matter and re-author cleanly.
9. Keep the old DC on ice. Don't format it on Monday morning. Leave it powered on, disconnected from authoritative roles, for 30 days. You'll find something you forgot.

Traps that bite Indian MSMEs specifically

A short list of what's gone wrong in migrations I've seen:

• The network gear. Older office routers (some MTNL/Airtel-provided ones) can't hand out DHCP to more than 50 clients reliably. Before migrating DHCP off the DC, check.
• Printers that were bound to the old DC as their LDAP server. These will silently stop authenticating. Check every network printer's config before cutover.
• SAP / Tally setups bound to AD for SSO. These often have domain references in config files. Flag before cutover.
• Team members working remotely on cutover day. If they're not on the office subnet when DNS flips, their machine can't find the old or new domain. Schedule cutover when everyone is either (a) in office or (b) on the VPN.
• Power cut during the 4-hour window. Delhi and Bangalore summer afternoons are not the time to run this. Plan for a Saturday morning before temperatures (and load-shedding risk) peak.

After go-live: what to validate

On Monday morning, before the team walks in:

• Log in as a test user on at least one machine from each departmental group
• Confirm drive mappings, printer access, VPN handshake
• Run a test password change — the new directory should accept it and propagate within seconds
• Check the audit log for the login — if you don't see it, you've wired up the wrong directory
• Send a team-wide message with the new VPN client instructions, the password-reset URL, and a promise that "we're watching the logs today"

Expect 3–5 individual tickets on Monday (someone who didn't rejoin cleanly, someone whose machine cached an old credential, the one Mac user whose configuration profile is wrong). Plan to be available for the full morning.

After 30 days: what to clean up

• Format the old DC hardware — or better, recycle it through a responsible e-waste vendor (we have a note on this in the IT asset policy template)
• Remove AD-related DNS records from public DNS that nobody ever actually needed
• Cancel the Windows Server licence renewal
• Run a second pass on the users/groups list — migrations always reveal further cleanup opportunities
• Audit your new directory's admin access: the number of people who need domain-admin rights is almost always two, not eight

When not to migrate

• If you're under 10 people and don't use file shares, group policies, or VPN — you may not need a directory at all. A password manager like Unit and SSO into your SaaS tools covers more ground than you'd expect.
• If you're a regulated financial services firm with on-prem data residency constraints — cloud AD may not clear compliance. Keep the on-prem setup and invest in proper backup / HA.
• If your directory has >500 users with complex multi-forest trust — this article is not enough. Engage a Microsoft Gold Partner.

---

If you want a cost comparison that shows exactly where cloud-managed AD breaks even versus a new Windows Server box, the Warden pricing calculator runs the numbers for your team size. And the Warden vs Microsoft Active Directory comparison lays the feature-by-feature story side-by-side.

The honest summary is this: for an Indian MSME with 20–100 people and a dying on-prem DC, the migration itself is a single Saturday of work if the audit is done well. The hard part is the audit — and the audit is hard because the directory has been quietly accumulating cruft for five years. Clear that out, pre-stage the new directory, and go-live is anticlimactic. Which is exactly what you want from an infrastructure migration.