System Center to Azure Monitor, Arc and Intune Transition
IT Partner moves a System Center estate onto Azure-native management as one planned transition rather than four disconnected projects: Operations Manager (SCOM) to Azure Monitor — VM insights, data collection rules, alert rules, action groups and workbooks, delivered to on-premises servers through Azure Arc — with a parity map that states, monitor by monitor, what Azure Monitor replaces and what it does not; Configuration Manager to Intune co-management, switching workloads collection by collection until the site keeps only the roles you decide to keep; Data Protection Manager to Azure Backup through Microsoft Azure Backup Server or the MARS agent; and Virtual Machine Manager to Azure Arc-enabled SCVMM, with Azure Local or a Hyper-V-to-Azure migration written up as the alternatives they are. Each stream runs in parallel with the System Center component it replaces, cuts over in waves, and ends with a decommission checklist you sign before anything is switched off. A typical estate runs about 6 weeks. Pricing is quoted per estate, from $6,500, because management-pack count, alert volume, server count, application catalog and protection-group inventory drive the effort — not a seat count. Three boundaries up front: Microsoft's meters — Log Analytics ingestion, alert rules, Arc-attached services, Azure Backup storage — are billed by Microsoft to your subscription and are not part of our fee; in-place upgrades to System Center 2025 are quoted separately when you decide to keep a component; and the Intune baseline itself, Microsoft Sentinel and ongoing monitoring operations are separate services linked below. If you run Azure Monitor SCOM Managed Instance, Microsoft retires it on 30 September 2026 with no extension, and the plan starts from that date.
What this engagement is
System Center estates reach a decision point on a calendar, not on a whim. The renewal for System Center licensing arrives; System Center 2025 has been generally available since November 2024, so the renewal is also an upgrade decision; Azure Monitor SCOM Managed Instance — the cloud-hosted SCOM Microsoft sold as the modern option — is no longer in support and is retired on 30 September 2026, per Microsoft's Azure Monitor documentation, after which the service is not accessible; System Center 2016 leaves support on 11 January 2027 and the Windows Server 2016 hosts many management servers still run on leave support one day later, on 12 January 2027, per Microsoft's product lifecycle; and Configuration Manager moves to an annual release cadence with version 2609 in September 2026, with Microsoft stating that Intune is where new device-management innovation goes. Put together, that is a renewal at which the honest question is not "which version" but "which of these components still earns its place". This service answers that question per component and then executes the answer. It does not editorialize: System Center Operations Manager 2025 is supported into the 2030s under Microsoft's fixed lifecycle, and keeping it for the management packs Azure Monitor cannot replace is a legitimate outcome that the parity map will state plainly when it is true. The Operations Manager stream is the one most often underestimated, because Azure Monitor is not SCOM with a new console. A management pack bundles discovery, data collection, health models and alerts into one workflow; Azure Monitor separates them — data collection rules (DCRs) decide what the Azure Monitor Agent collects from a server, alert rules evaluate that data, action groups route the result, and workbooks visualize it. Microsoft states that no tool converts management packs to Azure Monitor, so we do not pretend one exists. Instead we start from your alert history rather than your management-pack list: the monitors and rules that actually fired in the lookback window, ranked by volume and by whether anyone acted on them, become the parity map — each mapped to a VM insights signal, a DCR-collected performance counter or event with a log-search alert, a metric alert, or a workbook; retained in SCOM where the scenario has no equivalent (health-model rollups, distributed-application views, synthetic transactions, and some application-specific packs); or retired as noise with the owner's agreement. Microsoft has published automation that analyzes management packs and generates draft DCRs and alert-rule templates; we use it as a starting point and treat its output as a draft to be reviewed, never as the map. Delivery is through Azure Arc: the Connected Machine agent goes on every in-scope server that is not already connected, the Azure Monitor Agent and DCRs are assigned through Azure Policy, VM insights is enabled, and Azure Monitor runs beside SCOM for an agreed parallel window so the two can be compared on the same conditions before SCOM agents come off. If you are on SCOM Managed Instance, the alert history and management-pack exports have to be taken before the retirement date, and the plan is sequenced around that. The Configuration Manager stream is a workload move, not a rip-out. Co-management keeps the Configuration Manager client on the device and enrolls the device in Intune, then lets each workload — compliance policies, device configuration, endpoint protection, resource access, Office Click-to-Run apps, Windows Update policies and client apps — be switched to Intune for a pilot collection, proved, and switched for production. Microsoft's prerequisites are firm: a supported Configuration Manager current branch, devices that are Microsoft Entra hybrid joined or Entra joined (Entra-registered devices are not supported), and Intune plus Microsoft Entra ID P1 licensing for the devices in scope. This service assumes an Intune tenant with a working Windows baseline already exists — built by our Microsoft Intune Initial Setup for Windows Device Management or by you — and moves the workloads onto it in the order that fails safest: compliance and Windows Update policies first, endpoint protection and device configuration next, applications last, because Win32 applications have to be repackaged for Intune and that is where most catalogs stall. Operating-system deployment has no Intune equivalent; its cloud-native replacement is Windows Autopilot, delivered separately through Windows Autopilot Initial Setup. Servers that Configuration Manager patched move to Azure Update Manager through Arc. What remains of the site at the end — nothing, an OSD-only role, or a co-managed estate for years — is your decision, and co-managing indefinitely is a legitimate end state that Microsoft supports; we design for the one you choose. The backup and virtualization streams are smaller and more mechanical, with one honest constraint each. Data Protection Manager has no upgrade path to Microsoft Azure Backup Server: MABS is a separate installation that inherits DPM's workload protection minus tape and System Center integration, so protection groups are rebuilt on MABS (or, for file, folder and system-state protection, on the MARS agent backing up directly to a Recovery Services vault), and the DPM server is kept, read-only in practice, until its existing recovery points age out of retention. Virtual Machine Manager has a cleaner story: Azure Arc-enabled SCVMM connects a VMM 2019, 2022 or 2025 management server to Azure through the Arc resource bridge, so the VMs it manages appear in the Azure portal, get the Connected Machine agent at scale, and inherit Azure Policy, Update Manager and Defender for Cloud without the fabric changing. Replacing the fabric itself with Azure Local and its Arc VM management is a hardware and platform project, and moving the VMs to Azure is a migration — both are written into the disposition as options, not folded into this scope. Orchestrator runbooks and Service Manager are inventoried and dispositioned (Azure Automation or Logic Apps for the former; there is no Azure successor to Service Manager, so an ITSM decision is yours), and their conversion is quoted separately. Who this is for: mid-size and enterprise IT operations teams with a System Center estate at renewal — tens to hundreds of monitored servers, one or more Configuration Manager sites, a DPM or VMM footprint — who want the transition planned as one program and executed by people who run Azure Monitor and Intune every day. Who it is not for: a ten-server shop with no System Center, which wants the Azure Arc implementation and Azure Resource Monitoring and Maintenance instead.
Which one applies to you
Every System Center component in your estate gets one of these dispositions in the parity map. The first four columns are what this service delivers; Orchestrator and Service Manager are inventoried and dispositioned here and converted or replaced as separately scoped work.
| Operations Manager → Azure Monitor | Configuration Manager → Intune co-management | Data Protection Manager → Azure Backup | Virtual Machine Manager → Azure Arc | |
|---|---|---|---|---|
| What moves | Server health, performance and event monitoring and the alerts that matter — mapped from alert history, not from the management-pack list. | Compliance, device configuration, endpoint protection, resource access, Office apps, Windows Update policies and client apps, switched per collection; servers' patching to Azure Update Manager. | Protection groups rebuilt on Microsoft Azure Backup Server (MABS) or the MARS agent, with retention designed to match or improve on DPM's. | VMM-managed VMs surfaced in Azure through Arc-enabled SCVMM: lifecycle operations, inventory, at-scale agent install, policy, patching and Defender coverage. |
| Azure-side tooling | Azure Arc Connected Machine agent, Azure Monitor Agent, data collection rules, VM insights, metric and log-search alert rules, action groups, alert processing rules, workbooks, Log Analytics. | Intune (with the baseline already in place), co-management settings and workload sliders, Intune Win32 app packaging for a pilot set, Windows Update for Business or Windows Autopatch, Azure Update Manager for Arc-enabled servers. | MABS V4 on a supported Windows Server host or the MARS agent; a Recovery Services vault; Azure Backup policies; Azure VM backup for workloads already in Azure. | Azure Arc resource bridge, Arc-enabled SCVMM (VMM 2019, 2022 and 2025 per Microsoft's support matrix), Connected Machine agent, Azure Policy, Update Manager. |
| What has no equivalent | Health-model rollups, distributed-application views, synthetic transactions and some application-specific management packs. These are retained in SCOM 2025 (upgrade quoted separately) or retired with the owner's sign-off — the map says which. | Operating-system deployment and task sequences (Autopilot is the cloud-native replacement, scoped separately); some legacy settings that Intune does not expose; catalogs of Win32 apps beyond the pilot set are repackaged as separately quoted work. | Tape, and System Center integration; DPM's existing recovery points do not transfer — DPM is retained until they age out of retention. | Azure Local VMs are not supported by Arc-enabled SCVMM; replacing the Hyper-V fabric with Azure Local is a platform project outside this scope. |
| Our role | We deliver this end to end — parity map, Azure Monitor build, parallel run, cutover, SCOM agent removal, decommission checklist. | We deliver the co-management enablement, the workload switches and the app-catalog disposition; the Intune baseline and full device onboarding are the separate Intune services. | We deliver the design, the vault, the rebuilt protection groups, the test restores and the DPM retention-tail plan. | We deliver the Arc-enabled SCVMM connection and the VM onboarding; Azure Local and VM migrations are dispositioned and scoped separately. |
The disposition is made per component and per management pack, collection or protection group from your own inventory and alert history — not from a preference for the column we happen to sell. Keeping SCOM 2025 for the packs Azure Monitor cannot replace is an outcome we will write down when it is the right one.
Success criteria
What you receive
How the work unfolds
Confirm scope, stakeholders, the renewal date and any hard date — SCOM Managed Instance retirement, Windows Server 2016 hosts — driving the plan. Inventory every System Center component, host and version; export management packs, overrides and 30 to 90 days of alert history from SCOM; collections, workloads, applications and task sequences from Configuration Manager; protection groups and retention from DPM; fabric and VM inventory from VMM. Confirm the licensing basis for Intune and Entra ID P1 and the Azure subscription the transition lands in.
Build the monitoring parity map from alert history with the application owners; design the Log Analytics workspace, data collection rules, alert rules and routing; agree the co-management workload order, pilot collection and application-catalog disposition; design backup retention and the MABS or MARS split; disposition VMM, Orchestrator and Service Manager. Deliver the Microsoft meter cost model. You approve the decision record before anything is built.
Onboard in-scope servers to Azure Arc or reuse the existing Arc estate; create the workspace, data collection rules and Azure Policy assignments; deploy the Azure Monitor Agent and enable VM insights; enable co-management and auto-enroll the pilot collection; stand up MABS or the MARS agent and the Recovery Services vault; connect VMM through the Arc resource bridge. SCOM keeps running throughout.
Create alert rules, action groups, alert processing rules and workbooks per the parity map; start the parallel-run window and reconcile Azure Monitor against SCOM daily. Switch every agreed workload for the pilot collection and validate from Intune; repackage and deploy the pilot application set; rebuild the first protection groups and run test restores; onboard the first VMM-managed VMs.
Switch workloads for production collections in the agreed order; cut alert routing over to Azure Monitor action groups; rebuild the remaining protection groups and confirm restores; complete Arc-enabled SCVMM onboarding; remove SCOM agents from servers whose parity-map lines are confirmed, wave by wave, with rollback criteria stated for each.
Deliver the decommission checklists for the SCOM management group, Configuration Manager roles, DPM and VMM with their preconditions and the DPM retention-tail date; hand over the as-built documentation, runbooks, decision record and open items in a session with your operations team; close on your approval. Decommission steps run only on your written approval and can be scheduled inside or after the engagement.
Prerequisites
Who does what
IT Partner
- Run the kickoff, perform the inventory and exports, confirm the licensing basis, and produce the lifecycle map, cost model and decision record.
- Build the monitoring parity map with your application owners from alert history, and state per line what Azure Monitor replaces, what SCOM retains and what is retired.
- Onboard in-scope servers to Azure Arc, build the Log Analytics workspace, data collection rules, alert rules, action groups, alert processing rules and workbooks, and run and report the parallel-run comparison.
- Enable co-management, switch workloads for the pilot and production collections in the agreed order, disposition the application catalog and repackage the pilot set, and configure Azure Update Manager for the in-scope Arc-enabled servers.
- Design and build the Azure Backup target, rebuild protection groups, run test restores, and write the DPM retention-tail plan.
- Connect VMM through Arc-enabled SCVMM and onboard the agreed VMs; disposition Orchestrator and Service Manager in writing.
- Remove SCOM agents from cut-over servers in waves, deliver the decommission checklists, and execute decommission steps only on your written approval.
- Deliver the handoff pack and hold the handoff session with your operations team.
Your team
- Grant the administrative and Azure access, disclose existing Arc, Azure Monitor, Intune and backup configuration, and open the outbound connectivity the design needs before kickoff.
- Approve the decision record — parity map, workload order, application dispositions, retention design, VMM disposition — within five business days of receiving it.
- Make application owners available for parity-map decisions in week 2 and for mismatch triage during the parallel run.
- Provide the pilot collection and pilot servers, schedule change windows, and communicate agent and workload changes to affected teams using wording IT Partner provides.
- Own the Azure subscription and pay Microsoft's meters for Log Analytics, alerting, Arc-attached services and Azure Backup; own the licensing decisions the cost model surfaces.
- Decide the end state of each System Center component, approve each decommission checklist in writing, and own the retirement of System Center licenses at renewal.
- Review the deliverables and approve delivery, or report defects, within the 6-week schedule.
What's not included
Limitations & technical notes
Frequently asked questions
What exactly does this service include?
Four streams planned as one program: Operations Manager to Azure Monitor (parity map from alert history, Azure Arc and Azure Monitor Agent rollout, data collection rules, VM insights, alert rules, action groups, workbooks, a parallel run, SCOM agent removal); Configuration Manager to Intune co-management (enablement, pilot and production workload switches, application-catalog disposition with a pilot set repackaged, Azure Update Manager for the servers it patched); Data Protection Manager to Azure Backup (MABS or MARS design, vault, rebuilt protection groups, test restores, DPM retention-tail plan); and Virtual Machine Manager to Azure through Arc-enabled SCVMM, with Azure Local and VM migration written up as alternatives. Orchestrator and Service Manager are inventoried and dispositioned. It ends with decommission checklists you approve and a handoff to your operations team.
How much does it cost, and what does 'from $6,500' mean?
It is quoted per estate, and $6,500 is the floor for the smallest estate the service fits — one management group with a handful of management packs that matter, one Configuration Manager site, a small DPM or VMM footprint. The quote is fixed and in writing before work begins, and you pay after you approve delivery. What moves it up is inventory: management packs and alert volume, monitored-server count, collections and the application catalog, protection groups and VMM hosts. Microsoft's meters — Log Analytics, alert rules, Arc-attached services, Azure Backup storage — are billed by Microsoft to your subscription and are outside the fee; the cost model shows them before anything is switched on.
How long does it take?
About 6 weeks for a typical estate: inventory and licensing in week 1, the parity map and decision record in week 2, the foundation build in weeks 2 to 3, alerting build, pilot switches and the parallel run in weeks 3 to 4, production cutover waves in weeks 4 to 5, and decommission checklists and handoff in week 6. Larger or multi-site estates get a wave plan with real dates rather than a promise. The decommission steps themselves run on your written approval and can sit inside or after the engagement — DPM in particular usually stays alive until its recovery points age out.
We are on Azure Monitor SCOM Managed Instance. What does 30 September 2026 mean for us?
Per Microsoft's Azure Monitor documentation, SCOM Managed Instance is no longer in support and is retired on 30 September 2026, after which the service is not accessible — there is no extension. Microsoft's recommended destinations are Azure Monitor or System Center Operations Manager 2025 on-premises. If you have not started by early September, we open with triage: export management packs, overrides and alert history first, put the highest-volume alerting into Azure Monitor next, and write down what will have no monitoring in the gap. Where a management pack cannot move in time, a SCOM 2025 stopgap is quoted separately; we will not pretend the calendar is longer than it is.
Can Azure Monitor really replace SCOM?
For server health, performance and event-driven alerting — most of what most estates actually use SCOM for — yes, and usually with less noise, because we rebuild from the alerts that fired and were acted on rather than from every rule a management pack ships. For health-model rollups, distributed-application views, synthetic transactions and some application-specific packs, no direct equivalent exists, and Microsoft's own guidance says there is no tool to convert management packs. The parity map is where that is settled: every line is Azure Monitor, retained in SCOM 2025, or retired with the owner's agreement. If the retained column is long, keeping SCOM 2025 for it is a legitimate outcome and we say so.
What about our SQL Server, Exchange and Active Directory management packs?
They are treated as application-specific packs on the parity map. The infrastructure signals inside them — service state, performance counters, event IDs — map cleanly to data collection rules and alert rules. The deeper checks (configuration best-practice analysis, dependency-aware health rollups) do not have a like-for-like Azure Monitor equivalent, and for some workloads Microsoft offers different Azure-side tooling — SQL Server enabled by Azure Arc for SQL instances, Microsoft Defender for Identity for domain controllers — that is a separate decision rather than a monitoring migration. Each pack gets a written disposition with the application owner before anything is built.
Do we have to get rid of Configuration Manager?
No. Co-management keeps the Configuration Manager client and moves workloads to Intune one at a time; the end state is yours — nothing left, an operating-system-deployment-only role, or a co-managed estate for years. Microsoft has moved Configuration Manager to an annual release cadence starting with version 2609 in September 2026 and continues to support it, while stating that Intune is where new device-management innovation goes. What we recommend depends on what is left on the site after the workloads move; the decision record states the end state and the decommission checklist waits for it.
What does co-management require, and are we licensed for it?
Microsoft's prerequisites are a supported Configuration Manager current branch, devices that are Microsoft Entra hybrid joined or Entra joined (Entra-registered devices are not supported), and Intune plus Microsoft Entra ID P1 licensing for the devices in scope — Microsoft 365 E3 or E5 and Enterprise Mobility + Security both include them, and Intune licensing generally carries Configuration Manager rights for the same devices. Week 1 confirms your basis. If the Intune tenant has no working Windows baseline yet, that is built first through the Microsoft Intune Initial Setup service; this service moves workloads onto a baseline, it does not create one.
What happens to our applications and task sequences?
Every application and package in Configuration Manager gets a disposition: Intune Win32 app, Microsoft Store app, retire, or stays in Configuration Manager. We repackage and deploy a pilot set through Intune and hand over the packaging runbook; converting a large catalog is quoted per application once the count is known, because that is where most Configuration Manager transitions stall. Task sequences and operating-system deployment have no Intune equivalent; Windows Autopilot is the cloud-native replacement and is delivered separately, or the site keeps an OSD role.
Who patches our servers once Configuration Manager stops?
Azure Update Manager, through Azure Arc. For the servers in the monitoring scope we configure Update Manager schedules and maintenance configurations as part of this service; Microsoft bills Update Manager for Arc-enabled servers per server per month at its published rate, with the exceptions Microsoft publishes (for example servers enrolled in Extended Security Updates through Arc). Clients move to Windows Update for Business policies from Intune, or to Windows Autopatch through our separate implementation. Retiring WSUS across servers outside the monitoring scope is the separate WSUS Replacement with Azure Update Manager for Servers engagement.
What are our options for Data Protection Manager?
Three, often combined: Microsoft Azure Backup Server (MABS), a separate installation that inherits DPM's workload protection — Hyper-V VMs, SQL Server, Exchange, SharePoint, files — with disk-to-cloud retention in a Recovery Services vault but without tape or System Center integration; the MARS agent for file, folder and system-state protection straight to the vault; and Azure VM backup for anything already in Azure. Microsoft does not support upgrading DPM to MABS, so protection groups are rebuilt and DPM stays until its existing recovery points expire — the retention-tail plan gives you the date. Host support follows Microsoft's current MABS protection matrix and is confirmed at design. If the product you are leaving is a third-party backup suite rather than DPM, the Legacy Backup to Azure Backup Migration for Server Estates service is the right page.
What are our options for Virtual Machine Manager?
Keep VMM and manage it from Azure: Arc-enabled SCVMM connects a VMM 2019, 2022 or 2025 server through the Azure Arc resource bridge, so its VMs appear in the Azure portal with lifecycle operations, at-scale agent installation, policy, patching and Defender coverage — that is what this service delivers. The alternatives are replacing the fabric with Azure Local, whose Arc VM management is native (a hardware and platform project), or migrating the VMs to Azure (the Hyper-V to Azure migration service). The disposition writes all three down with what each would take; only the first is in this scope.
Should we just upgrade to System Center 2025 instead?
Sometimes, for some components. System Center 2025 has been generally available since November 2024, and Operations Manager 2025 is supported into the 2030s under Microsoft's fixed lifecycle, so keeping SCOM for packs Azure Monitor cannot replace is a sound decision. What rarely holds up is upgrading everything by default at renewal. The lifecycle map and parity map put the choice per component in front of you with the Microsoft meters priced; if the answer for a component is 'upgrade', we quote the in-place upgrade separately and sequence it with the rest.
Who pays Microsoft, and for what?
You do, on your own Azure subscription: Log Analytics ingestion and retention beyond the included period, alert rules, Azure Arc-attached services such as Azure Update Manager and machine configuration billed per Arc-enabled server per month, Azure Backup protected instances and storage, and any Defender plan you choose. The cost model in week 2 prices each from Microsoft's published rates on the design date and shows the effect of every design choice — which counters to collect, how long to retain logs, which servers get Update Manager — before it is switched on. Our fee is separate, fixed and quoted in writing.
Who runs it after handoff?
Your operations team, with the as-built documentation and runbooks — add a server, add or tune an alert, switch a workload, package an app, add a protection group. If you would rather we run it, the Azure Resource Monitoring and Maintenance Service takes over alert triage, noise tuning and monthly reporting as a separately priced recurring service, and the Managed Microsoft Intune Service covers the Intune side.
Who owns this service at IT Partner?
Roman Sotnik owns the service. IT Partner has been a Microsoft partner since 2006 and holds the Solutions Partner designation for Infrastructure; Azure Arc, Azure Monitor and Intune are the tooling our own managed services run on, and the scoping call is with the engineers who will do the work.