Tools & Implementation • Hybrid Identity

Microsoft Entra Cloud Sync: Moving Identity Management Towards the Cloud

Microsoft is moving hybrid identity synchronisation towards Cloud Sync. New cloud-to-Active Directory scenarios suggest a future in which Entra ID can govern identity while AD remains a controlled compatibility layer for services that still need it.

This is a transition guide, not a production deployment recommendation. Cloud-to-AD security-group provisioning is generally available, but newly documented user-provisioning options remain Preview and current Microsoft pages are not yet fully consistent.

Trends4You Editorial

Feature status

Separate the platform from the preview capability

Microsoft Entra Cloud Sync is an established hybrid identity service and Microsoft's stated strategic direction. That does not make every Cloud Sync scenario generally available.

ScenarioStatus and treatment
Active Directory to Entra ID users, groups and contactsEstablished Cloud Sync capability. Assess feature compatibility before migrating from Entra Connect Sync.
Entra ID to AD security groupsGenerally available. Microsoft directs customers away from the deprecated Group Writeback v2 preview in Connect Sync.
Switch an existing synced user's source of authority to Entra IDGenerally available since January 2026. The user becomes cloud managed rather than AD managed.
Provision cloud-managed users from Entra ID into ADPreview in newly published configuration guidance. Evaluate only in an isolated test environment unless Microsoft and organisational requirements permit otherwise.
Provision users and groups together from Entra ID to ADPreview. Treat combined configuration, membership and lifecycle behaviour as unproven for production use.
Enforce cloud authority for groups against direct AD changesPreview. Do not confuse provisioning a group with preventing an on-premises administrator from changing it.

Microsoft's documentation is still converging

New configuration material describes preview user and combined user-and-group provisioning, while the current Cloud Sync migration decision guide still lists cloud-to-AD user provisioning as unsupported. Confirm the status shown in your tenant and the latest Microsoft documentation before planning or approving use.

Three different changes

Source of authority is not the same as provisioning direction

GA

Move authority to the cloud

An existing AD-synchronised user can be converted so that Entra ID becomes its source of authority. The account is no longer managed through ordinary AD synchronisation.

GA

Provision cloud groups to AD

Cloud-managed security groups can be provisioned into AD where on-premises applications still depend on an AD group.

Preview

Provision cloud users to AD

A cloud-managed user can be created or managed in Entra ID and provisioned back into AD for a remaining on-premises dependency.

The important architectural idea

Identity can become cloud managed before every dependent application becomes cloud native. Active Directory can progressively move from being the master directory towards a narrower compatibility role.

Direction of travel

A cloud-first model can still support legacy access

1

Create and govern the identity in Entra ID

The organisation uses its cloud identity processes, appropriate lifecycle controls and accountable ownership as the primary management route.

2

Scope only the required on-premises presence

Where a person still needs an AD identity or group membership, Cloud Sync provisions the necessary object into a controlled OU rather than making the whole identity lifecycle depend on AD.

3

Retain access to a defined dependency

The AD object supports an application, file service, Kerberos-authenticated resource or other service that cannot yet consume the cloud identity directly.

4

Remove the dependency when feasible

As legacy services are replaced or modernised, reduce the scope of cloud-to-AD provisioning and retire unnecessary objects, agents and infrastructure through a governed exit plan.

Compatibility is not permanence. Provisioning back to AD can make a staged transition practical, but each remaining dependency should retain an owner, business reason, evidence and review or exit date.

Why Cloud Sync matters

Cloud-managed orchestration changes the operating model

Entra Connect Sync performs substantial synchronisation work through an on-premises server. Cloud Sync moves configuration, scheduling and orchestration into Microsoft Entra while retaining lightweight provisioning agents as the bridge to AD.

Cloud-managed configuration

Administrators configure and monitor synchronisation through the Entra admin centre rather than depending on direct management of one Connect server.

Multiple active agents

More than one active provisioning agent can provide failover, reducing the single-server dependency associated with a traditional Connect deployment.

Smaller on-premises footprint

The agent model can reduce infrastructure and maintenance, although it does not remove the need for secure agent hosts, AD connectivity and operational ownership.

Cloud-first scenarios

Cloud-to-AD group provisioning and source-of-authority capabilities support gradual modernisation rather than forcing immediate replacement of every AD-dependent service.

Do not migrate on direction alone

Cloud Sync is not yet feature-equivalent for every environment

Microsoft is notifying eligible organisations about phased migration windows, beginning with tenants whose requirements Cloud Sync already supports. Organisations relying on capabilities that are not yet available are not required to migrate until their needs are supported.

Current configurationInventory forests, object counts, group sizes, filtering, attribute flows, custom rules, authentication and writeback dependencies.
Known differencesReview Microsoft's live decision guide. Device synchronisation, complex sync rules, some cross-forest relationships and other scenarios differ from Entra Connect Sync.
Shared scopeDo not let Connect Sync and Cloud Sync manage the same objects simultaneously. Microsoft's migration guidance uses controlled scoping for coexistence.
RecoveryKeep exportable configuration, tested rollback, emergency cloud accounts, agent recovery and a process for failed or quarantined provisioning.

Practical preparation

Prepare for the transition without deploying preview user provisioning

  1. 01

    Map identity authority

    Record which identities and attributes are managed by AD, Entra ID, an HR platform or another process. Include service accounts, privileged identities and exceptions.

    Outcome:A defensible source-of-authority map.
  2. 02

    Find the AD dependencies

    Identify applications, file services, Kerberos resources, devices and operational processes that genuinely require an AD user or group.

    Outcome:A prioritised compatibility and exit register.
  3. 03

    Assess Cloud Sync compatibility

    Compare the live Microsoft decision guide with the actual Connect configuration. Treat undocumented assumptions as evidence gaps, not implied support.

    Outcome:Supported, unsupported and uncertain requirements.
  4. 04

    Design resilient agents

    Decide where agents would run, how they would reach domain controllers and Microsoft services, who would patch and monitor them, and whether multiple agents are proportionate.

    Outcome:An owned support and recovery design.
  5. 05

    Test outside production

    Use a test forest, test tenant or other properly isolated environment for preview user provisioning. Validate creation, updates, matching, passwords, attributes, group membership, disablement and deletion.

    Outcome:Recorded positive, negative and recovery tests.
  6. 06

    Wait for an evidence-based decision

    Do not approve production use solely because the option appears in the portal. Require suitable availability status, documentation, supportability and testing for the organisation's risk.

    Outcome:Adopt, defer or reject—with an owner and review trigger.

RACF-CC alignment

Modernise identity without ignoring feasibility

This transition belongs primarily in Domain 1: Identity & Access Management, with infrastructure and agent hardening from Domain 2, provisioning evidence from Domain 6, recovery planning from Domain 7 and accountable transition decisions from Domain 8.

Where AD remains because an application cannot yet be replaced, use the legacy-system treatment guide to contain and govern that dependency rather than pretending it has disappeared.

Use a controlled transition

Inventory → assess → isolate → pilot → validate → migrate → review

A cloud-first identity strategy can be gradual. Move authority and workloads only when the organisation has evidence that access, lifecycle, recovery and remaining AD dependencies behave as intended.

Primary sources

Microsoft documentation used for this guide

Last checked: 31 August 2026. Microsoft documentation was changing at the time of publication and did not describe cloud-to-AD user provisioning consistently across every page. Verify current status, licensing, limitations and tenant availability before testing or deployment.

Voluntary support

Found this useful? Support Trends4You

Trends4You's practical guides, RACF-CC resources and downloadable tools are provided free of charge. If they've helped you or your organisation, you can support the time and hosting that keeps them freely available.

Support is optional, handled securely by Stripe and does not provide additional access.