acrolinx

Author: bwren

articles/azure-monitor/azure-monitor-operations-manager.md

@@ -1,5 +1,5 @@
 ---
-title: Migrate from SCOM to Azure Monitor
+title: Migrate from System Center Operations Manager (SCOM) to Azure Monitor
 description: Guidance for existing users of System Center Operations Manager (SCOM) to transition monitoring of workloads to Azure Monitor as part of a transition to the cloud.
 ms.topic: conceptual
 author: bwren
@@ -9,35 +9,35 @@ ms.reviewer: bwren
 
 ---
 
-# Migrate from SCOM to Azure Monitor
+# Migrate from System Center Operations Manager (SCOM) to Azure Monitor
 This article provides guidance for customers who currently use [System Center Operations Manager (SCOM)](/system-center/scom/welcome) and are planning a transition to cloud based monitoring with [Azure Monitor](overview.md) as they migrate business applications and other resources into Azure. 
 
-There's no standard process for migrating from SCOM, and depending on your business and technical requirements, you may rely on SCOM management packs for an extending period of time as opposed to performing a quick migration. This article describes the different options available and decision criteria you can use to determine the best strategy for your particular environment.
+There's no standard process for migrating from SCOM, and depending on your business and technical requirements, you may rely on SCOM management packs for an extended time as opposed to performing a quick migration. This article describes the different options available and decision criteria you can use to determine the best strategy for your particular environment.
 
 
 
 ## Hybrid cloud monitoring
-Most customers will use a [hybrid cloud monitoring](/azure/cloud-adoption-framework/manage/monitor/cloud-models-monitor-overview#hybrid-cloud-monitoring) strategy that allows you to make a gradual transition to the cloud and maintain your existing business processes as you become more familiar with the new platform. Only move away from SCOM functionality as you can replace it with Azure Monitor. Using multiple monitoring tools does add complexity, but it allows you to take advantage of Azure Monitor's ability to monitor next generation cloud workloads while retaining SCOM's ability to monitor server software and workloads running in your virtual machines.
+Most customers use a [hybrid cloud monitoring](/azure/cloud-adoption-framework/manage/monitor/cloud-models-monitor-overview#hybrid-cloud-monitoring) strategy that allows you to make a gradual transition to the cloud. This allows you to maintain your existing business processes as you become more familiar with the new platform. Only move away from SCOM functionality as you can replace it with Azure Monitor. Using multiple monitoring tools does add complexity, but it allows you to take advantage of Azure Monitor's ability to monitor next generation cloud workloads while retaining SCOM's ability to monitor server software and workloads running in your virtual machines.
 
 Your environment prior to moving any components into Azure is based on virtual and physical machines located on-premises or with a managed service provider. It relies on SCOM to monitor business applications, server software, and other infrastructure components in your environment such as physical servers and networks. You use standard management packs for server software such as IIS, SQL Server, and various vendor software, and you tune those management packs for your specific requirements. You create custom management packs for your business applications and other components that can't be monitored with existing management packs and configure SCOM to support your business processes.
 
-As you move services into the cloud, Azure Monitor starts collecting [platform metrics](essentials/data-platform-metrics.md) and the [activity log](essentials/activity-log.md) for each of your resources, and you create [diagnostic settings](essentials/diagnostic-settings.md) to collect [resource logs](essentials/resource-logs.md) to be collected so you can interactively analyze all available telemetry using [log queries](logs/log-query-overview.md) and [insights](insights/insights-overview.md).
+As you move services into the cloud, Azure Monitor starts collecting [platform metrics](essentials/data-platform-metrics.md) and the [activity log](essentials/activity-log.md) for each of your resources. You create [diagnostic settings](essentials/diagnostic-settings.md) to collect [resource logs](essentials/resource-logs.md) so you can interactively analyze all available telemetry using [log queries](logs/log-query-overview.md) and [insights](insights/insights-overview.md).
 
-During this period of transition, you will have two independent monitoring tools. You'll use insights and workbooks to analyze your cloud telemetry in the Azure portal while still using the Operations console to analyze your data collected by SCOM. Since each system has its own alerting, you need to create action groups in Azure Monitor equivalent to your notification groups in SCOM.
+During this period of transition, you have two independent monitoring tools. You use insights and workbooks to analyze your cloud telemetry in the Azure portal while still using the Operations console to analyze your data collected by SCOM. Since each system has its own alerting, you need to create action groups in Azure Monitor equivalent to your notification groups in SCOM.
 
 The following table describes the different features and strategies that are available for a hybrid monitoring environment using SCOM and Azure Monitor.
 
 | Method | Description |
 |:---|:---|
-| Dual-homed agents | SCOM uses the Microsoft Management Agent (MMA) which is the same as [Log Analytics agent](agents/log-analytics-agent.md) used by Azure Monitor. You can configure this agent to have a single machine connect to both SCOM and Azure Monitor simultaneously. This does require that your Azure VMs have a connection to your on-premises management servers.<br><br>The [Log Analytics agent](agents/log-analytics-agent.md) has been replaced with the [Azure Monitor agent](agents/agents-overview.md) which provides significant advantages including simpler management and better control over data collection. The two agents can coexist on the same machine allowing you to connect to both Azure Monitor and SCOM. This is a better option than dual-homing the legacy agent because of the significant [advantages of the Azure Monitor agent](agents/agents-overview.md#benefits). |
+| Dual-homed agents | SCOM uses the Microsoft Management Agent (MMA) which is the same as [Log Analytics agent](agents/log-analytics-agent.md) used by Azure Monitor. You can configure this agent to have a single machine connect to both SCOM and Azure Monitor simultaneously. This does require that your Azure VMs have a connection to your on-premises management servers.<br><br>The [Log Analytics agent](agents/log-analytics-agent.md) has been replaced with the [Azure Monitor agent](agents/agents-overview.md), which provides significant advantages including simpler management and better control over data collection. The two agents can coexist on the same machine allowing you to connect to both Azure Monitor and SCOM. This is a better option than dual-homing the legacy agent because of the significant [advantages of the Azure Monitor agent](agents/agents-overview.md#benefits). |
 | Connected management group | [Connect your SCOM management group to Azure Monitor](agents/om-agents.md) to forward data collected from your SCOM agents to Azure Monitor. This is similar to using dual-homed agents, but doesn't require each agent to be configured to connect to Azure Monitor. This strategy requires the legacy agent, so you can't specify monitoring with data collection rules. You also can't use VM insights unless you connect each VM directly to Azure Monitor. |
 | SCOM Managed instance (preview) | [SCOM managed instance (preview)](vm/scom-managed-instance-overview.md) is a full implementation of SCOM in Azure allowing you to continue running the same management packs that you run in your on-premises SCOM environment. There is no current integration between the data and alerts from SCOM and Azure Monitor, and you continue to use the same Operations console for analyzing your health and alerts.<br><br>This is similar to maintaining your existing SCOM environment and dual-homing agents, although you can consolidate your monitoring configuration in Azure and retire your on-premises components such as database and management servers. Agents from Azure VMs can connect to the SCOM managed instance in Azure rather than connecting to management servers in your own data center. |
-|  Azure management pack | The [Azure management pack](https://www.microsoft.com/download/details.aspx?id=50013) allows Operations Manager to discover Azure resources and monitor their health based on a particular set of monitoring scenarios. This management pack does require you to perform additional configuration for each resource in Azure, but it may be helpful to provide some visibility of your Azure resources in the Operations Console until you evolve your business processes to focus on Azure Monitor. |
+|  Azure management pack | The [Azure management pack](https://www.microsoft.com/download/details.aspx?id=50013) allows Operations Manager to discover Azure resources and monitor their health based on a particular set of monitoring scenarios. This management pack does require you to perform additional configuration for each resource in Azure. It may be helpful though to provide some visibility of your Azure resources in the Operations Console until you evolve your business processes to focus on Azure Monitor. |
 
 ## Monitor business applications
-You typically require custom management packs to monitor your business applications with SCOM, leveraging agents installed on each virtual machine. Application Insights in Azure Monitor monitors web-based applications whether they're in Azure, other clouds, or on-premises, so it can be used for all of your applications whether or not they've been migrated to Azure.
+You typically require custom management packs to monitor your business applications with SCOM, using agents installed on each virtual machine. Application Insights in Azure Monitor monitors web-based applications whether they're in Azure, other clouds, or on-premises. It can be used for all of your applications whether or not they've been migrated to Azure.
 
-If your monitoring of a business application is limited to functionality provided by the [.NET app performance template](/system-center/scom/net-application-performance-monitoring-template) in SCOM, then you can most likely migrate to Application Insights with no loss of functionality. In fact, Application Insights will include a significant number of additional features including the following:
+If your monitoring of a business application is limited to functionality provided by the [.NET app performance template](/system-center/scom/net-application-performance-monitoring-template) in SCOM, then you can most likely migrate to Application Insights with no loss of functionality. In fact, Application Insights includes a significant number of additional features including the following:
 
 - Automatically discover and monitor application components.
 - Collect detailed application usage and performance data such as response time, failure rates, and request rates.
@@ -50,7 +50,7 @@ If your monitoring of a business application is limited to functionality provide
 There are certain scenarios though where you may need to continue using SCOM in addition to Application Insights until you're able to achieve required functionality. Examples where you may need to continue with SCOM include the following:
 
 - [Availability tests](/previous-versions/azure/azure-monitor/app/monitor-web-app-availability), which allow you to monitor and alert on the availability and responsiveness of your applications require incoming requests from the IP addresses of web test agents. If your policy won't allow such access, you may need to keep using [Web Application Availability Monitors](/system-center/scom/web-application-availability-monitoring-template) in SCOM.
-- In SCOM you can set any polling interval for availability tests, with many customers checking every 60-120 seconds. Application Insights has a minimum polling interval of 5 minutes which may be too long for some customers.
+- In SCOM you can set any polling interval for availability tests, with many customers checking every 60-120 seconds. Application Insights has a minimum polling interval of five minutes which may be too long for some customers.
 - A significant amount of monitoring in SCOM is performed by collecting events generated by applications and by running scripts on the local agent. These aren't standard options in Application Insights, so you could require custom work to achieve your business requirements. This might include custom alert rules using event data stored in a Log Analytics workspace and scripts launched in a virtual machines guest using [hybrid runbook worker](../automation/automation-hybrid-runbook-worker.md).
 - Depending on the language that your application is written in, you may be limited in the [instrumentation you can use with Application Insights](app/app-insights-overview.md#supported-languages).
 
@@ -72,7 +72,7 @@ Continue to use management packs for functionality that cannot be provided by ot
 ### Migrate management pack logic for VM workloads
 There are no migration tools to convert SCOM management packs to Azure Monitor because their logic is fundamentally different than Azure Monitor data collection. Migrating management pack logic will typically focus on analyzing the data collected by SCOM and identifying those monitoring scenarios that can be replicated by Azure Monitor. As you customize Azure Monitor to meet your requirements for different applications and components, then you can start to retire different management packs and legacy agents in SCOM.
 
-Management packs in SCOM contain rules and monitors that combine collection of data and the resulting alert into a single end-to-end workflow. Data that's already been collected by SCOM is rarely used for alerting. Azure Monitor separates data collection and alerts into separate processes. Alert rules access data from Azure Monitor Logs and Azure Monitor Metrics that has already been collected from agents. Also, rules and monitors are typically narrowly focused on very specific data such as a particular event or performance counter. Data collection rules in Azure Monitor are typically more broad collecting multiple sets of events and performance counters in a single DCR.
+Management packs in SCOM contain rules and monitors that combine collection of data and the resulting alert into a single end-to-end workflow. Data already collected by SCOM is rarely used for alerting. Azure Monitor separates data collection and alerts into separate processes. Alert rules access data from Azure Monitor Logs and Azure Monitor Metrics that has already been collected from agents. Also, rules and monitors are typically narrowly focused on specific data such as a particular event or performance counter. Data collection rules in Azure Monitor are typically more broad collecting multiple sets of events and performance counters in a single DCR.
 
 See the following content for guidance on creating data collection and alerting for common monitoring scenarios: