According to unnamed sources in some reliable publications, Microsoft Systems Center Operations Manager (OpsMgr aka SCOM) is going to the cloud. It's called Project Aquila (at least internally). Finally. I've been wanting this for years. Of course Microsoft's official stance has been that System Center remains their "on-prem" (aka private cloud, aka public cloud but not managed) solution, but it was clear they were heavily pushing Azure Monitor (previously known as Log Analytics and OMS). However, I don't think adoption has been great as a forklift replacement. There are parts of Azure Monitor I like, but it doesn't replace OpsMgr. They've also reimagined the product multiple times, changed its name multiple times, refactored the UX multiple times, etc. You just don't do that with a successful new product. And if you've used both Azure Monitor and OpsMgr, it's pretty clear why.
Both have steep learning curves, so let's get that out of the way. One may seem easier to you than the other, but it's only because you've dedicated yourself to learning it. That isn't a problem. So I won't comment on Azure Monitor's learning curve except that they didn't make anything easier to help ease transition.
The problem, to me, is more the approach to monitoring. Azure Monitor is DevOps focused, which is a good thing, but in my opinion it neglects some basic features as a result of this focus. For example, there is very little in the way of deploying a baseline of monitors without custom scripts and lots of upkeep. There is no concept of automatic discovery which is the best part of OpsMgr. If you have a ton of DevOps labor resources, this is less of a problem, but it's also something OpsMgr does automatically and natively. If you want to create a monitor that touches everything of a defined class across all entities, you can do it easily -- that's a core functionality in OpsMgr. You can then set all the parameters and thresholds across the management group through overrides. You do it once, and it is continuously pushed out to new resources automatically. You can't easily do this in Azure Monitor without a lot of upkeep and auditing. And if your monitoring parameters change, you have to manually (or by script) copy it across the organization.
On the other hand, Azure Monitor makes it insanely easy for anybody on any team or any scope to create custom monitoring to exactly suit their needs. OpsMgr severely lacks this. Even with the wizard driven monitors (which give you only a fraction of what is possible to monitor), scoping it to subgroups of classes is not trivial. And creating new classes inside the management console is impossible. The only way to get the full functionality out of it is to create a management pack, using Visual Studio Authoring Extensions or a third party like Silect. It's not a great experience at all, debugging is very difficult, and documentation is lacking.
Visualizations and analytic intelligence is vastly superior in Azure Monitor. Not a surprise since it's using the vast log collection to get insights. And any new intelligence MS creates is immediately available and can retroactively provide insight. It's the most impressive part of Azure Monitor. You can see how this was/is a desperate need for OpsMgr because SquaredUp built their business on top of building a better OpsMgr UI on the web which MS has neglected. They've since moved onto adding visualizations to other products, but for years their key focus was only OpsMgr.
The key difference in approach is that Azure Monitor works exclusively on log feeds. There is no probe-based monitoring. You can still simulate probes in some ways, such as heartbeating, by alerting on a lack of a periodic log entry being treated like a missed heartbeat, but fundamentally, it's not the same. If you actually need a probe, you have to make it some other way and feed the output of that into the log stream. In contrast, OpsMgr natively supports probe based monitoring, both from the agent or agentless. Of course, on the flip side, while OpsMgr can react to logs, it doesn't aggregate logs like how Azure Monitor does with Log Analytics (we'll just ignore ACS since it's not that great and was always separate from OpsMgr anyway). So root cause analysis of issues can be more difficult with OpsMgr.
As you can see, they each do something different well. My personal preference, tainted by years of working with SCOM, is that I prefer SCOM's shortcomings to Azure Monitor's shortcomings. I feel what Azure Monitor lacks is easily filled in by other products, but the reverse isn't necessarily true. But, all that said, why should we even have to choose? MS makes both products, they can give us the features of both!
Aquila could be what changes this. First of all, the rumors are that they are refactoring SCOM into containers. This gives really terrific portability and seamless updating, making the product ready to run on the modern cloud. Powered by Azure SQL (or replicated to/from MS-SQL) and with multiple regions and datacenters, SCOM will have HA options like it's never had before, both in the cloud and on-prem (or self-managed VMs). Because of how easy it is to update containers, whether the container runs inside MS managed instances or if you run it on-prem or in your own cloud VM, there will be feature parity and the product will stay up-to-date. Secondly, this brings Azure Monitor and OpsMgr closer together for integration and rapid feature enhancement. The best of both worlds would be having the ability to, from a single pane of glass, have all your SCOM management packs, recommended and tweaked baseline monitoring, organization standards, and so forth deployed, but then on top of that have the log consumption, analytics, visualizations, and ad hoc log alerting of Azure Monitoring. Further, since we are again talking about containers now, OpsMgr could run in any cloud, anywhere. You can get the same monitoring experience in AWS, GCS, and so on. So you now have a bridge connecting your cloud monitoring. All of it rolled up to SCOM + Azure Monitor. That would truly set the entire MS monitoring picture above and beyond the competition by leaps and bounds. And of course finally we can't ignore it would give a better pathway for ACS migration to Log Analytics, which actually is a part of SCOM that I think is pretty terrible but it seems there are a lot of organizations that haven't made the migration yet.
So, in conclusion, I'm hoping Aquila has great success, this could be a game changer.