The Azure Monitor Agent migration can't wait because MMA retires soon

I keep finding legacy Log Analytics Agent (MMA/OMS) installs in Azure environments where I honestly didn't expect them to have lasted this long. As of February 2024, though, the Azure Monitor Agent migration is no longer something you can put off. MMA retires on August 31, 2024. That date is close enough now that ignoring it will soon cost you logs, security visibility and support for your monitoring solutions.

MMA still hides in more places than most teams expect

In many environments MMA is far more entrenched than the teams running them realize. What you need to know is which workloads and solutions still depend on it. The usual suspects in my projects are VM Insights, certain Microsoft Sentinel connectors, Defender for Cloud, and classic management features such as Change Tracking and Update Management. Update Management in particular was tied to MMA for a long time. If you haven't moved off it yet, have a look at my post on Azure Update Manager, which explains how patching works now without an Automation Account.

Third-party extensions and custom scripts can also rely on the way MMA collects data, for example to pull in specific event logs or performance counters. So before you migrate anything, do a proper agent inventory. Which VMs and servers have MMA installed, and which solutions depend on it?

The AMA Migration Helper workbook shows where you stand

Microsoft makes this detective work easier with the "AMA Migration Helper" workbook for Azure Monitor. It tells you which servers still run MMA, which already have AMA, and where Data Collection Rules (DCRs) are missing or incomplete. I find it especially useful in mixed fleets of Azure VMs and Arc-enabled servers. It also picks up servers with both agents installed, which you'll want to deal with during the migration. Because the workbook shows migration status and concrete recommendations in one place, you can track how far you've really got instead of just ticking boxes.

Data Collection Rules give you precise filtering and cost control

DCRs are the core of the Azure Monitor Agent migration. The old agent was more or less all or nothing. With DCRs you define exactly which data sources you want (Windows Event Logs, Syslog, Performance Counters) and where the data goes (Log Analytics, Event Hub, Storage). You can even transform data in real time, for instance with KQL to filter or aggregate it before ingestion. That can cut log volume and cost considerably and makes the whole setup much easier to manage. The official docs give a good overview of what DCRs can do: Data Collection Rule overview.

Say you only want Windows Security Event ID 4625 (failed logons). This is the relevant part of a DCR JSON definition:

{
  "dataSources": {
    "windowsEventLogs": [
      {
        "name": "SecurityEvents",
        "streams": [ "Microsoft-Windows-Security-Auditing" ],
        "xPathQueries": [ "*[System[(EventID=4625)]]" ]
      }
    ]
  }
}

Azure Policy assigns DCRs at scale

The next problem is rolling DCRs out across many machines. I use Azure Policy for that. With the right initiative, DCRs get assigned automatically to all servers, or a selected set, in a subscription or management group. Microsoft documents this well (Agent overview), and it holds up in practice, including for Arc-connected servers that live outside Azure. Data collection stays consistent and auditable, no matter how spread out your infrastructure is.

The diagram below shows the basic flow: a VM or Arc server sends data through the Azure Monitor Agent, and a DCR routes it to Log Analytics.

flowchart TD
  Server["Server (VM or Arc)"] --> AMA["Azure Monitor Agent"]
  AMA --> DCR["Data Collection Rule"]
  DCR --> Target["Log Analytics Workspace"]

Figure: The basic components of data collection with the Azure Monitor Agent and a DCR, for Azure VMs and Arc-connected servers alike.

Parallel operation needs a plan to avoid duplicate data and leftovers

During the transition I recommend running MMA and AMA side by side. You can move solutions over one at a time, watch the data flows and reduce the risk of missing logs or gaps in your SIEM. The catch is duplicate data. If both agents send the same logs to the same workspace, you ingest everything twice and pay for it twice. Check carefully what each agent collects, and filter in the DCR or in MMA where needed.

My tip: In migration projects I usually move individual workloads to AMA first and send their logs to a separate workspace while both agents are running. That makes it much easier to compare the data and avoid both gaps and duplicates.

When the migration is complete, uninstall MMA from every server. This is about more than tidiness or cost. An old agent left in place can cause security or operational problems later.

Now is a good time to leave MMA behind

If you still run the legacy Log Analytics Agent, start now. The Azure Monitor Agent migration is more than a change under the hood. It gives you a reason to rethink how you handle monitoring and your SIEM. DCRs, granular filters and Azure Policy let you collect less data, spend less and end up with a monitoring setup that's easier to manage. If you're unsure where to begin, open the AMA Migration Helper workbook and pick off a few easy wins. The earlier you start, the less painful the move off MMA will be.