We recently completed a successful upgrade of our SCCM environment, which was originally running on Windows Server 2016 with SQL installed on the same server as the SCCM application. If you’re planning to upgrade your SCCM infrastructure and separate the SQL component, this might be exactly what you need.

I’ll give you the quick steps first, but if you want to avoid some pitfalls, definitely read the full story afterward.

Quick Steps – SCCM Upgrade & SQL Separation

This is what worked in our environment:

1. Prep your new SQL Server – We used Windows Server 2022 and SQL Server 2022.
2. Backup everything – Take backups of your SCCM DBs and snapshot your SCCM server.
3. Upgrade SQL (if needed) – If your current SCCM server isn’t already running SQL 2022, do an in-place upgrade first. (We upgraded from SQL 2016 SP2 to 2022 SP3.)
4. Validate SCCM functionality – After the SQL upgrade, confirm SCCM is still working properly.
5. Get ready to split SQL from SCCM.
6. Backup SCCM DBs again.
7. Stop SQL Services on the SCCM server.
8. Restore DBs on your new SQL Server. Our DBA also reindexed and set the compatibility level to 160.
9. Run setup.exe /recover from the SCCM setup directory.
10. During recovery, select the new SQL Server and the restored DB.
11. After recovery completes, verify everything is functioning.
12. Check site communication, DPs, and other components.
13. Upgrade the OS – We upgraded the SCCM server OS from 2016 to 2022.
14. Reconfigure WSUS post-upgrade (no need to uninstall it).
15. Use this Microsoft link to follow any post-upgrade steps:
    Post-Upgrade Tasks
16. Finally, run setup.exe again from the SCCM installer folder and select Repair.

Bonus – Migrating WSUS from WID to SQL

If you’re still using WID for WSUS and want to move to SQL, here’s what we did:

1. Back up the SUSDB.
2. Restore and reindex it on the new SQL Server.
3. Update registry settings on the SCCM server using this guide:
   Migrate WSUS from WID to SQL

The Story Behind the Scenes

This upgrade was truly a team effort. I won’t take all the credit! Especially since the heavy lifting around SQL was handled by someone way better at that than me. Huge shoutout to Jeffrey B. for leading the SQL work, and to Gabe and Fred from our SCCM team for testing and tackling early errors. Steve helped prep the servers, and Doug T. was key in escalating our issues to Microsoft.

So here’s what happened…

Our old SCCM setup had SQL and SCCM on the same server, which we knew wasn’t ideal. There was little documentation from the past, so we decided it was time to clean things up and follow best practices. I was tasked with leading the upgrade and was already familiar with previous migrations, which helped. Luckily, this time we had only one site code, so the scope was manageable.

Two weeks before our cutover, we reached out to Microsoft to validate our plan. They gave us the green light. Spoiler alert: things didn’t go as expected.

Our original idea was to bring up a second SCCM App server and have it recover to the original DB while keeping both SCCM servers in play. Do not do this. It won’t work.

We quickly found out that you can only have one primary site, and recovery must use the same FQDN as the original SCCM server. Thankfully, Microsoft routed our ticket to a real SCCM expert who clarified the correct recovery approach.

When in doubt, it’s always smart to get a second opinion from a different engineer or tech. Every environment is a little different, and not all support engineers see things the same way. We also recommend leaning on multiple sources—Microsoft Docs, community forums, and tech peers—to validate your plan. You never know how your ticket will be routed, and sometimes it takes fresh eyes to spot what’s missing.

Final Thoughts

If you’re tackling a similar SCCM upgrade, I hope this helps you avoid some of the trial and error we went through. Stick to the recovery process using the same server name, plan your backups, and involve your DBA early.

Since completing the upgrade, SCCM has been noticeably faster and more responsive, we’re calling it a win. Huge team effort all around, and the performance boost is the cherry on top.

One thing to call out: we weren’t able to remove SSRS (Reporting Services) from the SCCM server. It’s still installed locally. We reached out to Microsoft but couldn’t get a clear answer on whether or how it could be safely removed. If you’ve successfully separated SSRS from your SCCM environment, definitely let us know, would love to learn how you did it.