Microsoft has quietly confirmed that the venerable HTTP Data Collector API for Azure Monitor won’t just stop working on September 14, 2026. According to a newly updated response on Microsoft Q&A, ingestion will continue for any client that can negotiate TLS 1.2 or higher. What ends is official support—meaning no bug fixes, no new features, and only critical security patches from that date forward. The real pressure shifts from panic-migration to something subtler and more dangerous: a painstaking treasure hunt for every forgotten PowerShell script, scheduled task, IIS application, and line-of-business service that still posts telemetry the old way.

The Real Story: No Hard Stop, But No Support Either

The confusion started when Microsoft’s original retirement notice, published in September 2023, warned that “Data Collector API endpoints will become unavailable after the cut over date.” That language suggested a hard stop. But in May 2026, the Azure Monitor team updated the official migration documentation with softer language, indicating only that support would end. The conflicting statements left admins asking whether their homegrown telemetry scripts would suddenly fail.

The definitive answer arrived in a Microsoft Q&A thread, where the backend team confirmed that September 14, 2026, is a support boundary, not a shutdown. Ingestion itself will keep working for clients using TLS 1.2 or later. However, the API becomes an unsupported dependency—one that won’t receive routine maintenance or fixes. In practice, that means any future change to the Azure platform could break these ingest paths without warning, and Microsoft will have no obligation to help. Organizations relying on the old API will be operating without a net.

There’s an earlier, harder deadline already behind us. On March 1, 2026, the endpoint began rejecting clients that couldn’t negotiate TLS 1.2 or above. If a custom log table suddenly went quiet around that date, the culprit isn’t a DCR misconfiguration—it’s an outdated script or app using legacy TLS. That failure is permanent unless you update the sender’s TLS stack.

Why Your Agent Report Won’t Save You

Most IT teams track Azure Monitor Agent deployment religiously. They know how many servers have the latest extension, and they can prove that Windows Event logs and performance counters flow through DCRs. None of that helps with the Data Collector API. The legacy API doesn’t require an agent at all: any piece of code that can construct an HTTPS request with a workspace ID, a shared key, and a custom HMAC signature can inject data directly into a Log Analytics workspace. These senders live outside the agent inventory.

Your real vulnerability sits in places like C:\Scripts\HealthCheck.ps1, a SQL Server Agent job step that calls a custom collector, an IIS-hosted web app whose web.config stores a workspace key, or a third-party backup utility that silently ships its own log data. There is no recognizable monitoring agent to discover. The integration is just a handful of code in a file system that nobody has touched in years.

To find them, you need to hunt for patterns in text-based files and inspect the behavior of services and scheduled tasks that could wrap custom collectors. The following patterns, adapted from WindowsForum’s migration playbook, are a good start:

  • ods.opinsights.azure.com
  • api/logs
  • Log-Type header
  • x-ms-date header
  • Authorization: SharedKey header
  • SharedKey or HMAC references
  • workspaceId or workspaceKey variables

A quick PowerShell scan of likely directories—C:\Scripts, C:\ProgramData, C:\inetpub, and C:\Windows\System32\Tasks—can surface scripts and configuration files that contain these strings. But a text search is only the first step. Obfuscated or compiled code may never reveal the string “SharedKey” even though it’s performing the exact same signing operation.

Where Hidden Data Senders Lurk

Scheduled tasks are a classic hiding place. The task name may say “Nightly Health Rollup,” but its action invokes a PowerShell script that, three modules deep, calls the Data Collector API. Don’t trust names. Export the full list of scheduled tasks and inspect their actions, arguments, and any referenced scripts. Follow the execution chain until you’re certain no Azure Monitor call is buried inside.

Windows services can be just as deceptive. A third-party monitoring tool installed five years ago may still run as a service, shipping data directly to a workspace you’ve long since forgotten about. Check the full service inventory, not just those with “monitor” or “collector” in the name. Look for any service whose binary path or arguments suggest custom code, and then examine that application’s configuration files for endpoint strings and keys.

IIS applications are a special challenge. An internal web app may use an application pool identity to post telemetry, blending in with normal outbound HTTPS traffic. Search under C:\inetpub and any custom deployment folders. Compiled .NET applications may embed the endpoint in a binary; look for companion .config, .json, or .xml files that set workspaceId and workspaceKey. If you can’t find source code, check application ownership records and observe outbound network connections to identify any traffic heading to ods.opinsights.azure.com on port 443.

SQL Server also creates several hiding spots. SQL Agent jobs can execute PowerShell or command-shell steps that call the legacy API. Integration packages (SSIS) may contain script tasks that do the same. Export job definitions and search for known patterns. If you use linked servers or external stored procedures, inspect those too.

From Shared Keys to Entra ID: The Code You Need to Rewrite

Once you’ve located every legacy sender, you’ll face a consistent code pattern that must be replaced. The old method typically follows these steps:

  1. Read a workspace shared key from a config file or environment variable.
  2. Serialize the telemetry payload into JSON.
  3. Construct a signing string from the HTTP method, content length, content type, and the current UTC date in RFC 1123 format.
  4. Compute an HMAC-SHA256 signature using the workspace key.
  5. Send an HTTPS POST to https://{workspaceId}.ods.opinsights.azure.com/api/logs?api-version=2016-04-01 with headers Authorization: SharedKey, Log-Type, and x-ms-date.

The modern Logs Ingestion API replaces almost every part of that sequence:

  • Authentication: Instead of a shared key and HMAC, you’ll obtain a Microsoft Entra ID access token (using a managed identity or service principal) and send it as a bearer token in the Authorization header.
  • Endpoint: The target URL changes to your DCR’s or DCE’s ingestion endpoint, and you must include the DCR immutable ID and the stream name as query parameters or in the URI path.
  • Payload handling: The JSON payload must conform to the input schema defined in the DCR. Any transformation, filtering, or routing that used to live in custom code can now be moved into the DCR’s built-in transformation KQL.

This is not a simple search-and-replace. The entire authentication and request architecture changes. A script that has been running flawlessly for years will need its core networking logic rewritten. But the migration also brings long-term benefits: you eliminate the storage of shared secrets, you gain centralized data transformation, and you align with a model that Azure will support for the next decade.

How to Test Without Breaking Production

Ripping out the old sender and hoping the new one works is a recipe for missing telemetry at the worst possible moment. The recommended approach is dual-write: run the legacy and new senders in parallel for a representative period, comparing the data side by side.

Choose a separate destination table or workspace for the new path if that makes comparison easier. Microsoft’s guidance notes that direct conversion of a table’s schema is not reversible, so a parallel stream with a different log type can give you a safe rollback point.

Your validation checklist should include:

  • Record counts: Match total events over the same time window.
  • Field integrity: Verify that every field you depend on still appears, with the correct type and no truncation.
  • Timestamp fidelity: Ensure events land with the correct timestamp and that TimeGenerated isn’t shifted by a time zone bug or parsing error.
  • Volume and burst testing: Don’t just test a single sample record. Send large batches and bursty payloads similar to peak production traffic. Watch for throttling or dropped events.
  • Transformation results: If you’ve moved logic into the DCR, confirm that filtered events are truly dropped and that derived fields are calculated correctly.
  • Downstream impact: Check all alerts, workbooks, dashboards, and queries that consume the data. A new stream name or a slight change in field names can silently break a SIEM rule or an executive dashboard.
  • Cost control: Dual-write doubles ingestion volume for the overlap period. Set a budget alert and turn off the old sender promptly after validation. Forgetting it could result in an expensive surprise.

Also, treat any workspace shared keys you find during discovery as credentials. Don’t include their actual values in inventory reports or check them into source control. If a shared key is compromised, an attacker can inject arbitrary data into your Log Analytics workspace. Rotate keys after migration and remove them from all configuration stores.

The Real Deadline

September 14, 2026, is not a day when your TLS 1.2‑compliant senders will silently fail. It’s the day the API loses its safety net. For every script, service, and application that still uses Authorization: SharedKey, you enter a state where any future Azure platform update—an endpoint change, a cipher suite deprecation, a security protocol upgrade—could break ingestion without notice and without recourse. That is an unacceptable operational risk for monitoring data that feeds security incident detection, capacity planning, and compliance reporting.

If you haven’t started the hunt, start now. The scanning, rewriting, and validation project is measured in weeks or months, not hours. Every legacy sender you find is a project, and the sheer variety of places they hide—scheduled tasks, IIS apps, SQL jobs, service executables—means a one-size-fits-all approach won’t work. Build an inventory, assign ownership, map every discovered sender to a workspace table, and then begin a disciplined dual-write migration. The API will keep working for now, but your window to move with support is closing.