1. Why Upgrade ADFS?

ADFS 2022 brings major improvements: support for stronger ciphers, faster token issuance, HTTP/2, and better hybrid integration. If you’re running an older version (like ADFS 3.0 on Server 2012 R2 or ADFS 4.0 on Server 2016), you’ll need a migration plan – in‑place upgrades are rarely possible across major operating system versions. The safe approach is side‑by‑side migration: build a new farm, export the configuration, and cut over traffic with minimal downtime.

In this lab, we’ll simulate an existing “old” ADFS farm (ADFS 2019, which shares the same schema as 2022) and migrate to a fresh Windows Server 2022‑based ADFS farm. Even though the versions are close, the procedure is identical for upgrading from 2016 or 2012 R2.

2. Lab Setup – Two Farms Side‑by‑Side

• OLD‑ADFS01 – Our existing ADFS 2019 farm (federation service name sts.corp.lab, WID database). We’ll clone our current ADFS01 or build a new one to represent the old farm.
• NEW‑ADFS01 – A brand‑new Windows Server 2022 VM, domain‑joined, ready to become the new farm (but we’ll use a temporary federation service name sts-new.corp.lab during migration).
• SQL Server (optional) – If you want to migrate from WID to SQL as part of the upgrade, we’ll include those steps. For simplicity, we’ll stick with WID in the new farm as well, but I’ll show the database migration commands.
• All machines on the same subnet, DNS records under your control (or HOSTS files).

3. Step 1 – Document the Old Farm Configuration

On the old ADFS server, capture everything you’ll need to recreate on the new farm.

# Export relying party trusts (with claims rules and properties)
Export-AdfsRelyingPartyTrust -Name "*" -FilePath "C:\ADFS-Backup\RPTrusts.xml"

# Export claims provider trusts (e.g., partner federation)
Export-AdfsClaimsProviderTrust -Name "*" -FilePath "C:\ADFS-Backup\CPTrusts.xml"

# Export access control policies
Get-AdfsAccessControlPolicy | Export-CliXml "C:\ADFS-Backup\Policies.xml"

# Backup token-signing and decryption certificates (private key needed)
# We'll manually export them from the certificate store.
# Also note the SSL certificate thumbprint used for the farm.

Export the token‑signing and token‑decryption certificates (with private keys, if they are software‑based) from the Local Machine certificate store. You’ll need to import them on the new farm so that existing relying parties continue to trust the same signing certificate. If you’re doing a rolling renewal, you can use new certificates, but that requires updating all relying parties – we’ll avoid that for now.

4. Step 2 – Build the New ADFS Server (NEW‑ADFS01)

1. Deploy a fresh Windows Server 2022 VM, join it to corp.lab.
2. Install the ADFS role:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

3. Request (or import) an SSL certificate for the temporary federation service name: sts-new.corp.lab. Use your internal CA.
4. Import the old token‑signing and decryption certificates (with private keys) into the Local Machine → Personal store.

5. Step 3 – Create the New Farm (Temporary Name)

Configure the first federation server in a new farm using the temporary service name. This avoids clashing with the live production name.

# Create new farm with temporary name
# Use the gMSA if desired, or a standard domain account
$gMSA = Get-ADServiceAccount -Identity ADFSSvc
Install-AdfsFarm `
    -CertificateThumbprint "thumbprint_of_sts-new_cert" `
    -FederationServiceName "sts-new.corp.lab" `
    -GroupServiceAccountIdentifier "CORP\ADFSSvc$" `
    -OverwriteConfiguration:$true `
    -WIDFarm

Verify the new farm is running by visiting https://sts-new.corp.lab/adfs/ls/idpinitiatedsignon.aspx.

6. Step 4 – Import Old Configuration to New Farm

Now import the relying party trusts, claims provider trusts, and policies that we exported from the old farm.

# Import relying parties (they will reference the old signing certificate, which we imported)
Import-AdfsRelyingPartyTrust -FilePath "C:\ADFS-Backup\RPTrusts.xml"

# Import claims provider trusts
Import-AdfsClaimsProviderTrust -FilePath "C:\ADFS-Backup\CPTrusts.xml"

# Import custom access control policies (if any)
Import-Clixml "C:\ADFS-Backup\Policies.xml" | % { Add-AdfsAccessControlPolicy -Name $_.Name -Conditions $_.Conditions -Action $_.Action }

After import, review the trust properties. The certificates should match because we imported the old ones. If you want to use new certificates, update the token‑signing certificate thumbnails in each relying party trust or use PowerShell to rotate them.

7. Step 5 – Database Migration (WID to SQL – Optional)

If you plan to move from WID to SQL Server, now is the perfect time. The process is straightforward:

1. Install SQL Server on a dedicated server (or use an existing one).
2. Export the existing WID configuration:

Export-AdfsDeploymentSQLScript -DestinationFolder "C:\ADFS-SQL-Migration"

3. Run the generated SQL scripts on the SQL Server to create the databases (AdfsConfiguration, AdfsArtifactStore).
4. On the new ADFS server, use Set-AdfsFarmInformation to point to the SQL connection string.

For our lab, we’ll stay with WID, but the migration ability is there when you need enterprise scale.

8. Step 6 – Cutover with Zero Downtime

Both farms are now running: old (sts.corp.lab) and new (sts-new.corp.lab). The final step is to redirect all traffic to the new farm. Because ADFS uses the federation service name in the URL, we simply update the DNS A record for sts.corp.lab to point to the IP address of NEW‑ADFS01.

However, the new farm’s SSL certificate currently only contains sts-new.corp.lab. Before changing DNS, we must replace that certificate with one that has sts.corp.lab (the production name) as the subject. You can either issue a new certificate or add the new host name to the existing one.

1. On NEW‑ADFS01, request a new certificate with Subject Alternative Name = sts.corp.lab (or edit the existing one if your CA allows).
2. Update the ADFS farm SSL certificate:

Set-AdfsSslCertificate -Thumbprint "new_cert_thumbprint"

3. Now update the DNS record for sts.corp.lab to point to the new server’s IP. Within seconds, all authentication requests will hit the new farm.
4. Monitor the ADFS event logs on the new server for incoming requests. Once you see traffic, the cutover is complete.

9. Step 7 – Decommission the Old Farm

After a few days of verifying everything works perfectly, it’s time to retire the old ADFS servers.

1. On the old ADFS01, remove the server from the farm:

# If it was a single-node farm, uninstall the role
Uninstall-WindowsFeature ADFS-Federation

2. Clean up any DNS entries for the temporary name sts-new.corp.lab (no longer needed).
3. Optionally revoke the old SSL certificate.

Your migration is complete – a fully functional ADFS 2022 farm with all existing trusts and policies intact.

10. Understanding the Migration Strategy

The key to a smooth migration is keeping the token‑signing certificate the same. If we changed it, every relying party would need to update its trust – a coordination nightmare. By importing the old certificates, the new farm can sign tokens exactly as the old one did, making the transition invisible to applications.

The temporary federation service name allows us to build and test the new farm without any conflict. DNS cutover is near‑instant, and because ADFS tokens are short‑lived (typically 1 hour), users experience at most one re‑authentication. Web Application Proxies will automatically reconnect because they resolve the federation service name and trust the same certificates.

11. Troubleshooting Common Pitfalls

• Imported relying parties show certificate errors? – Ensure you imported the old token‑signing certificate into the new server’s personal store with private key. Without it, ADFS cannot sign tokens and will throw MSIS errors.
• DNS update not taking effect immediately? – Flush client DNS caches (ipconfig /flushdns). Some applications cache federation metadata – wait up to an hour or restart the application pool.
• WAP proxy loses connectivity? – The Web Application Proxy automatically reconnects because it resolves the federation service name. If it doesn’t, re‑run the WAP configuration wizard pointing to the same sts.corp.lab (now the new farm).
• SQL migration script fails? – Check that the SQL Server has the correct permissions and that the ADFS service account has db_owner on the new databases.

12. Next Steps 🚀

You’ve just mastered a real‑world ADFS migration. Now let’s ensure your new farm stays healthy and secure.

👉 Part 9 – Monitoring, Hardening & Disaster Recovery
We’ll set up auditing, enforce best‑practice security settings, configure high‑availability with a load balancer, and prepare a rapid recovery plan – so your federated identity platform is bulletproof.