There is a lot to unpack with your question.
Let’s start with your most recent reply about doing a side-by-side. When objects are migrated, most times, they get a brand new GUID. That means if you have references in your management packs to specific objects, then those relationships would be lost. So, a side-by-side might be problematic for you. I guess this approach would depend on how many EAs you have and how complicated are they? It’s entirely realistic to do a side-by-side migration, but it’s tedious.
Add new 2019 Management Servers to your existing Management Group
As for your SCOM 2016 management group running on Server 2012 R2 (I’m assuming R2 because it scares me if you’re running 2012).
I “believe” you could:
- Stand up a couple of new 2019 VMs.
- Add them to your 2016 SCOM management group (as 2016 Management Servers).
- Phase-out your 2016 management servers (that are running on server 2012R2).
- Once complete, upgrade your management group to SCOM 2019.
Upgrading to 2019
Keep in mind that when you upgrade your 2016 SCOM management group to 2019 SCOM, you will not be able to monitor Windows 2012 or Windows 2012 R2.
The bane of Linux management is the certificates. When you install new management servers, you will need to create a certificate mesh. You can do a lot of that work from within SCOM and maintain monitoring. It’s annoying and time-consuming, but definitely possible. When you phase out the 2016 management servers that exist on Windows 2012, you will need to remove their certificate. In other words, get familiar with the process because you are going to be this a lot.
Here are some links to some blog posts that should help:
Monitoring UNIX/Linux with OpsMgr 2016
Upgrade from SCOM 2016 to SCOM 2019 Checklist
Dual-Home UNIX/Linux Agent (Multi-Home)
How to Remove the Management Server Role
Let me know if this helps (or doesn’t help) and how you’re getting along.