How can I represent an on-premises OU hierarchy in Entra ID?

If the client still wants directory-based provisioning, ask them to define a synchronization process that updates the chosen attributes or groups whenever someone changes department. Entra ID doesn’t have a native OU tree to walk, so the integration has to consume one of those explicit representations instead of attempting to recreate the old traversal.

If you need a hierarchy inside Entra ID, model it explicitly rather than trying to traverse OUs. For example, maintain groups for the relevant organizational levels, using consistent names such as Directorate, Department, Unit, and Team. Your integration can then read group membership and group metadata through Microsoft Graph.

User attributes such as department can work, but only if there is a process that reliably maintains them. The on-premises distinguished name is primarily a synchronization attribute and shouldn’t be treated as the authoritative organizational model, especially if the website needs a stable department ID or parent-child relationship.

The best source is usually the client’s HR or organizational-data system, not Active Directory or Entra ID. HR should be able to provide stable organization IDs, parent organization IDs, names, and user assignments through an API or regularly generated file. Use that data to build the website hierarchy, and use Entra ID only to resolve users or authenticate them.

That avoids depending on OU placement or manually maintained user attributes, both of which can become inconsistent with the actual business structure.