Migrating MMA to AMA at fleet scale with Azure Policy

The Microsoft Monitoring Agent (MMA, the old Log Analytics agent) is deprecated; the Azure Monitor Agent (AMA) replaces it. On a handful of VMs you'd just install AMA and move on. Across a real fleet — dozens or hundreds of servers, some spun up after you started — manual installs guarantee gaps: you'll miss machines, and new ones will arrive with no agent at all. The scalable answer is Azure Policy, which installs and configures AMA automatically on any VM that's missing it, existing or future.

01The pieces that make telemetry flow

The agent alone collects nothing — the DCR association is what matters.

The single most common AMA mistake is thinking the agent is the job. It isn't. AMA is just a pipe; what it collects and where it sends data is defined entirely by a Data Collection Rule (DCR), and the DCR only applies to a VM once there's a DCR association linking them. Three parts, and all three must be present:

Piece	Role	If it's missing
AMA extension	The agent on the VM	No agent — nothing to collect
Data Collection Rule	Defines what to collect and the destination workspace	Agent runs but has no instructions
DCR association	Links the DCR to the VM	Agent installed, but collects nothing — the silent failure

That third row is the crux of this whole post. An AMA that's installed but has no DCR association looks healthy in the portal — the extension shows "provisioned" — yet sends zero telemetry. Remember it; it explains the workbook problem in Part 04.

02Why policy-driven

DeployIfNotExists installs and associates automatically — on existing and future VMs.

Azure Policy has built-in DeployIfNotExists (DINE) policies for AMA. Assigned to a subscription or management group, they evaluate every VM and, where the agent or association is missing, deploy it. New VMs are caught automatically at creation; existing VMs are fixed by a remediation task. This is the difference between a migration you finish and one that quietly regresses every time someone spins up a server.

# the policy-driven migration, in order
1. Assign the AMA DINE policy initiative to the subscription / MG
   - "Configure Windows/Linux VMs to run Azure Monitor Agent"
   - "Configure DCR association" policy for your DCR
2. Provide a user-assigned managed identity for AMA auth
3. Create the remediation task → installs AMA + associates the DCR
   on all EXISTING non-compliant VMs
4. New VMs are handled automatically going forward (DINE at create)
5. Validate telemetry, THEN remove MMA

03Validate before you remove MMA

Prove AMA is actually sending data — from the data, not the portal.

Never uninstall MMA on the assumption AMA took over. Prove it with the telemetry itself — query the workspace for recent heartbeats from the AMA agent:

// confirm AMA is actually reporting, per machine
Heartbeat
| where TimeGenerated > ago(30m)
| where Category == "Azure Monitor Agent"
| summarize LastBeat = max(TimeGenerated) by Computer
| sort by LastBeat desc

A machine appearing here, with a recent timestamp and the AMA category, is genuinely collecting. Only once a VM shows healthy AMA heartbeats should MMA be removed from it. Do this per-machine or in batches — not fleet-wide on faith.

04The trap — the health workbook lies gotcha

VMs show "not installed" while the portal shows AMA running. Don't chase it.

Here's the one that wastes an afternoon. The AMA Health Workbook (in Sentinel/Monitor) will show some VMs as "Not Installed" or "Missing Agent" — while the Azure portal, on those exact same VMs, shows the AMA extension installed and active. Both can't be right, and the instinct is to reinstall agents that are already there.

It's a reporting artifact, not a missing agent

The workbook infers agent state from telemetry — Heartbeat data and Resource Graph — not from the extension's actual presence. So it reads as "missing" when that telemetry is delayed or, more importantly, when the VM has no DCR association (installed agent, but no instructions, so no heartbeat — exactly the Part 01 silent failure). The agent is fine; the data path is the problem. Reinstalling the agent does nothing; fixing the DCR association does.

So when the workbook and the portal disagree, trust the portal (and the Heartbeat query above) for agent presence, and treat the workbook's "missing" as a signal to check the DCR association, not the agent. The clean fix is exactly the same policy mechanism: a DINE policy that ensures every AMA-equipped VM has the correct DCR association applied — remediating the data path rather than the agent.

05The migration, end to end

Assess → deploy by policy → associate → validate → remove.

# the full sequence
Assess    inventory VMs still on MMA (legacy Log Analytics agent)
Deploy    assign AMA DINE policy + DCR-association policy; run remediation
Associate confirm every AMA VM has a DCR association (this is the real work)
Validate  Heartbeat query shows recent AMA beats per machine
Remove    uninstall MMA only from validated machines
Confirm   workbook health normalises once associations + heartbeats exist

The takeaway

Migrate MMA→AMA with Azure Policy DINE so both existing and future VMs are covered automatically — but remember the agent is only a third of the job: without a DCR association it collects nothing. Validate migration from Heartbeat data, not the portal's "provisioned" status, and don't be fooled by the health workbook showing installed agents as "missing" — that's a delayed-telemetry / missing-association artifact, fixed by remediating the DCR association, never by reinstalling the agent.