Organizations currently using Microsoft Entra Connect Sync can transition to Microsoft Entra Cloud Sync to reduce their dependency on a Full On-Premises Synchronization Engine and move Synchronization Orchestration into Microsoft Entra ID.
Microsoft Entra Connect vs. Microsoft Entra Cloud Sync Features Comparison Table
|
Capability |
Microsoft Entra Connect Sync |
Microsoft Entra Cloud Sync |
|
Primary Architecture |
Full Synchronization Engine Installed On-Premises |
Cloud-managed synchronization with Lightweight On-Premises Agents |
|
Configuration Location |
Primarily On The Entra Connect Server |
Microsoft Entra Admin Center |
|
Synchronization Engine |
Runs On-Premises |
Runs primarily in Microsoft Cloud Services |
|
Users |
Yes |
Yes |
|
Groups |
Yes |
Yes |
|
Contacts |
Yes |
Yes |
|
Password Hash Synchronization |
Yes |
Yes |
|
Password Writeback |
Yes |
Yes |
|
Single AD Forest |
Yes |
Yes |
|
Multiple AD Forests |
Yes |
Yes |
|
Disconnected AD Forests |
Limited By Topology Requirements |
Yes — Major Cloud Sync Advantage |
|
Device Synchronization |
Yes |
No |
|
Hybrid Device Scenarios |
Yes |
Limited / Not Equivalent to Connect |
|
Advanced Synchronization Rules |
Yes |
Limited |
|
Custom Attribute Transformations |
Advanced |
Supported, but Less Extensive |
|
OU Filtering |
Yes |
Yes |
|
Attribute-Based Filtering |
Advanced |
More Limited |
|
Directory Extension Attributes |
Yes |
Yes |
|
Exchange Hybrid Attributes |
Yes |
Yes |
|
Cross-Forest References |
Yes |
No |
|
Merge Attributes from Multiple Domains |
Yes |
No |
|
Microsoft Entra Groups Provisioned Back to AD |
No / Legacy Writeback Architecture Differs |
Yes |
|
On-Demand Provisioning |
No |
Yes |
|
Cloud-Based Provisioning Logs |
Limited Compared with Cloud Sync |
Yes |
|
Multiple Provisioning Agents |
Staging-Server Model |
Yes |
|
Active/Active Sync Engines |
No |
No |
|
High Availability Model |
Active server + staging server(s) |
Multiple Registered Provisioning Agents |
|
Agent Auto-Update |
Connect must be maintained/upgraded |
Agents Automatically Updated by Microsoft |
|
Local SQL Database |
Yes |
No local ADSync Database |
|
SQL Express Support |
Yes |
Not applicable |
|
Full SQL Server Support |
Yes |
Not applicable |
|
ADSync Database Required |
Yes |
No |
|
Staging Mode |
Yes |
No |
|
Staging Servers |
Yes |
No |
|
Direct Access to Sync Engine |
Yes |
No Traditional Local Sync Engine |
|
Synchronization Service Manager |
Yes |
No |
|
Metaverse |
Yes |
Cloud-Managed Architecture |
|
Connector Spaces |
Yes |
Cloud-Managed Architecture |
|
Complex Object Joins |
Yes |
Limited |
|
Large/Complex Enterprise Rule Sets |
Strongest Option |
Limited Compared with Connect |
|
Multi-Forest Mergers/Acquisitions |
Supported |
Especially Well Suited |
|
Infrastructure Footprint |
Higher |
Lower |
|
Server Maintenance |
Required |
Reduced |
|
SQL Maintenance |
May be Required |
Not Required |
|
Cloud-Managed Configuration |
No |
Yes |
|
Provisioning Agent Footprint |
Not Applicable |
Lightweight |
|
Authentication: Password Hash Sync |
Yes |
Yes |
|
Authentication: PTA |
Can Configure/Support PTA Architecture |
Synchronization is Separate from PTA |
|
Seamless SSO |
Can Configure/Support |
Synchronization is Separate from Seamless SSO |
|
Federation / AD FS Integration |
Supported through Connect Configuration |
Not a Replacement for Federation Configuration |
|
Can Run Alongside the Other Product |
Yes, with carefully separated Migration/Control Scope |
Yes, with carefully separated Migration/Control Scope |
|
Best for Simple New Deployments |
Supported |
Preferred Starting Point |
|
Best for Complex Legacy Synchronization |
Yes |
Depends on Feature Requirements |
|
Microsoft Strategic Direction |
Existing Mature Platform |
Strategic future synchronization platform |
|
Migration Target |
Can remain where required |
Microsoft's Preferred Direction where Supported |
However, this Migration Should not be treated as simply:
Disable Entra Connect
↓
Install Cloud Sync
↓
Enable Synchronization
A Production Migration Requires Controlled Coexistence, Validation, Object Matching, Synchronization-Rule Management, and a Defined Rollback Period.
Microsoft's current Migration Guidance uses a Phased Approach in which Microsoft Entra Connect and Cloud Sync Temporarily Coexist while selected Active Directory Organizational Units are Migrated. Microsoft specifically warns against simply removing Pilot Objects from Entra Connect scope during the migration because doing so can cause reference deletions, including Group-Membership Changes, to be exported to Microsoft Entra ID.
The recommended migration architecture is:
Existing Environment
Active Directory
↓
Microsoft Entra Connect
↓
Microsoft Entra ID
Then:
Migration / Coexistence
Active Directory
↙ ↘
Entra Connect Cloud Sync Agent
↘ ↙
Microsoft Entra ID
Finally:
Active Directory
↓
Cloud Sync Provisioning Agents
↓
Microsoft Entra Cloud Provisioning Service
↓
Microsoft Entra ID
Step 1: Determine Whether the Environment is Eligible for Cloud Sync
Before deploying anything, compare the existing Entra Connect Configuration against the capabilities currently supported by Cloud Sync.
Do not assume that every Entra Connect Environment can be Migrated Directly.
Document whether the Environment Uses:
- Password Hash Synchronization
- Pass-through Authentication
- Seamless Single Sign-On
- Federation
- Device synchronization
- Password Writeback
- Exchange Hybrid
- Group Writeback
- Custom Synchronization Rules
- Custom Attribute Transformations
- Directory Extensions
- Multiple Forests
- Cross-Forest References
- Attribute Merging from Multiple Domains
- Large Groups
- Complex OU or Attribute Filtering
Cloud Sync still does not provide Complete Feature parity with Entra Connect.
For Example, Microsoft's current comparison shows that Entra Connect supports capabilities including Cross-Forest References and Merging Attributes from Multiple Domains that Cloud Sync does not currently support. Cloud Sync also has more limited attribute filtering capabilities.
Microsoft Entra Connect vs. Cloud Sync - Attribute Filtering Capabilities Matrix
|
Filtering / Attribute Capability |
Microsoft Entra Connect Sync |
Microsoft Entra Cloud Sync |
|
Domain-Based Filtering |
Yes |
Configuration/domain scoped |
|
OU-Based Filtering |
Yes |
Yes |
|
Security Group-Based Scoping |
Yes, with limitations depending on method |
Yes |
|
Attribute-Based Object Filtering |
Yes — Advanced |
Limited / Basic |
|
Different Attribute Filters by Object Type |
Yes |
More limited |
|
Multiple Attribute Conditions |
Yes |
Supported within available scoping capabilities |
|
AND Conditions |
Yes |
Supported where applicable |
|
OR Conditions |
Yes |
More limited than Connect's rule engine |
|
Inbound Attribute Filtering |
Yes |
Cloud-managed scoping |
|
Outbound Attribute Filtering |
Yes |
No equivalent Connect-style outbound synchronization-rule engine |
|
Filter Before Metaverse Processing |
Yes |
No traditional metaverse |
|
Filter After Metaverse Join |
Yes |
No traditional metaverse |
|
cloudFiltered Control |
Yes |
No |
|
Synchronization Rules Editor |
Yes |
No |
|
Custom Synchronization Rules |
Yes — Advanced |
No equivalent rule engine |
|
Rule Precedence |
Yes |
No Connect-style precedence engine |
|
Scoping Filter Groups |
Yes |
Limited |
|
Scoping Filter Clauses |
Yes |
Supported within Cloud Sync configuration |
|
Attribute Transformations |
Yes — Advanced |
Yes |
|
Direct Attribute Mapping |
Yes |
Yes |
|
Constant Attribute Mapping |
Yes |
Yes |
|
Expression-Based Attribute Mapping |
Yes |
Yes |
|
Set Attribute to No Mapping |
Through synchronization-rule design |
Yes — None mapping |
|
Conditional Attribute Transformation |
Yes |
Yes, using expressions |
|
Script-Like Expressions |
Yes |
Yes |
|
Custom Directory Extension Attributes |
Yes |
Yes |
|
Exclude Individual Attributes from Synchronization |
Yes |
Mapping can be changed/deleted |
|
Attribute Filtering by department |
Yes |
Limited depending on provisioning direction/scenario |
|
Attribute Filtering by extensionAttribute |
Yes |
Depends on exposed Cloud Sync schema/scoping support |
|
Attribute Filtering by userAccountControl |
Yes |
More limited |
|
EQUAL / NOTEQUAL Conditions |
Yes |
Supported in applicable Cloud Sync filters |
|
STARTSWITH / ENDSWITH Logic |
Yes |
Expression/filter capabilities vary by provisioning scenario |
|
Regex Filtering |
Through advanced expression/rule design |
Supported in certain Cloud Sync scoping scenarios |
|
Filter Using Multiple AD Attributes |
Yes — Advanced |
More limited |
|
Different Rules for Users and Groups |
Yes |
Yes, mappings are object-type specific |
|
Different Rules by Forest |
Yes |
Configuration based |
|
Cross-Forest Attribute Evaluation |
Yes |
No equivalent capability |
|
Cross-Domain Attribute Evaluation |
Yes |
Limited |
|
Merge Attributes from Multiple Domains |
Yes |
No |
|
Evaluate Attributes After Object Join |
Yes |
No equivalent metaverse processing |
|
Positive Filtering — “Sync Only These Objects” |
Yes |
Supported through Cloud Sync scoping, but less flexible |
|
Negative Filtering — “Do Not Sync These Objects” |
Yes |
More limited |
|
Full Declarative Provisioning Engine |
Yes |
No |
|
Metaverse-Based Filtering |
Yes |
No metaverse |
|
Connector-Space Filtering |
Yes |
No traditional connector spaces |
|
Preview Complex Synchronization Rules |
Yes |
Different testing model |
|
On-Demand Provisioning Test |
No equivalent Cloud Sync feature |
Yes |
|
Cloud-Managed Attribute Configuration |
No |
Yes |
|
Overall Attribute Filtering Flexibility |
Very High |
Moderate / Limited |
|
Best for Complex Enterprise Filtering |
Microsoft Entra Connect |
Suitable for simpler requirements |
Microsoft Entra Connect's advantage comes from its declarative provisioning and synchronization-rule engine. It can apply attribute filtering inbound from AD to the metaverse or outbound from the metaverse to Microsoft Entra ID. Microsoft specifically describes attribute-based filtering in Connect as its most flexible filtering mechanism.
For example, Connect can implement logic such as:
IF department = "Sales"
AND employeeType = "Employee"
AND extensionAttribute15 != "NoSync"
THEN synchronize the user
ELSE exclude the user
It can also perform filtering after objects from Multiple Sources have joined in the Metaverse. Microsoft's documentation gives an example where an outbound rule evaluates attributes originating from different forests before deciding whether the resulting identity should synchronize.
Cloud Sync is considerably simpler. It supports customizable mappings with Direct, Constant, Expression, and None mapping types, and its expression system can transform source values into target values. Its basic synchronization scope can also be defined using all users, selected security groups, or selected OUs.
Key Difference
Entra Connect
Active Directory Attribute
↓
Connector Space
↓
Synchronization Rule Scoping Filter
↓
Join / Match Rules
↓
Metaverse
↓
Transformations
↓
Outbound Scoping Rules
↓
Microsoft Entra ID
Cloud Sync
Active Directory Attribute
↓
Cloud Sync Provisioning Agent
↓
Cloud Sync Scope + Attribute Mapping
↓
Expression / Transformation
↓
Microsoft Entra Cloud Provisioning Service
↓
Microsoft Entra ID
Microsoft Entra Connect — Advanced Enterprise Attribute Filtering
Microsoft Entra Cloud Sync — Basic/Limited Attribute Filtering with strong Attribute-Mapping and Transformation Capabilities
If the organization depends on an unsupported capability, do not proceed with the production migration.
Microsoft states that organizations depending on features not yet available in Cloud Sync are not required to migrate until those capabilities become supported.
Step 2: Document the Existing Entra Connect Configuration
Before making changes, document the production synchronization configuration.
Record:
Active Directory Forests
corp.contoso.com
Microsoft Entra Tenant
contoso.onmicrosoft.com
Verified Domains
contoso.com
Synchronization Scope
OU=Corporate Users
OU=Service Accounts
OU=Security Groups
Source Anchor
msDS-ConsistencyGuid
Authentication Method
Password Hash Synchronization
Synchronization Rules
Document all custom inbound and outbound synchronization rules.
Optional Features
Document Features such as:
- Password Writeback
- Exchange Hybrid
- Directory Extensions
- Group-Related Provisioning
- Seamless SSO
The objective is to establish exactly what Entra Connect currently provides before replacing any part of it.
Step 3: Back Up the Microsoft Entra Connect Configuration
Export and preserve the current Entra Connect configuration.
Entra Connect automatically stores configuration snapshots under:
%ProgramData%\AADConnect
with filenames similar to:
Applied-SynchronizationPolicy-*.json
Copy the current configuration to a secure administrative location.
For Example:
\\IdentityAdmin\Config\EntraConnect\Pre-CloudSync-Migration\
Also document custom synchronization rules separately.
This configuration provides an important reference and rollback resource during the migration.
Microsoft specifically recommends backing up the Entra Connect configuration using its import/export functionality before migration.
Step 4: Identify a Pilot Organizational Unit
Do not migrate the entire production directory first.
Create or identify an OU containing a small number of representative users.
For Example:
OU=CloudSync-Pilot,DC=contoso,DC=com
Select Users representing different Identity Scenarios.
For Example:
Standard User john@contoso.com
Microsoft 365 User mary@contoso.com
Group Member robert@contoso.com
Manager susan@contoso.com
The pilot population should be large enough to Validate Synchronization but small enough that problems can be investigated without affecting the Entire Organization.
Microsoft's current Migration Procedure specifically recommends Identifying or creating an OU for the Migration Pilot.
Step 5: Keep the Pilot OU in Entra Connect Scope
This Point is Critical.
Do not immediately remove the pilot OU from Microsoft Entra Connect Synchronization Scope.
Earlier Migration Approaches commonly used simple OU Exclusion to Separate Synchronization Engines. Microsoft's current Migration Procedure is more Sophisticated.
During coexistence, Microsoft instructs Organizations to keep Migrated Objects within the existing Entra Connect Scope and use Synchronization Rules that prevent Entra Connect from Exporting Conflicting Changes.
Removing the objects prematurely can cause Entra Connect to interpret them as out-of-scope objects and export reference deletions.
For Example:
User Removed from Connect Scope
↓
Entra Connect Detects Scope Change
↓
Reference Changes Calculated
↓
Group Membership / Manager References Potentially Affected
Microsoft therefore specifically warns:
Keep the existing Entra Connect scope configured until the objects have been fully migrated and final cutover is ready.
Step 6: Record the Pilot Objects
Use PowerShell to record the Users Currently Located in the Pilot OU.
For Example:
Get-ADUser -Filter * `
-SearchBase "OU=CloudSync-Pilot,DC=contoso,DC=com"
Record the Object Count.
You can also export the objects for migration documentation:
Get-ADUser -Filter * `
-SearchBase "OU=CloudSync-Pilot,DC=contoso,DC=com" `
-Properties UserPrincipalName,mail,proxyAddresses |
Export-Csv C:\Migration\CloudSyncPilotUsers.csv -NoTypeInformation
Microsoft includes OU User-Count Validation as part of its current Migration Workflow.
Step 7: Stop the Entra Connect Synchronization Scheduler Temporarily
Before modifying the Entra Connect Synchronization Rules, Temporarily Stop Scheduled Synchronization.
Open PowerShell as Administrator on the active Entra Connect Server.
Run:
Import-Module ADSync
Set-ADSyncScheduler -SyncCycleEnabled $false
Verify:
Get-ADSyncScheduler
Confirm:
SyncCycleEnabled : False
This prevents Synchronization Cycles from running while the Migration-Specific Rules Are Being Configured.
Step 8: Configure the Migration Synchronization Rules
Microsoft's current Migration Procedure uses special Synchronization Rules to Control which Synchronization Engine Manages Migrated Objects.
The important concepts are:
cloudNoFlow
and
JoinNoFlow
These Rules allow the Pilot Objects to remain within Entra Connect Scope while preventing Entra Connect from Exporting Object Additions, Deletions, and Non-Reference Attribute updates for Objects being Migrated.
Reference Attributes can continue to participate in Resolution During Coexistence.
This is Substantially Safer than simply removing the Pilot OU from Entra Connect Scope.
Follow Microsoft's current Migration Tutorial when constructing these Rules Because their exact Implementation and Precedence are part of the Supported Migration Procedure.
Step 9: Prepare the Cloud Sync Agent Servers
Deploy the Windows Servers that will host the Microsoft Entra Cloud Sync Provisioning Agents.
For Example:
CLOUDSYNC01
CLOUDSYNC02
CLOUDSYNC03
Each Server Should:
Be Domain Joined.
Run a currently supported Windows Server Version.
Have connectivity to Active Directory Domain Controllers.
Have outbound HTTPS connectivity to Microsoft Entra Services.
Have required LDAP and Global Catalog Connectivity.
Be protected as Privileged Identity Infrastructure.
Unlike Entra Connect staging Servers, Cloud Sync does not use Staging-Mode Synchronization Servers.
Microsoft currently states that Staging Servers aren't supported by the Cloud Provisioning Agent.
Step 10: Install the First Cloud Provisioning Agent
Sign in to the:
Microsoft Entra admin center
Navigate to:
Microsoft Entra ID
↓
Entra Connect
↓
Cloud Sync
↓
Agents
Select:
Download On-Premises Agent
Download: AADConnectProvisioningAgentSetup.exe
Copy the installer to: CLOUDSYNC01
Run the installer.
Step 11: Register the Provisioning Agent
During installation, authenticate to Microsoft Entra ID using the required administrative account.
The agent registers with the Microsoft Entra Cloud Provisioning Service.
Provide the required Active Directory administrative credentials when prompted.
The installation configures the required service identity and establishes connectivity between:
Microsoft Entra Cloud Provisioning Service
↓
Cloud Provisioning Agent
↓
Active Directory
Step 12: Verify the Provisioning Agent
Return to:
Microsoft Entra admin center
↓
Microsoft Entra ID
↓
Entra Connect
↓
Cloud Sync
↓
Agents
Verify that:
CLOUDSYNC01
appears as a Healthy Registered Agent.
Do not Configure Production Synchronization Until Agent Health has been Verified.
Step 13: Deploy Additional Cloud Sync Agents
For Production Resiliency, install additional Provisioning Agents.
For Example:
CLOUDSYNC01
CLOUDSYNC02
CLOUDSYNC03
All communicate with:
Microsoft Entra Cloud Provisioning Service
However, Cloud Sync agent resiliency should not be confused with Entra Connect's active/staging architecture. Microsoft's current FAQ states that the agents do not load-balance synchronization work; only one agent is active at a time.
Therefore:
Entra Connect HA
1 Active + Staging Servers is replaced by:
Cloud Sync Agent Resiliency Multiple Registered Provisioning Agents
with the Cloud Sync service controlling agent operation.
Step 14: Create the Cloud Sync Configuration
In the Microsoft Entra admin center navigate to:
Microsoft Entra ID
↓
Entra Connect
↓
Cloud Sync
Select:
New Configuration
Choose the appropriate Active Directory Domain.
For Example:
corp.contoso.com
Do not immediately scope the Entire Production Directory.
Configure the Pilot Population First.
Step 15: Configure Pilot Scope
Configure the Cloud Sync Job to target the Pilot Population.
For Example:
OU=CloudSync-Pilot,DC=contoso,DC=com
Verify that only the Intended Objects are included.
The migration should now logically look like:
Production Users
↓
Entra Connect
↓
Microsoft Entra ID
while:
Pilot Users
↓
Cloud Sync
↓
Microsoft Entra ID
with the Migration-Specific Entra Connect No-Flow Rules preventing conflicting ownership of Migrated Object Changes.
Microsoft does not support Connect Sync and Cloud Sync Independently Managing the same Objects Simultaneously.
Step 16: Configure Attribute Mappings
Review Cloud Sync's attribute mappings.
Compare them against the existing Entra Connect mappings.
Pay particular attention to:
- userPrincipalName
- proxyAddresses
- displayName
- givenName
- sn
- department
- manager
- Employee Attributes
- Extension Attributes
If Entra Connect Uses Custom Synchronization Rules, determine whether equivalent Cloud Sync Expressions are supported.
Do not assume that Entra Connect Custom Synchronization Rules Automatically Translate into equivalent Cloud Sync Behavior.
Step 17: Verify Source Anchor and Object Matching
Existing synchronized users must remain the same Microsoft Entra objects after migration.
The objective is:
Existing AD User
↓
Existing Entra User
not:
Existing AD User
↓
New Duplicate Entra User
Validate:
Source Anchor
- onPremisesImmutableId
- User Principal Name
- proxyAddresses
- Existing object matching
This is one of the most important migration validation steps.
Step 18: Configure Password Hash Synchronization
If the existing environment uses Password Hash Synchronization, configure Cloud Sync accordingly.
The desired result is:
Active Directory Password
↓
Password Hash Synchronization
↓
Cloud Sync
↓
Microsoft Entra ID
Validate Password Synchronization before retiring the equivalent Entra Connect Synchronization Function.
Step 19: Understand PTA and Seamless SSO During Migration
If the Environment Uses:
Pass-Through Authentication
or:
Seamless Single Sign-On
do not assume that removing Entra Connect Automatically means those capabilities must disappear.
Microsoft States that Hybrid Authentication Capabilities such as PTA and Seamless SSO are Configured Separately from the Synchronization Engine and can continue operating after Migration through the Entra Connect Configuration Infrastructure.
Therefore, separate these two Architectural Decisions:
Identity Synchronization
Entra Connect → Cloud Sync from:
User Authentication PHS / PTA / Federation / Seamless SSO
A Synchronization Migration is not Automatically an Authentication Migration.
Step 20: Use On-Demand Provisioning
Before enabling the complete pilot, test individual users using On-Demand Provisioning.
Select a Pilot User.
For Example:
john@contoso.com
Run: Provision on Demand
Review: Scoping
↓
Object Matching
↓
Attribute Mapping
↓
Provisioning
↓
Result
Verify that Cloud Sync identifies the existing Microsoft Entra object rather than attempting to create an incorrect duplicate.
Microsoft specifically recommends On-Demand Provisioning for validating Cloud Sync configuration during migration.
Step 21: Enable the Pilot Cloud Sync Configuration
After validation, enable the Cloud Sync configuration.
Monitor:
Provisioning Logs and Verify:
- Users Synchronize Successfully.
- No Duplicate Users Appear.
- Attributes Remain Correct.
- Group Memberships Remain Correct.
- Manager Relationships Remain Correct.
- Password Hash Synchronization Works Where Configured.
- Existing Microsoft 365 Access Remains Intact.
Step 22: Restart the Entra Connect Scheduler
After the migration-specific synchronization rules have been configured and validated, restart the Entra Connect synchronization scheduler.
Run: Set-ADSyncScheduler -SyncCycleEnabled $true
Verify: Get-ADSyncScheduler
Confirm: SyncCycleEnabled : True
The supported Migration Design Permits Entra Connect to continue Synchronizing the rest of the Environment while Cloud Sync Manages the Migrated Population through the Controlled Coexistence Configuration. Microsoft's Migration Tutorial Specifically includes stopping the Scheduler, Configuring Migration Rules and Cloud Sync, and then Restarting the Scheduler.
Step 23: Monitor the Pilot
Do not Immediately Migrate the remaining Organization.
Monitor the Pilot.
Verify:
AD attribute modification
↓
Cloud Sync detects modification
↓
Microsoft Entra Cloud Provisioning Service processes change
↓
Microsoft Entra object updated
Test representative changes such as:
- Display name
- Department
- Job title
- Group membership
- Manager
- Password
- Proxy addresses where applicable
Also inspect:
Microsoft Entra ID
↓
Monitoring & health
↓
Provisioning logs
Resolve Synchronization Errors before expanding the Migration.
Step 24: Expand Migration in Controlled Batches
After successful pilot validation, migrate additional object populations.
For Example:
Phase 1
OU=CloudSync-Pilot
↓
Phase 2
OU=Finance
↓
Phase 3
OU=Human Resources
↓
Phase 4
OU=IT
↓
Phase 5
OU=Corporate Users
For Each Phase:
Identify Objects
↓
Apply Migration Controls
↓
Configure Cloud Sync Scope
↓
Run On-Demand Tests
↓
Enable Provisioning
↓
Validate
↓
Monitor
↓
Proceed to Next Batch
Microsoft's current guidance specifically supports Migration in Batches such as OUs.
Step 25: Validate Reference Attributes
Before final cutover, verify relationships between directory objects.
This includes:
- Group Memberships
- Manager Relationships
- Referenced Contacts
- Cross-Object Relationships
This validation is especially important because reference attributes are one of the reasons Microsoft warns against prematurely removing objects from Entra Connect scope during coexistence.
Step 26: Verify the Entire Production Scope Is Managed by Cloud Sync
Before retiring Entra Connect, verify that every intended production object is successfully managed through Cloud Sync.
Validate:
✓ Users
✓ Groups
✓ Contacts where applicable
✓ Passwords
✓ Attributes
✓ Group Membership
✓ Manager Relationships
✓ Exchange Attributes where applicable
✓ Directory Extensions where applicable
✓ Provisioning Logs
The objective is:
All Required Objects
↓
Cloud Sync
↓
Microsoft Entra ID with no remaining synchronization dependency on Entra Connect.
Step 27: Stop Microsoft Entra Connect for Final Cutover
Once all required objects have been successfully migrated and validated, stop Entra Connect synchronization as part of the final cutover.
Microsoft recommends leaving the Entra Connect server available in a disabled state temporarily rather than immediately uninstalling it.
This provides a rollback window.
The Architecture Becomes:
Active Directory
↓
Cloud Sync Agents
↓
Microsoft Entra Cloud Provisioning Service
↓
Microsoft Entra ID
While:
Microsoft Entra Connect
Disabled / Rollback Only
Step 28: Do Not Immediately Uninstall Entra Connect
Keep the Entra Connect server intact during the validation period.
Do not immediately:
- Uninstall Entra Connect.
- Delete its database.
- Delete service accounts.
- Delete its configuration backups.
- Destroy the VM.
- Remove synchronization documentation.
Instead:
Disable
↓
Monitor
↓
Validate
↓
Retain Rollback Capability
↓
Decommission Later
Microsoft's migration guidance explicitly recommends leaving Entra Connect disabled for a period while the Cloud Sync migration is verified.
Step 29: Validate Cloud Sync in Production
During the post-cutover validation period, verify:
New User
Active Directory
↓
Cloud Sync
↓
Microsoft Entra ID
Modified User
Active Directory
↓
Cloud Sync
↓
Microsoft Entra ID Updated
Password Change
Active Directory
↓
Password Hash Synchronization
↓
Microsoft Entra ID
Disabled User
Active Directory
↓
Cloud Sync
↓
Microsoft Entra ID Updated
Also validate:
- Microsoft 365 Authentication
- Group Memberships
- Conditional Access Targeting
- Exchange Attributes
- Application Assignments
- Licensing
- Password Changes
- Manager Relationships
- Identity Governance Workflows Where Applicable
Step 30: Establish a Rollback Decision Point
Define the conditions under which the organization would return temporarily to Entra Connect.
For Example:
Cloud Sync migration problem detected
↓
Disable Cloud Sync Configuration
↓
Validate Entra Connect Configuration
↓
Restore Entra Connect synchronization authority
↓
Run controlled synchronization
↓
Validate Microsoft Entra ID
Do not activate both platforms indiscriminately for the same object population.
Rollback must restore a single authoritative synchronization path.
Step 31: Decommission Microsoft Entra Connect
Only after Cloud Sync has operated successfully through the organization's defined validation period should Entra Connect be permanently decommissioned.
Verify that no remaining capability depends on the server.
Then:
Document Final Entra Connect Configuration
↓
Preserve Configuration Backup
↓
Disable Synchronization
↓
Verify Cloud Sync
↓
Uninstall Entra Connect
↓
Remove Obsolete Service Accounts
↓
Remove Obsolete SQL Databases
↓
Decommission Entra Connect Server
↓
Update Architecture Documentation
Microsoft's migration guidance places decommissioning at the end of the process, after successful Cloud Sync validation.
Transitioning an Environment with Entra Connect Staging Servers
An Enterprise Environment May Currently Contain:
ENTRACONNECT01 — ACTIVE
ENTRACONNECT02 — STAGING
ENTRACONNECT03 — STAGING
The migration should not attempt to reproduce this architecture directly in Cloud Sync.
The transition is:
Before Migration:
Active Directory
↓
ENTRACONNECT01 — Active
ENTRACONNECT02 — Staging
ENTRACONNECT03 — Staging
↓
Microsoft Entra ID
During Migration
Active Directory
↙ ↘
Entra Connect Infrastructure Cloud Sync Agents
↘ ↙
Microsoft Entra ID
After Migration
Active Directory
↓
Cloud Sync Provisioning Agents
↓
Microsoft Entra Cloud Provisioning Service
↓
Microsoft Entra ID
↓
Entra Connect Servers Disabled
Once Cloud Sync has been Validated, the active Entra Connect Server and its Staging Servers can eventually be Decommissioned.
Cloud Sync does not require Administrators to Maintain Equivalent Staging Synchronization Servers.
Important: Do Not Use Simple OU Exclusion as the Migration Mechanism
One of the most important changes in Microsoft's current Migration Guidance is how Coexistence should be Handled.
Do not Design the Migration Simply as:
Remove OU from Entra Connect
↓
Add OU to Cloud Sync
That approach can cause Entra Connect to interpret Objects as Removed from Synchronization Scope and Export Unwanted Reference Changes.
Instead, Microsoft's Current Migration Process is:
Keep Objects in Entra Connect Scope
↓
Apply Migration No-Flow Rules
↓
Configure Cloud Sync
↓
Validate Objects
↓
Migrate in Controlled Batches
↓
Complete Final Cutover
↓
Stop Entra Connect
This distinction is important for production environments Containing Groups, Manager Relationships, and other Referenced Objects.
Exclusion vs. Migration No-Flow Rule Behavior
|
Behavior |
Exclusion |
Migration No-Flow Rule |
|
Object remains in Connect Scope |
No |
Yes |
|
Connect Continues Seeing/Importing Object |
No, once excluded from Applicable Scope |
Yes |
|
Existing Connect Relationship Remains Available during Coexistence |
Potentially Disrupted |
Yes |
|
Normal Attribute Flow from Connect |
Stops |
Suppressed Intentionally |
|
Cloud Sync can take over Attribute Flow |
Yes, but Cutover can be Disruptive |
Yes, Controlled Migration |
|
Connect can Interpret Object as Leaving Scope |
Yes |
No — that's what we're Avoiding |
|
Risk of Unintended Deletion/Reference Processing |
Higher during migration |
Designed to avoid this |
|
Appropriate for Permanent Filtering |
Yes |
No |
|
Appropriate for Connect → Cloud Sync Coexistence |
Not by itself |
Yes |
Final Migration Architecture
The Final Production Environment Should Look Like:
Active Directory Domain Services
↓
Microsoft Entra Cloud Sync Provisioning Agents
↓
Microsoft Entra Cloud Provisioning Service
↓
Microsoft Entra ID
The former architecture:
Active Directory
↓
Microsoft Entra Connect Server
↓
ADSync Database
↓
Microsoft Entra ID
is no longer required for directory synchronization.
This eliminates the traditional Entra Connect synchronization engine and its associated:
- ADSync Database
- SQL Infrastructure where Dedicated SQL was used
- Active/Staging Server Architecture
- Local Synchronization Rule Engine
- Synchronization Server Maintenance
while retaining the Active Directory-to-Microsoft Entra hybrid identity relationship through Microsoft's cloud-managed provisioning architecture.
Migration Summary
The complete transition can be summarized as:
Assess Cloud Sync Compatibility
↓
Document Entra Connect
↓
Back Up Entra Connect Configuration
↓
Create Pilot Population
↓
Keep Pilot Objects in Entra Connect Scope
↓
Configure Migration No-Flow Rules
↓
Deploy Cloud Sync Provisioning Agents
↓
Create Cloud Sync Configuration
↓
Validate Attribute Mappings
↓
Validate Source Anchor and Object Matching
↓
Test with On-Demand Provisioning
↓
Enable Pilot
↓
Validate
↓
Migrate Additional OUs in Batches
↓
Validate All Users, Groups and References
↓
Stop Entra Connect
↓
Retain Entra Connect for Rollback
↓
Validate Cloud Sync Production Operation
↓
Decommission Entra Connect
The most important principle is:
Do not make Entra Connect and Cloud Sync Independently Authoritative for the same Objects at the Same Time.
Microsoft supports Controlled Coexistence during Migration, but that Coexistence Depends on Carefully Defined Synchronization Scope and Migration-Specific No-Flow Rules.
Once every required Object and Feature has been Validated under Cloud Sync, Entra Connect can be Disabled, Retained Temporarily as a Rollback Mechanism, and Ultimately Decommissioned.
0 comments