On September 14, 2026, Microsoft ends official support for the HTTP Data Collector API, a long-standing method for sending custom telemetry and logs into Azure Monitor Logs and Microsoft Sentinel. But a quiet update—delivered through a Microsoft Q&A moderator rather than a formal announcement—now confirms the retirement won’t be the hard cutoff many administrators feared. Ingestion for clients using TLS 1.2 or later will continue past that date.

That twist doesn’t mean you can skip the migration. It reshapes the urgency: you’re no longer staring at a hard stop, but you are running against the clock on official support, bug fixes, and any service-level guarantees. For critical workloads feeding security telemetry, compliance data, or operational dashboards, the practical deadline remains well before the support window slams shut.

The Clarification: What Actually Changes on September 14

The original Azure Updates retirement announcement, published in September 2023, declared that “Data Collector API endpoints will become unavailable after the cut over date.” That hard-stop language stood for nearly three years, driving compliance calendars and migration projects. But on May 14, 2026, Microsoft quietly updated its Learn documentation to reflect a soft deprecation model. The newer guidance says ingestion will continue, albeit without any support commitments beyond critical security fixes.

The confusion came to a head in a Microsoft Q&A thread where a customer asked for definitive clarity. Moderator Suchitra responded after checking directly with the Azure Monitor backend team. Her reply, dated May 15, 2026, made three things plain:

  • September 14, 2026, is not a hard ingestion cutoff for clients connecting over TLS 1.2 or later.
  • What ends is official support: no new features, no non-critical bug fixes, and no SLA.
  • The earlier retirement announcement with its “unavailable” wording is now considered outdated; the May 2026 Learn article represents the current, accurate expectation.

The response also strongly recommends migrating to the Logs Ingestion API—based on Data Collection Rules (DCR)—to avoid operating on an unsupported endpoint.

What This Means for You, Depending on Your Role

For IT Administrators and Operations Teams

If you manage servers, runbooks, or custom monitoring scripts that push data into Azure Monitor Logs, the clarification is both a relief and a warning. You won’t face an immediate outage on September 14, but every day you run on an unsupported API increases the risk of silent failures, security gaps, and a sudden, unannounced shutdown later. “Still responding” is not the same as “supported.” The backend team’s message draws a bright line: after September 14, they’ll deliver only critical security patches—nothing else.

This is not a license to procrastinate. Without an SLA, a transient ingestion failure could go unnoticed until a security incident review. Nor will you receive notification of upcoming changes that might break your integration. Your only safe path is to complete migration before the support curtain falls.

For Security Teams Using Microsoft Sentinel

Sentinel integrations that rely on custom data fed through the old API require extra scrutiny. Many organizations have scripts, appliances, or third-party tools shipping logs directly to Sentinel workspaces via the HTTP Data Collector API. After September 14, those pipes remain open, but unsupported. If a threat detection depends on that data, a subtle ingestion error could blind your SOC.

The Sentinel connector catalog now offers documented, supported ingestion paths—including DCR-based Logs Ingestion API connectors, Syslog, and Common Event Format (CEF) channels—for most common sources. The immediate task is to classify every custom integration as either an out-of-box connector you can switch to, a documented Syslog/CEF/REST path you can adopt, or truly custom code that you must rewrite. Don’t assume a simple agent upgrade will fix everything; many customer-owned scripts call the retiring API directly and must be rebuilt.

For Developers

If you built applications, functions, or automation that constructs HTTP requests against the Data Collector API endpoints, the clock is ticking on code-level changes. You’ll need to rework those senders to target the Logs Ingestion API. The new API uses a different authentication and payload structure tied to DCRs, so testing and validation will take real engineering time. Start early.

How We Got Here: A Timeline of Mixed Messages

  • September 2023: Microsoft posts an Azure Update announcing that the HTTP Data Collector API will retire on September 14, 2026, stating plainly that endpoints “will become unavailable” after that date.
  • May 14, 2026: Microsoft Learn documentation is silently refreshed to say ingestion will continue for TLS 1.2+ clients, replacing the hard-stop language with a soft deprecation note. No public blog or email accompanies the change.
  • May 15, 2026: A Microsoft Q&A moderator relays backend team confirmation that the retirement is not a hard stop, and that the September 2023 announcement is now outdated.
  • Present day: Customers are left parsing a moderator’s reply as their best source of truth, while official planning guidance lags behind.

The inconsistency has created operational headaches: some teams planned aggressive migration sprints expecting a hard shutdown; others may now be tempted to delay indefinitely. Both positions misread the risk.

What to Do Now: A Practical Migration Playbook

1. Inventory Every Sender, Not Just Azure Resources

Azure Advisor’s “Service Upgrade and Retirement” recommendations will flag some affected resources, but they won’t catch all the scripts, scheduled tasks, and custom code that might be hiding in your environment. Export what Advisor finds, then launch a broader hunt using these tips:

  • Search PowerShell script repositories, Azure Automation runbooks, and Azure Function configurations for references to the Data Collector API endpoint or associated workspace IDs.
  • Inspect Windows Task Scheduler on automation servers and SQL Server Agent jobs on database instances.
  • Check IIS application settings, credential stores, and third-party monitoring appliances.
  • Look on on-premises servers that forward logs to Azure; scheduled tasks there are easily overlooked.
  • Ask application teams to grep their source code and deployment pipelines for API calls to ods.opinsights.azure.com or similar endpoints.

2. Build a Dependency Register

For each sender you find, create a record that captures:

  • Technical owner and business owner
  • Destination workspace and table
  • Execution schedule and business impact if ingestion stops
  • Whether data feeds security monitoring, audit, or compliance processes
  • Current migration status and the replacement path selected

Record unknowns (e.g., orphaned integrations with no owner) as risks requiring escalation.

3. Prioritize by Consequence

Address security telemetry, incident-response feeds, audit trails, and regulated data first. Business-critical application logs should follow—especially if operational alerts depend on them. Shared automation that affects multiple teams deserves early attention. Low-value telemetry can wait, but only after you’ve documented who owns it and accepted the risk.

4. Migrate Using Microsoft’s Documented Path

Don’t rewrite scripts yet. First, determine the correct replacement for each sender. For most use cases, the answer is the Logs Ingestion API with Data Collection Rules. Start with the official migration guide: Migrate from the HTTP Data Collector API to the Logs Ingestion API. (Note: that link is a placeholder; use the latest Microsoft Learn article.)

For Microsoft Sentinel sources, classify every integration using the connector catalog:

  • Out-of-box connector: Switch to it; follow the setup documentation.
  • Documented Syslog/CEF/REST path: Reconfigure the data source accordingly.
  • Custom integration: Redesign it to call the Logs Ingestion API directly.

5. Validate in Parallel Before Cutover

Run the old and new ingestion paths side by side for a full business cycle—at least one complete iteration of every scheduled job. Compare:

  • Record counts over equivalent periods
  • Field population and event timestamps
  • Query results, alert behavior, and dashboard outputs
  • Downstream automation triggers

Keep evidence: test windows, queries used, expected vs. actual results, and sign-off from both the technical owner and the consumer of the data. A single sample event is not enough to prove a detection rule works.

6. Monitor Post-Cutover

After switching off the legacy sender, watch actual data arrival for several cycles. A successful HTTP 200 response from the new API doesn’t guarantee that records reached the right table in a usable schema.

The Outlook

Microsoft has not announced a future hard cutoff date for the Data Collector API. Theoretically, TLS 1.2 ingestion could continue for years—but without support, that’s a gamble. The company’s clear strategic direction is toward the DCR-based Logs Ingestion API, which offers better control, transformation capabilities, and parity with all newer Azure Monitor agents. Every new feature and security investment will flow there.

The safe, responsible move is to complete your migration before September 14, 2026. If you haven’t started, the time to begin the discovery is now. A dependency register that exposes every hidden script, job, and appliance feeding the old API is your best insurance against an unplanned outage.