The Ultimate Guide to SCCM Primary Site Migration: Windows Server 2016 to Server 2022

Migrating your Microsoft Endpoint Configuration Manager (SCCM/MECM) environment can feel like an overwhelming task, especially when dealing with complex infrastructure architectures. In this post, we will walk you through a highly secure, reliable lift-and-shift methodology to migrate a co-located SCCM Primary Site Server from Windows Server 2016 to Windows Server 2022.

This guide is tailored specifically for topologies where all core application roles—including the Site Server engine, Management Point (MP), Software Update Point (SUP), and Distribution Point (DP)—are co-located on a single machine, while the database layer stays safely hosted on an external remote SQL Failover Cluster or Always On Availability Group. Because the database remains untouched, our entire focus is centred on seamlessly transitioning the application container layer.

The golden rule of co-located site migration

The destination server running Windows Server 2022 must retain the exact same NetBIOS name, Active Directory domain membership, physical installation drive letters, and Fully Qualified Domain Name (FQDN) as the original source server. Because all client-facing roles (MP, DP) are hosted here, endpoint access depends completely on maintaining this identity.

Phase 1: Pre-Migration Discovery & Content Mapping

Before taking anything offline, you must log your current site metadata and storage configurations to ensure you can replicate the exact environment on the new operating system.

Step 1.1: Log Site and Remote SQL Parameters

• Site Code & Site Name: Locate this via Administration → Site Configuration → Sites.
• Installation Directory Path: Verify the exact drive letters for all binaries (e.g., E:\Program Files\Microsoft Configuration Manager).
• SCCM Build Version: Verify your precise build version number (e.g., Version 2403) so your restoration media matches exactly.
• Remote SQL Cluster Endpoints & WSUS: Document the SQL Cluster Virtual Network Name (VNN), instance name, and port configuration. Confirm that both the core site database (CM_XYZ) and the WSUS database (SUSDB) collations are set to SQL_Latin1_General_CP1_CI_AS.

Step 1.2: Audit SQL Service Account SPNs and Compatibility

Document the Active Directory service account running the remote SQL engine instances. Run the following command to verify Kerberos registration:

setspn -L DOMAIN\SqlServiceAccount

Additionally, run a quick query in SQL Server Management Studio (SSMS) to verify database compatibility levels for CM_XYZ and SUSDB to avoid prerequisite warnings later:

SELECT name, compatibility_level FROM sys.databases WHERE name IN ('CM_XYZ', 'SUSDB');

Phase 2: Complete Source Backup Operations

Execute these steps sequentially on the original Windows Server 2016 machine to cleanly capture all data before decommissioning.

Step 2.1: Execute Native Site Backup & Staging

1. In the console, go to Administration → Site Configuration → Sites, and select Site Maintenance Tasks.
2. Edit and enable the Backup Site Server task, pointing to an external network UNC path.
3. Manually trigger the backup immediately by launching services.msc and starting the SMS_SITE_BACKUP service. Monitor via Smsbkup.log.
4. Copy the entire CD.Latest directory (typically inside C:\Program Files\Microsoft Configuration Manager\CD.Latest) to your network staging share.

Step 2.2: Copy Content Stores and Local DP Data

Use Robocopy from an elevated command prompt to stage local application source folders and the Distribution Point Content Library while preserving all NTFS permissions and shares:

robocopy "D:\AppSources" "\\NetworkStorage\Staging\AppSources" /E /COPYALL /XF SECURE /R:3 /W:5 /MT:32 /LOG:"C:\Temp\Sources_Robocopy.log"

robocopy "D:\SCCMContentLib" "\\NetworkStorage\Staging\SCCMContentLib" /E /COPYALL /R:3 /W:5 /MT:32 /LOG:"C:\Temp\ContentLib_Robocopy.log"

Step 2.3: Host Decommissioning

Shut down the old Windows Server 2016 machine completely to free up the network IP and hostname configuration. Then, log into your AD management tools and reset the server's Computer Account metadata so the new Server 2022 host can bind to the domain seamlessly.

Phase 3: Compute Host Provisioning (Server 2022)

Now, it's time to provision and configure the brand-new Windows Server 2022 environment.

Step 3.1: Establish Operating System Baseline

Install a clean instance of Windows Server 2022. Assign it the exact same computer hostname, FQDN, and IP address as the old server, and join it to the production domain. Format and map your storage volumes to perfectly mirror the previous drive setup (e.g., maintaining partitions D: and E: to prevent broken internal path references).

Step 3.2: Install Feature Roles & Prerequisites

Automate the prerequisite installations—including critical .NET 4.8 WCF HTTP Activation handles to avoid client policy request errors (HTTP 500/404)—by executing the following PowerShell script from an elevated prompt:

<#.SYNOPSIS
    Initialises Windows Server 2022 prerequisites for a co-located 
    SCCM Primary Site Server (MP/SUP/DP roles) with remote SQL.
#>
$Features = @(
    "Web-Server", "Web-WMI", "Web-Scripting-Tools", "Web-ISAPI-Ext", 
    "Web-ISAPI-Filter", "Web-Http-Redirect", "Web-Custom-Logging", 
    "Web-Log-Libraries", "Web-Request-Monitor", "Web-Basic-Auth", 
    "Web-Windows-Auth", "Web-Stat-Compression", "Web-Dyn-Compression", 
    "Web-Metabase", "BITS", "RDC", "NET-Framework-Features", 
    "NET-Framework-45-Features", "NET-Framework-Core", "NET-Http-Activation", 
    "WAS-Process-Model", "WAS-NET-Environment", "WAS-Config-APIs",
    "NET-WCF-HTTP-Activation45"
)
Write-Host "Initialising Windows Feature installation for Server 2022..." -ForegroundColor Cyan
foreach ($Feature in $Features) {
    if ((Get-WindowsFeature -Name $Feature).Installed -eq $false) {
        Write-Host "Installing feature: $Feature" -ForegroundColor Yellow
        Install-WindowsFeature -Name $Feature -IncludeManagementTools -ErrorAction SilentlyContinue | Out-Null
    } else {
        Write-Host "Feature already present: $Feature" -ForegroundColor Green
    }
}
Write-Host "Windows Feature configuration complete." -ForegroundColor Green

Next, deploy the matching baseline version of the Windows ADK and WinPE Add-on. Install SQL Server Management Studio (SSMS) or SQL connectivity tools—but do NOT install a local SQL database engine. Make sure to grant the new machine account local administrator permissions across the remote SQL cluster nodes and sysadmin privileges inside the database instance.

Step 3.3: Initialise WSUS and Re-link to Remote SUSDB

Install the required WSUS API sub-features via PowerShell:

Install-WindowsFeature -Name UpdateServices-API, UpdateServices-Services -IncludeManagementTools

Then, run the post-installation configuration utility to link the WSUS layer directly back to your persistent remote cluster database:

CD "C:\Program Files\Update Services\Tools"
wsusutil.exe postinstall SQL_INSTANCE_NAME="SQLClusterVNN.domain.local\InstanceName" CONTENT_DIR="D:\WSUSContent"

Phase 4: Content Restoration & Site Recovery Execution

Step 4.1: Repopulate App Stores & Verify Connectivity

Bring back your staged data folders using Robocopy:

robocopy "\\NetworkStorage\Staging\AppSources" "D:\AppSources" /E /COPYALL /MT:32

robocopy "\\NetworkStorage\Staging\SCCMContentLib" "D:\SCCMContentLib" /E /COPYALL /MT:32

Explicitly recreate your network shares on those paths matching the original naming conventions and access control lists. Open SSMS on the new host to confirm you have flawless database connectivity to both CM_XYZ and SUSDB on the remote cluster.

Step 4.2: Bind WSUS SSL Encryption Certificates

If your Software Update Point uses secure sockets (HTTPS), import your enterprise FQDN Web Server signing certificate into the Local Computer → Personal certificate store. Launch IIS Manager, expand to Sites → WSUS Administration, select Bindings, and map the certificate to SSL Port 8531 to prevent clients from hitting 0x80244007 errors.

Step 4.3: Run the Site Recovery Wizard

1. Copy the staged CD.Latest folder to a local temporary partition.
2. Navigate to CD.Latest\SMSSETUP\BIN\X64\, right-click Setup.exe, and select Run as Administrator.
3. Choose 'Recover a site' from the initialisation window.
4. Select 'Recover this site server using an existing backup set' and target your backup folder.
5. On the database step, choose 'Use a site database that has been manually recovered', input the FQDN/VNN or Availability Group Listener path of your remote SQL cluster, and complete the installation wizard.

Phase 5: Post-Recovery Validation Checklist

• Monitor Progress Logs: Check ConfigMgrSetup.log at the system root folder to verify zero failure states were hit.
• Re-enter Encrypted Passwords: Open the SCCM console and re-type credentials for all service accounts (Network Access Account, domain join profiles, discovery tasks), since machine key updates wipe these records.
• Confirm Local Roles & DPs: Navigate to Monitoring → System Status → Component Status and ensure MP and DP report healthy metrics.
• Validate WSUS Sync: Trigger a manual 'Synchronize Software Updates' task from the console ribbon and monitor Wsyncmgr.log to confirm the local WSUS API is mapping perfectly to the persistent cluster database.

When to call in help

Lift-and-shift SCCM migrations demand precision. A single mismatch in hostname, FQDN, drive letters or SQL connectivity can leave endpoints unable to check in or receive updates. If your team needs an experienced hand to plan the migration, validate prerequisites or standby during cutover, our Microsoft Consulting Services team can run the discovery, build a runbook and support you through go-live.

For broader endpoint modernisation projects — moving from SCCM to Intune, hardening device security or automating patch compliance — see our Modern Endpoint Management services or get in touch to discuss your environment.