SCOM Managed Instance Retirement: What It Means and How to Migrate Before September 2026

TL;DR:

• Retirement date: September 30, 2026
• What happens after: Customers lose access to the service; existing SCOM MI instances must be decommissioned
• No extension or grace period has been announced
• Recommended paths: Migrate to on-premises System Center Operations Manager (SCOM 2025), or to Azure Monitor

Microsoft has confirmed that Azure Monitor SCOM Managed Instance (SCOM MI) will be retired on September 30, 2026. After that date, customers will no longer be able to access the service, and existing SCOM MI instances will need to be decommissioned. No extension, no grace period. If you're still running on it, you need a plan before then, not after. So if your organization relies on SCOM MI for hybrid or on-premises monitoring, now is the time to plan your next move.

Microsoft recommends migrating either to a self-managed on-premises deployment of System Center Operations Manager, or to Azure Monitor for cloud-native monitoring. This series of articles guides you through what the retirement means, why it's happening, and how to choose and execute the right migration path before the deadline.

What’s next for SCOM MI Customers?

If you deployed Azure Monitor SCOM Managed Instance (SCOM MI) over the last couple of years, you did it for a reason: keep the monitoring investment you already had, but get rid of the operational overhead of running SCOM yourself. No more patching management servers, no more babysitting the Operations Manager databases, no more high-availability headaches.

Sadly, SCOM MI didn’t remove the operational overhead of managing and troubleshooting agents, management packs or alerts - the real challenges of SCOM - and the lack of uptake has led to its demise.

Microsoft's own retirement guidance is blunt about the alternatives:

• If your goal is monitoring on-premises workloads, move to Operations Manager on-premises.
• If you're monitoring cloud-native workloads, move to Azure Monitor.

SCOM MI was always a bridge product - a way to run SCOM "in Azure" without giving up your existing management packs while you figured out your longer-term cloud strategy. Microsoft is now closing that bridge and asking everyone to pick a side.

Is SCOM Dead? (Addressing the Confusion)

The end of SCOM MI has created some noise in the community - you'll see people online arguing "SCOM is dead" as a result. It isn't, and it's worth being precise about the difference.

SCOM MI retiring and System Center Operations Manager retiring are two different things. Microsoft released SCOM 2025 with mainstream support running through the end of the decade, and shipped a meaningful update rollup (UR1) barely a year later. We'll go deeper on what's actually in that release in an upcoming article. The current retirement is specific to the managed cloud instance - not the underlying product line.

The Migration Options

Once SCOM MI is off the table, there are genuinely two paths, and most organizations are choosing based on one question: where do your workloads actually live?

• Option A - Go fully cloud-native with Azure Monitor. This makes sense if your estate is mostly Azure-resident already and you're willing to re-platform your monitoring logic - management packs don't carry over. Azure Monitor also has some functional limitations that lead many teams toward additional monitoring, observability, or dashboarding tools alongside it.
  
• Option B - Redeploy Operations Manager on-premises (or in Azure VMs) on SCOM 2025. This makes sense if you have a large management pack estate, custom monitoring logic, hybrid or on-prem-heavy infrastructure, or limited appetite for a full monitoring re-platform on a forced 2026 deadline.
  
• Option C - Keep SCOM on-premises, and add a dashboarding/visualization layer on top. SquaredUp Dashboard Server for visualizing on-premises SCOM, VMWare, SolarWinds, Splunk and SquaredUp Cloud for visualizing Cloud Services, all pulled together into a single pane of glass for stakeholders across your enterprise. See a recent webinar for more details.

Tools like SquaredUp Dashboard Server exist specifically to sit alongside an on-premises SCOM 2025 deployment (or other sources like VMware, SolarWinds, or Splunk) and present the data in a single pane of glass, with SquaredUp Cloud extending that view to cloud services. This is a genuine third path for organizations that want to keep their existing SCOM investment but weren't happy with the SCOM console itself - separately from the MI retirement question.

In our experience, organizations with mature SCOM deployments tend to lean toward B or C. These organizations have years of tuning, custom management packs, and integration work behind them that don't have to be thrown away just because a managed cloud wrapper around SCOM is being retired.

Throwing that away to chase a retiring managed service isn't a upgrade, it's a step backward. Redeploying on SCOM 2025 keeps everything that already works with SquaredUp Dashboard Server providing the visualizations that the SCOM console never had and SquaredUp Cloud enabling organisations to go “beyond SCOM” and visualize Cloud services in the same pane of glass.

The gap that redeployment doesn't solve on its own

Here's the honest part: going back to on-premises SCOM brings back the thing SCOM MI was hiding from you - the SCOM console itself, and the alert-fatigue problem that comes with it. Hundreds of alerts, no business context, no way to tell a war-room-worthy incident from noise.

That's a separate problem from the MI retirement, but it's one many teams end up solving at the same time, since a migration is a natural point to also fix a visualization or alert-triage gap that's existed for years. We'll cover this in more detail in an upcoming article..

What to do now

1. Confirm your SCOM MI end date and inventory what's running on it. This includes management groups, agents, management packs, dashboards, integrations.

2. Decide: Azure Monitor or on-prem SCOM 2025? This should be based on where your workloads actually sit, not where they might sit someday.

3. If you're redeploying on-prem, don't just lift-and-shift your old overrides. Years of undocumented tuning is the single biggest source of migration pain - we cover how to deal with that cleanly in a later post.

4. Plan around the SCOM 2025 UR1 release, not the original SCOM 2025 RTM. UR1 closes several gaps that made some teams hesitant to commit. We'll get to that once we've dealt with the "is SCOM even still viable" question head-on.

You have until September 30, 2026. That sounds like a long runway. For anything involving a management-pack inventory, override clean-up, and a production cutover, it isn't.