What DNS and other dependencies should we address before moving devices to Entra ID?

Entra join doesn’t automatically remove the need for internal DNS. If you still have on-premises servers, private cloud resources, file shares, line-of-business applications, or VPN services, you’ll need DNS infrastructure that can resolve those private zones. That might be Windows DNS, DNS provided by your network or cloud platform, or a secure DNS forwarder. The important part is making sure clients receive the right DNS settings through DHCP, VPN configuration, or device management before changing anything.

I’d treat this as an application and authentication migration rather than just a device-join change. Test each app from an Entra-joined device while connected both on and off the VPN. Confirm name resolution, certificate trust, authentication method, access to file shares, and whether the app uses hard-coded server names or IP addresses. Keep internal DNS and domain services running until the remaining dependencies are either migrated, published through an appropriate gateway, or confirmed to be unnecessary. Entra joining the endpoints by itself doesn’t make private resources internet-accessible.

Make an inventory before touching the domain controllers. Common dependencies include SMB file shares, printers, mapped drives, applications using LDAP or Kerberos, certificate auto-enrollment, Group Policy, scheduled tasks running under domain accounts, scripts, service accounts, SQL connections, monitoring tools, and VPN authentication. Also check whether devices need line-of-sight to a domain controller for sign-in or password changes. Entra ID and Intune can replace some of these functions, but not every application can be moved without configuration changes or a redesign.