With the official launch of System Center 2019 last week we can now test the migration of the final version.
https://cloudblogs.microsoft.com/windowsserver/2019/03/07/coming-soon-microsoft-system-center-2019/
New Version Policy
In the new version policy of System Center, there will be no Semi-Annual channels like Windows.
That is, you will have the 2019 version for approximately 3 years with the updates that usually occur 3 times a year.
This means that different from the first versions that were 1801 and 1807, henceforth we will no longer have that same type of nomenclature returning to the old versions model with updates (2019 UR 99).
Important: System Center Configuration Manager continues with the Semi-Annual channel
https://docs.microsoft.com/en-us/system-center/ltsc-and-sac-overview
Running the Upgrade
In the same document above, we see the support for in-place upgrade that is guaranteed until the last 2 versions.
This means that users of the 2012 R2 versions will need to first upgrade to 1801 and then to SC 2019.
Important: System Center Configuration Manager will have the different update rules depending on the chosen channel
Just as the upgrade from version 2016 to 1801 was quiet and I have already demonstrated here https://msincic.wordpress.com/2019/01/02/system-center-2019-and-windows-server-2019-upgrade-in-place/, the migration of 2019 was also quite satisfactory.
All of them only need to confirm the installation, with the exception of SCOM and VMM that you need to upgrade agents.
DPM did not upgrade because I currently use Microsoft Azure Backup which is a specialized subset for backup on Azure.
System Center Operations Manager (SCOM)
In the case of SCOM a change is now enabled by the interface in the "About", before it was necessary to do by PowerShell with the command Set-SCOMLicense .
Remember that in the case of SCOM it is necessary to authorize the upgrade of the agent to all servers shortly after installation. If it does not, communication will continue, but it will create constant warning alerts and new features can cause agents to fail.
System Center Service Manager (SCSM) and System Center Orchestrator (SCO)
Literally nothing needed to be done or changed, and so did Orchestrator.
System Center Virtual Machine Manager (SCVMM or VMM)
The VMM has already required a bit more work because it is necessary to review the accounts in the "Run-AS" that now limits local accounts and reinstall the agents.
In my case, I did the uninstall exercise to validate if just using the database would return and it worked!
