Migrate to Azure Monitor Agent from Azure Diagnostic extensions (WAD/LAD)

The Azure Diagnostics extensions (WAD/LAD) are deprecated and retire on March 31, 2026. For full migration guidance, see here.
As a migration option, you can migrate to Azure Monitor Agent (AMA). It gets configured with Data Collection Rules (DCRs) to continue collecting guest OS logs and performance data. It allows multi-destination routing, centralized, a more secure configuration, and at-scale management.

Note

DCRs provide transformations (ingestion-time filtering, parsing) to reduce cost and tailor schemas - something not available in WAD/LAD.

Comparison of WAD/LAD agents and AMA

Area WAD/LAD AMA
Status Legacy; retiring March 31, 2026 Current and strategic agent
Config model XML/JSON/WAD, LAD schema Centralized DCRs in Azure, also providing transformations (ingestion-time filtering, parsing) to reduce cost and tailor schemas
Security Storage keys, classic auth patterns Azure Managed Identity based access; modern Transport Layer Security (TLS) endpoints
Network Per extension outbound Standardized endpoints/service tags for AMA and data collection endpoints (DCEs)

Migration steps

Use the following phased approach to migrate from WAD/LAD to AMA with DCRs.

Phase 1: Discover and assess

  1. Inventory machines running WAD/LAD

    1. For per-VM view in Azure portal, navigate to Extensions + applications tab.
    2. For fleet view, use Azure Resource Graph query from the WAD/LAD overview article to find extensions by publisher == Microsoft.Azure.Diagnostics.

  2. Extract current diagnostics config - Gather WAD public config XML (Windows) and LAD JSON (Linux) to list counters, events, syslog facilities/severities, file paths, transfer schedules, and destinations.

  3. Prioritize what to keep or drop - Use this moment to reduce noise and unused data types, if any. By using DCR transformations, you can additionally filter to essential signals.

Phase 2: Design DCRs

  1. Create DCRs that replicate the WAD/LAD intent:
    1. Standard VM data sources like Windows events (for example, System, Application, Security), Linux syslog, performance counters.
    2. Custom text logs (same file path wildcards; ensure custom tables exist; often requires a DCE) sent to low-cost Auxiliary tier in Log Analytics.
    3. ADX-destination routing.

Note

Keep Windows and Linux in separate DCRs to avoid accidental counter duplication (same metric from both naming styles).

Phase 3: Deploy AMA and assign DCRs at scale

  1. Prepare prerequisites for AMA installation and DCR association, including verifying supported OS and network settings.
  2. Ensure you have Log Analytics workspace setup with Auxiliary tier as needed.
  3. (Recommended) Use Azure Policy built‑in initiatives to install AMA on Windows and Linux and associate DCRs. By using policy, you auto-onboard new machines and remediate existing machines, aligning to the migration best practices.

Phase 4: Validate

  1. Agent health: Confirm AzureMonitorWindowsAgent and AzureMonitorLinuxAgent extension status is Provisioning succeeded on VMs.
  2. Data flow:
    1. Logs: Query in Log Analytics workspace (for example, Event, Syslog, custom table) as per the DCR data source.
    2. Performance counters to Metrics: switch to the VM Metrics view to the Virtual machine guest namespace to see counters via AMA-to-Metrics routing.

Phase 5: Remove WAD/LAD

  1. Coordinate a cutover window per environment (Dev → Test → Production).
  2. Stop or remove the Microsoft.Azure.Diagnostics extension from each VM after AMA data parity is confirmed. This step is explicitly recommended to avoid double ingestion and extra costs.

Common troubleshooting tips

  • Agent installed but no service visible on Windows: AMA runs under an extension model and process. Verify the agent through the VM Extensions area and DCR association rather than looking for an "Azure Monitor Agent" service.
  • No data from custom logs: Confirm the custom table exists, DCE is configured (where required), file patterns are correct, and the record delimiter and time format matches your files.
  • Firewall or proxy blocked: Validate outbound port 443 to the control, DCR, ODS, and DCE ingest endpoints. You must disable HTTPS inspection.
  • Last updated on