Entra-only vs hybrid AD for small offices
A practical way for a 20-60 user firm to choose cloud-only identity, hybrid identity, and the right Windows device join without keeping domain controllers by habit.
- #microsoft
- #identity
- #entra
- #active-directory
- #msp

Small offices often describe themselves as “hybrid” because a domain controller still runs in a closet while everyone spends the day in Microsoft 365. That does not tell you whether the server is still necessary. It only tells you the migration stopped somewhere.
For a 20-60 user firm, the goal is not cloud purity. The goal is the simplest identity and device model that supports the work. Keep Active Directory Domain Services when a named dependency requires it. Do not keep it because mapped drives and Group Policy are familiar.
First, separate three decisions
“Entra-only versus hybrid” hides three questions:
- Where are user accounts authoritative? They can be created directly in Microsoft Entra ID, or created in on-premises AD and synchronized to Entra ID.
- How are Windows devices joined? A device can be Microsoft Entra joined or joined to AD and registered as Microsoft Entra hybrid joined.
- How are devices managed? Entra-joined devices normally use MDM such as Intune. Hybrid devices may use Group Policy, Configuration Manager, Intune, or an untidy mix.
Those choices do not have to move on the same day. A synchronized AD user can sign in to an Entra-joined PC. That lets a business move new endpoints to a cloud-native join while an application or file server still keeps hybrid identity alive.
Microsoft’s current join guidance for cloud-native endpoints recommends Entra join for new or reset Windows endpoints. It treats hybrid join as a transition for existing domain-joined devices, not the preferred end state for new PCs.
When Entra-only is the better default
Start with cloud-only users and Entra-joined devices for a new environment when:
- Microsoft 365 and other SaaS applications hold the business workflow
- Files live in SharePoint, OneDrive, or another managed cloud platform
- Windows settings and applications can be delivered through Intune or another MDM
- Authentication uses modern protocols rather than LDAP binds, NTLM, or AD computer accounts
- Staff work remotely enough that reaching a domain controller is an operational burden
- There is no established AD forest that must remain the source of employee identity
A Microsoft Entra joined device signs in with an organizational Entra account and supports Conditional Access, MDM, Windows Hello for Business, and SSO to cloud resources. Entra-joined devices can also reach many on-premises resources, but do not assume every old workload will work. Applications that authenticate the AD computer account, depend on a specific GPO, or expect old LDAP and NTLM behavior need individual testing.
The payoff is practical: no domain controllers to patch and restore, no sync server to monitor, and no VPN dependency just to process a password change or apply a computer policy.
When hybrid still earns its keep
Keep AD for now when the dependency inventory names something real:
- A line-of-business application authenticates users or machines directly against AD
- File permissions and service workflows rely heavily on AD groups and Kerberos
- Certificate services, RADIUS, print systems, or other infrastructure is bound to the domain
- Existing Windows applications use AD computer-account authentication
- A large installed fleet still needs Group Policy and cannot be reset or migrated safely yet
- Exchange or another supported hybrid workload requires directory synchronization
Microsoft says hybrid-joined devices require periodic network line of sight to domain controllers. That matters for a remote employee whose cached sign-in works until a password, TPM, or device-state change needs the domain. Hybrid also adds a synchronization layer; Microsoft documents both Entra Connect Sync and the newer agent-based Cloud Sync, with different supported scenarios.
Hybrid is reasonable when it is supporting a current dependency. It becomes expensive when nobody can name what would break if the last domain controller disappeared.
The costs that rarely reach the proposal
The server license is not the whole cost of AD.
- Domain controllers need patching, monitoring, tested system-state recovery, DNS care, and lifecycle planning.
- Directory synchronization needs health alerts and an owner who understands which directory is authoritative.
- Group Policy and Intune can configure the same setting differently, creating two control planes and long troubleshooting sessions.
- Remote devices need a reliable path to the domain for hybrid operations.
- Old service accounts, scripts, and scheduled tasks tend to survive because nobody inventoried them.
Cloud-only has costs too. Intune policies have to replace the outcomes that GPO delivered. Autopilot, application packaging, local admin control, certificate delivery, and support processes need to be ready. Our Intune enrollment guide covers the endpoint side; Entra join without management is not a finished design.
Run a dependency inventory before choosing
Build one table with these columns: workload, owner, authentication method, device dependency, data location, replacement plan, and test result.
Look specifically for:
- LDAP and LDAPS connections
- NTLM or Kerberos dependencies
- AD computer accounts used by applications
- GPO-delivered settings, scripts, certificates, printers, and drive maps
- File shares with complex ACLs
- Wi-Fi or VPN authentication using NPS/RADIUS
- Service accounts and scheduled tasks
- DNS, DHCP, and certificate roles installed on domain controllers
- Synced Exchange attributes or leftover hybrid management requirements
Do not accept “the accounting software needs the domain” without testing the supported configuration. On the other hand, do not dismiss a production machine-authentication dependency because the cloud diagram looks cleaner. Name the constraint, document its owner, and give it an exit plan.
A low-drama migration path
- Write the target state. State whether users remain synced, how new devices join, which platform manages them, and which on-premises workloads remain.
- Pilot an Entra-joined PC. Use a real employee and test file access, printing, line-of-business applications, VPN, certificates, and daily support tasks.
- Move new hardware first. Microsoft notes that converting an existing hybrid-joined PC to Entra join requires a Windows reset. Hardware refresh is the clean migration window.
- Replace policy outcomes, not every GPO. Rebuild the security and configuration settings still needed in Intune. Do not migrate twenty years of policy archaeology.
- Modernize one blocker at a time. Move team data, update an application, replace machine authentication, or redesign the print path.
- Test identity operations. New hire, password reset, device replacement, remote sign-in, and same-day offboarding must work in the target model.
- Retire infrastructure only after validation. Confirm AD-integrated DNS, certificate services, synchronization, backups, service accounts, and recovery procedures before demoting the last controller.
Use Conditional Access after device identity and management signals are trustworthy. Requiring a compliant device before enrollment works is a lockout plan, not a security plan.
Bottom line
For a new small office, cloud-only users, Entra-joined Windows devices, and MDM are the sensible default. For an existing office, hybrid can remain while specific workloads are modernized. Separate user identity from device join, move new PCs first, and make every remaining domain dependency earn its place on the list.

Michael Narehood