Forum Discussion

GabeCz's avatar
GabeCz
Copper Contributor
Jun 05, 2026

Moving from Windows Server 2022 to 2025

And by moving I mean stand up a completely fresh Windows Server 2025 as the old server was patched for one too many times. (painfully slow and stuffy)

What I figured out so far, is to

  • install Windows Server 2025, and the exact same SQL Server 1:1 to the build #
  • install ODBC v18
  • update current MECM to the latest and its OS (update other Microsoft products with windows update)
  • go to sites / maintenance tasks and do an export
  • robocopy the "software" folder as is

Now next would be to shut down old MECM server, rename new to the old's hostname, and start the "recover site"

What my concern is as always "What if" can I at this point or once I set up the new MECM up and running go back by shutting down this new server, and powering on the old (leave and rejoin domain for trust) and go back to business as usual?
That if anything goes sideways, or things won't get better. By that i mean speeding up things which is the main reason of the 'move' which now I do not wish to troubleshoot. Our environment, database size is 7.9 Gb, which is far from being big. The reason must be the update over upgrade over update over 15 years or more no and never brand new OS.

I can take care of the "how to" I know exactly how to recover a site 'on paper'. I just want to know there's no such thing as point of no return. (when not making a single change in the Db/console)

I also understand I should not make any changes in the Db (console) while testing, which is no problem at all. All we use MECM for is staging computers. Nothing else really. Like nothing else at all. PXE. The end.

Thanks for the inputs.

 

(I hope I picked the right tags)

CM2012
MECM
MECM Migration

1 Reply

  • mertefekanlikilic's avatar
    mertefekanlikilic
    MCT
    Jun 24, 2026

    Hi GabeCz​ 

    Your recovery plan is generally sound and I don't see any major issues with it.

    The only thing I would challenge is the assumption that the old OS is the root cause of the performance issue. A 7.9 GB ConfigMgr database is very small, so I would normally investigate SQL performance, disk latency, inbox processing and provider performance before assuming the repeated upgrade path is responsible.

    Regarding rollback, there isn't really a hard point of no return as long as you have good backups of both the site database and the original server. However, once the recovered site is online and actively processing data, rolling back becomes increasingly complicated.

    I would strongly recommend taking:

    • A ConfigMgr site backup
    • A SQL backup
    • A VM snapshot/full backup of the existing site server

    before beginning the recovery.

    Also make sure both servers are never online simultaneously with the same site identity.

    If this is a standalone site used primarily for OSD/PXE, the migration itself should be relatively straightforward.