Migrating from Entra Connect to Cloud Sync in Complex Multi-Forest Environments

1. The Architectural Shift: Heavy Engine to Cloud Micro-Agents

For more than a decade, Microsoft Entra Connect (formerly Azure AD Connect / DirSync / AADSync) served as the hybrid identity backbone. Built upon the legacy Microsoft Identity Manager (MIM) architecture, it relies on an on-premises SQL Server database, an in-memory metaverse, and a localized declarative synchronization engine.

Microsoft Entra Cloud Sync completely flips this model. The synchronization rules engine, scheduling orchestrator, and transformation calculations are shifted directly into the Microsoft Entra cloud infrastructure (SCIM-based provisioning service). The on-premises footprint is reduced to lightweight, stateless, outbound-only agents.

2. The Elephant in the Room: Migrating the 40 Custom Sync Rules

In virtually every enterprise migration, custom synchronization rules represent 80% of the risk. Azure AD Connect uses Declarative Provisioning inside the Synchronization Rules Editor (combining Inbound and Outbound rules, precedence numbers between 1 and 100, joins, and transformations across the Metaverse).

Cloud Sync replaces the MIM engine with the Microsoft Entra Attribute Mapping & Expression Builder (based on SCIM schema specifications). You cannot simply import an .xml rule export from AD Connect. Every single rule must be categorized into one of three tiers.

Phase 1: Auditing and Extracting the 40 Rules from AD Connect

Run the following PowerShell script on your Primary Azure AD Connect Server. It identifies, isolates, and exports only non-standard rules (precedence < 100 or customized rules) into a clean analysis CSV and XML backup:

# Import the ADSync Module
Import-Module ADSync

# Output directory for assessment
$exportPath = "C:ADSyncMigrationAudit"
if (-not (Test-Path $exportPath)) { New-Item -ItemType Directory -Path $exportPath | Out-Null }

Write-Host "Analyzing Active Directory Connect Synchronization Rules..." -ForegroundColor Cyan

# Fetch all sync rules that are NOT standard out-of-the-box Microsoft rules
# Standard OOB rules usually have precedence >= 100
$customRules = Get-ADSyncRule | Where-Object { 
    $_.Precedence -lt 100 -or $_.Name -like "In from AD - Custom*" -or $_.Name -like "Out to AAD - Custom*" 
}

Write-Host "Found $($customRules.Count) custom synchronization rules." -ForegroundColor Green

# Generate detailed report with attribute transformations
$report = foreach ($rule in $customRules) {
    foreach ($flow in $rule.AttributeFlowMappings) {
        [PSCustomObject]@{
            RuleName         = $rule.Name
            Precedence       = $rule.Precedence
            Direction        = $rule.Direction
            SourceObjectType = $rule.SourceObjectType
            TargetObjectType = $rule.TargetObjectType
            FlowType         = $flow.MappingType # Direct, Expression, or Constant
            SourceAttribute  = if ($flow.MappingType -eq "Expression") { $flow.Expression } else { $flow.Source -join ", " }
            TargetAttribute  = $flow.Destination
            ExecuteOnce      = $flow.ExecuteOnce
        }
    }
}

# Export to CSV for engineering triage
$report | Export-Csv -Path "$exportPathCustomRules_AttributeMatrix.csv" -NoTypeInformation
# Export complete rule definition objects for rollback/reference
$customRules | Export-Clixml -Path "$exportPathCustomRules_CompleteBackup.xml"

Write-Host "Audit completed successfully. Report exported to $exportPathCustomRules_AttributeMatrix.csv" -ForegroundColor Yellow

Phase 2: Translation Dictionary (Declarative Provisioning ➔ Cloud Sync Expressions)

Cloud Sync uses a different expression syntax than AD Connect. Below is the definitive conversion dictionary for common enterprise patterns found across custom rules:

Phase 3: The Hard Truth — What Cannot Be Directly Migrated

Out of your 40 custom rules, there will typically be 4 to 8 rules that touch unsupported scenarios in Cloud Sync. Here is how you tackle them without breaking your identity lifecycle:

3. Mastering the 20 Domains, ADFS Federation & 2 Partner Trusts

In a traditional AD Connect deployment, the AD Connect server required direct TCP/UDP line-of-sight (Kerberos, LDAP, RPC, SMB) to domain controllers across all 20 domains and both trusted partner organizations. In segmented corporate networks, this demanded hundreds of firewall holes.

Preserving ADFS Federation & ImmutableID Integrity

When a user authenticates against an AD FS federated domain in Entra ID, Entra ID passes the authentication request to AD FS. AD FS inspects the user, generates a SAML 2.0 token containing an ImmutableID claim, and returns it to Entra ID.

Entra ID verifies that the ImmutableID in the SAML token matches the sourceAnchor attribute stored on the user object in the cloud. If they do not match, the user is locked out with error AADSTS50107: Requested federation realm object does not exist or login mismatch!

The Partner Organizations (2 External Trusts) Solution

Under AD Connect, synchronizing users from two partner organizations connected via external forest trusts required either:

• ✖ Complex IPSec VPN tunnels between data centers so the central AD Connect server could perform RPC/LDAP queries.
• ✖ Permissive firewall rules exposing RPC dynamic ports (1024-65535) across corporate trust boundaries.

The Cloud Sync Revolution: You can install two Cloud Sync Agents directly inside the Partner Organization’s network! The agents only require outbound HTTPS (port 443) access to Microsoft Entra ID endpoints. They query their local Partner Domain Controllers via local LDAP, and stream the identities directly to your central Entra ID tenant over encrypted cloud WebSockets. Zero firewall ports between the partner network and your corporate network!

4. Managing the Primary & Staging (Secondary) AAD Connect Servers

You cannot simply turn on Cloud Sync for an entire forest while an Active Azure AD Connect server is synchronizing the same objects. This creates an Authority Conflict (Race Condition): AD Connect syncs at minute 00; Cloud Sync syncs at minute 02. If attribute transformations differ even slightly, the cloud attributes will bounce back and forth in an endless update loop!

5. Prerequisites & Environmental Readiness Checklist

Ensure every server designated to host a Cloud Sync Provisioning Agent meets the following strict specifications:

Automated Network Connectivity & Port Pre-Check Script

Run this script on each candidate agent server across your 20 domains to ensure no firewall or proxy intercepts SSL/TLS traffic:

# Cloud Sync Agent Outbound Connectivity Validator
$Endpoints = @(
    "login.microsoftonline.com",
    "aadcdn.msauth.net",
    "bootstrap.cloudsync.azure.com",
    "servicebus.windows.net",
    "crl3.digicert.com"
)

Write-Host "--- Checking Outbound Port 443/80 Egress for Entra Cloud Sync ---" -ForegroundColor Cyan
foreach ($endpoint in $Endpoints) {
    $port = if ($endpoint -like "crl*") { 80 } else { 443 }
    try {
        $test = Test-NetConnection -ComputerName $endpoint -Port $port -WarningAction SilentlyContinue
        if ($test.TcpTestSucceeded) {
            Write-Host "[OK] Connected to $endpoint on port $port" -ForegroundColor Green
        } else {
            Write-Host "[FAIL] Unable to connect to $endpoint on port $port" -ForegroundColor Red
        }
    } catch {
        Write-Host "[ERROR] Exception connecting to $endpoint : $_" -ForegroundColor Red
    }
}

6. Phased Step-by-Step Transformation Workflow

# On Primary AD Connect Server, stop the synchronization scheduler
Set-ADSyncScheduler -SyncCycleEnabled $false

# Verify scheduler status is Disabled
Get-ADSyncScheduler | Select-Object SyncCycleEnabled, SchedulerSuspended

# Perform a final export review to ensure no pending exports exist in the connector space
Get-ADSyncConnectorRunStatus

7. Accounts, Permissions & Directory Rights Architecture

One of the greatest security benefits of Cloud Sync is eliminating the sprawling domain administrator credentials historically required by Azure AD Connect.

Delegating Password Writeback Permissions to the gMSA

# Import Active Directory Module
Import-Module ActiveDirectory

$gMSAName = "provAgentgMSA$" # Name of the auto-generated gMSA
$TargetOU = "OU=CorporateUsers,DC=corp,DC=contoso,DC=com"

Write-Host "Granting SSPR Password Writeback permissions to $gMSAName on $TargetOU..." -ForegroundColor Cyan

# Grant Reset Password and Lockout clearing permissions
$acl = Get-Acl -Path "AD:$TargetOU"
$gMSA = New-Object System.Security.Principal.NTAccount($gMSAName)
$sid = $gMSA.Translate([System.Security.Principal.SecurityIdentifier])

# Reset Password GUID: 00299570-246d-11d0-a768-00aa006e0529
$resetPasswordGuid = New-Object Guid "00299570-246d-11d0-a768-00aa006e0529"
$rule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
    $sid,
    [System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight,
    [System.Security.AccessControl.AccessControlType]::Allow,
    $resetPasswordGuid,
    [System.DirectoryServices.ActiveDirectorySecurityInheritance]::Descendents
)
$acl.AddAccessRule($rule)
Set-Acl -Path "AD:$TargetOU" -AclObject $acl

Write-Host "Permissions successfully delegated!" -ForegroundColor Green

8. Troubleshooting, Diagnostics & Critical Error Codes

Unlike AD Connect, which required digging through the Synchronization Service Manager GUI, Cloud Sync diagnostics are accessible via Entra Provisioning Logs and local Windows Event Logs.

Agent Local Log Inspection

When diagnosing on-premises agent failures, open Event Viewer and navigate to:

Applications and Services Logs > Microsoft > Azure AD Connect Provisioning Agent > Admin

9. Conditional Access (CA) Policies & Security Architecture

Migrating your identity sync engine interacts directly with your Zero Trust perimeter and Conditional Access policies:

10. Comprehensive Pros & Cons: Feature Parity Matrix

Before committing to a complete cutover, evaluate this authoritative feature comparison between Entra Connect and Entra Cloud Sync:

11. Conclusion & Recommended Road Map

Migrating from Microsoft Entra Connect to Entra Cloud Sync across 20 domains, federated ADFS systems, and 40 custom rules is not just a tool replacement—it is a modern identity transformation that liberates your enterprise from legacy SQL-bound servers, simplifies cross-forest firewalls, and accelerates synchronization from 30 minutes down to 2 minutes.

By decomposing your 40 custom rules into SCIM expressions, maintaining ADFS sourceAnchor alignment, safely scoping out AD Connect via staging filters, and isolating your lightweight agent pools across regional subnets and partner trusts, you achieve seamless, zero-downtime identity modernization.