The legacy HTTP Data Collector API stops being supported after September 14, 2026.
Both the date and the consequence are published. Any data source, custom integration or connector still using that API risks interrupted ingestion once it passes. If something you built is sending data that way, nothing else on your Sentinel list is more urgent. We inventory, migrate and monitor Sentinel ingestion for organizations across the United States.
- Sep 14, 2026Legacy HTTP Data Collector API support ends
- Mar 31, 2027Sentinel in the Azure portal is retired
- 4 routesFor building a custom connector
- 3 support tiersMicrosoft, partner, and community
Eight things to establish about your own ingestion.
What is still using the legacy API
Support for the legacy HTTP Data Collector API ends on September 14, 2026, with a published warning about ingestion interruptions after that point. Anything custom that was built more than a couple of years ago is a candidate. Note how it fails: the data quietly stops arriving rather than producing an error anybody sees.
Where that data should go instead
The recommended destinations are the Logs Ingestion API or the Codeless Connector Framework, on the grounds of uninterrupted ingestion, better reliability, better scalability and long-term support. Choosing between the two normally comes down to one question: are you calling out to an API, or receiving something pushed to you.
Service to service connectors for Microsoft and AWS
Service-to-service integration works out of the box and in real time. Take the Defender XDR connector on its own: it pulls in data from Office 365, Microsoft Entra ID, Microsoft Defender for Identity and Microsoft Defender for Cloud Apps. That is a great deal of coverage arriving through a single connection.
Syslog and CEF through the Azure Monitor Agent
Events arrive from Linux devices that support Syslog by way of the Azure Monitor Agent, which sits either on the device itself or on a dedicated Linux log forwarder. Where they land differs by type: Syslog messages go into the Syslog table and CEF messages into CommonSecurityLog. Worth committing to memory before you write your first query against them.
Custom logs and custom tables
Some sources are collected as files sitting on Windows or Linux machines, and once configured that data turns up in custom tables. This is the route for any application offering neither an API nor Syslog output, a description that fits a great deal of line of business software.
Who supports each connector you rely on
Each connector falls into one of three support tiers: Microsoft-supported, partner-supported or community-supported. A community-supported connector lists no support contact at all, and problems get raised through the Microsoft Sentinel GitHub community. Establish which tier your critical connectors sit in before one of them breaks rather than during the incident.
Connectors arrive as part of solutions
Deploy a solution out of the Content Hub and the data connector arrives alongside the workbooks, analytics rules and playbooks that belong with it, all in one deployment. Installing the connector on its own and then wondering where the detection content went is a common step, and an entirely avoidable one.
The portal move, with its own date
From March 31, 2027, support for Sentinel in the Azure portal ends and the Defender portal becomes the only place it exists, with customers redirected there. That has consequences beyond a change of address: it affects runbooks, saved links, documentation and any automation written on the assumption of the Azure portal experience.
Past September 14, 2026, anything still riding the legacy HTTP Data Collector API may simply stop turning up.
The published wording is potential ingestion interruptions. What makes it worth acting on today rather than next year is the manner in which it fails.
- When ingestion stops, it does so quietly. A connector that has run faithfully for three years raises nothing when it finally stops sending. A workspace missing one source looks exactly like a workspace with every source intact, right up until somebody queries a table and notices the most recent row is four months old.
- What is at risk is the custom work rather than the product connectors. Integrations a previous provider built. Scripts pushing data out of a line of business system. Anything written against the older Log Analytics ingestion pattern. Those happen to be precisely the things nobody kept documentation for.
- Two destinations are recommended, the Logs Ingestion API and the Codeless Connector Framework, with uninterrupted ingestion, better reliability, better scalability and long-term support given as the reasoning. Where the source exposes an API of its own, the Codeless Connector Framework is usually the route requiring the least work from you.
- What this calls for first is an inventory, not a migration project. Work out which sources are on the legacy API, which of those anybody still needs, and which can simply be retired rather than migrated. That final category is almost always larger than anyone expected going in.
Four things that make ingestion reliable rather than assumed.
Legacy API usage gets found by us rather than by the deadline
Come September 14, 2026, the legacy HTTP Data Collector API loses support, with a published warning about ingestion interruptions afterwards. The custom integrations relying on it are almost never documented anywhere, which makes this an inventory exercise rather than something you can look up. Better done now than in the last fortnight before the date.
We ask what actually uses each source
We map each source to the analytics rules and workbooks consuming it, on the basis that a source nothing ever queries is pure cost with no benefit attached. Migrating one of those is wasted effort. Retiring it cuts the migration workload and the ongoing ingestion volume in a single decision.
We add alerting for silence
A SIEM connector fails in one characteristic way: it stops without saying anything. Alerting when a source falls silent converts that into a detected event. Of every change available to you here, that one does the most for your confidence in the data sitting underneath every detection you run.
We install solutions rather than bare connectors
A Content Hub solution deploys the connector together with the workbooks, analytics rules and playbooks that accompany it, all at once. Connecting a source and then writing detection from a blank page is a well-worn route to spending several weeks recreating content that would have arrived alongside the connector.
Four phases across roughly four to six weeks.
- 01Week 1
Inventory every ingestion path
The connectors page is only the start. We go after the custom integrations, the scripts, the forwarders and whatever a previous provider left behind. Each one gets attributed to a source, an owner, an ingestion method and a support tier, because a community-supported connector carries a very different risk profile from a Microsoft-supported one.
- Every ingestion path listed with method and owner
- Legacy HTTP Data Collector API usage identified
- Support tier recorded per connector
- Sources believed connected but silent identified
- 02Week 2
Decide migrate or retire, per source
No question in the whole engagement returns more than this one. A source that nothing queries, that no analytics rule touches, does not need migrating anywhere. It needs switching off. Making that call cuts the migration effort and the ongoing ingestion bill at the same time.
- Every source mapped to the analytics rules and workbooks that actually read it
- Unused sources identified for retirement
- Migration target chosen per remaining source
- Retirement decisions recorded with owners
- 03Weeks 3 to 4
Migrate, preferring codeless where it fits
Where a source exposes a suitable API, the Codeless Connector Framework does the job. Where custom logic is genuinely required, the Logs Ingestion API through an Azure Function or a Logic App. Every migration is validated the same way: confirm the data is landing in the expected table before anybody removes the old path.
- Connectors rebuilt on supported routes
- Data confirmed arriving in the expected tables
- Analytics rules validated against the new data
- Legacy paths decommissioned only after validation
- 04Weeks 5 to 6
Add ingestion monitoring and plan the portal move
This is the step that stops the whole problem recurring. An alert fires when a source stops sending, which converts a silent ingestion failure into something detected. Alongside that we plan for the Azure portal retirement on March 31, 2027, which will affect your runbooks and every saved link pointing at it.
- Ingestion health monitoring per source
- Alerting when a source goes quiet
- Runbooks updated for the Defender portal
- Content Hub solutions installed where connectors were standalone
Six situations where ingestion is the problem.
An organization with integrations built by a previous provider
Custom ingestion built by somebody who left years ago, with no documentation behind it, and every chance it runs on the HTTP Data Collector API that loses support after September 14, 2026. In most Sentinel estates today, nothing deserves an inventory more urgently.
A business that discovered a gap during an investigation
There is no worse moment to discover a connector broke. Ingestion health monitoring that alerts on silence turns that discovery from something you make mid-incident into a ticket somebody picks up on a quiet Tuesday. The underlying failure is identical. The outcome is not remotely comparable.
A regulated firm evidencing log coverage
A SOC 2 auditor, a HIPAA security assessment or an NYDFS Part 500 examination will ask two questions: which sources feed the SIEM, and how do you know they are still feeding it. An inventory carrying owners, methods and support tiers answers the first. Ingestion health alerting answers the second in a way no screenshot ever will.
An operator with network and appliance logs
Syslog and CEF come from Linux devices through the Azure Monitor Agent, running either on the device itself or on a dedicated log forwarder. Knowing where each ends up, Syslog in the Syslog table and CEF in CommonSecurityLog, is what makes the queries you write against them work on the first attempt rather than the fourth.
A business whose critical applications do nothing but write log files
No API, no Syslog output, nothing but files sitting on a server. Custom log collection moves that data into custom tables, and it is frequently the only available route for the one application the business cares about most and which integrates with absolutely nothing.
An organization planning data lake retention
The data lake tier does not behave like the analytics tier, and that is worth establishing before you start ingesting into it. Individual records cannot be purged from it. It holds data for the full retention period even after the source deletes it. And changes to Purview settings have no effect on it. Anywhere CCPA or CPRA deletion obligations apply to you, that behavior belongs in your data map rather than being discovered later.
How US organizations manage Sentinel ingestion.
| Feature | Inventoried and monitored | Connected, not monitored | Accumulated over years |
|---|---|---|---|
Every ingestion path known | Yes | Mostly | No |
Legacy API usage identified | Yes | Unknown | Unknown |
Silent ingestion failure detected | Alerted | No | No |
Unused sources retired | Yes | No | No |
Connectors installed with solutions | Yes | Sometimes | Rarely |
Support tier known per connector | Yes | No | No |
Sources mapped to analytics rules | Yes | No | No |
Ready for the September 2026 deadline | Yes | Unknown | Unknown |
Ready for the Defender portal move | Planned | Not started | Not started |
Ingestion volume understood | Yes | Partly | No |
The available routes into Sentinel, and which source suits which.
Route
Solution from the Content Hub
- Best suited to
- Any source with a connector already published, since the detection content comes with it
Route
Service to service connector
- Best suited to
- The Microsoft services and Amazon Web Services, integrating as events happen
Route
Codeless Connector Framework
- Best suited to
- A source offering an API you can poll, leaving you no code to look after
Route
Logs Ingestion API in an Azure Function
- Best suited to
- Custom logic, transformation, or authentication the framework cannot express
Route
Logs Ingestion API in a Logic App
- Best suited to
- Light integration work where standing up an Azure Function would be overkill
Route
Syslog via Azure Monitor Agent
- Best suited to
- Network and Linux devices, landing in the Syslog table
Route
CEF via Azure Monitor Agent
- Best suited to
- Security appliances emitting CEF, landing in CommonSecurityLog
Route
Custom logs via the agent
- Best suited to
- Applications that do nothing but write log files, arriving in custom tables
Route
Azure Monitor Agent directly or Logstash
- Best suited to
- Custom connector scenarios outside the above
Route
Legacy HTTP Data Collector API
- Best suited to
- Nothing, after September 14, 2026
Five steps, of which the second saves more work than the other four together.
- 1
Inventory every path data takes into the workspace
Product connectors, service to service integrations, agents, forwarders, scripts and whatever a previous provider left behind, all of it. Every item gets attributed to a source, an owner, an ingestion method and a support tier, because a community-supported connector lists no support contact at all when it eventually breaks.
- 2
Map sources to what consumes them
We trace each source through to the analytics rules, workbooks and hunting queries that read it. A source nothing consumes is an ingestion bill delivering no security whatsoever, and switching it off is both cheaper and quicker than migrating it onto a supported ingestion route.
- 3
Migrate the legacy paths to supported routes
For a source exposing a suitable API, the Codeless Connector Framework. Where custom logic is genuinely required, the Logs Ingestion API driven by an Azure Function or a Logic App. Either way the migration is validated by confirming data is arriving in the expected table before anybody switches off the legacy path.
- 4
Add ingestion health monitoring
An alert fires when a source stops sending, configured per source rather than across the aggregate. That is what converts the characteristic silent failure of SIEM ingestion into something you detect, and it protects every single detection built on top of that data.
- 5
Plan the Defender portal transition
From March 31, 2027 the Defender portal is the only place Sentinel exists, and anyone still on the Azure portal gets redirected there. Your runbooks, saved links, training material and any automation written around the Azure portal all need revising. Doing that early turns a rushed change into a planned one.
What organizations ask about Sentinel data connectors.
Fifteen questions about your own Sentinel data.
Deadlines
- Does anything use the HTTP Data Collector API?Support ends September 14, 2026.
- Did a previous provider build integrations?Those are the likeliest candidates.
- Are we still using the Azure portal?Retired for Sentinel March 31, 2027.
- Do our runbooks link to the Azure portal?They will need updating.
- Have we planned the Defender portal move?There is a documented path.
Coverage
- Which sources are connected today?From evidence, not memory.
- Is the Defender XDR connector enabled?It brings four sources at once.
- Are connectors installed with their solutions?Solutions include detection content.
- What support tier is each connector?Community means no support contact.
- Which sources have no analytics rules?Ingestion with no detection.
Health
- Would we notice if a source stopped?Usually not.
- Do we alert on ingestion gaps?The fix for the above.
- When did each table last receive data?A one minute query.
- Do CEF sources land in CommonSecurityLog?Syslog goes to the Syslog table.
- Who owns connector health?Name them.
Take every table you depend on and find out when it last received anything.
One query per table, a minute apiece, and it surfaces every connector that stopped without mentioning it to anyone. Then check whether anything you built still runs on the HTTP Data Collector API, given support for it ends on September 14, 2026.
Related Services
Explore more solutions that work great with this service
Microsoft Sentinel Analytics Rules
Sentinel detection engineering for US organizations: every enabled
Learn moreMicrosoft Sentinel
Cloud-native SIEM and threat intelligence
Learn moreMicrosoft Sentinel Transition to the Defender Portal
Sentinel transition planning and delivery for US organizations ahead
Learn moreMicrosoft Sentinel SOC Optimization
Sentinel SOC optimization reviews for US organizations: ingestion
Learn moreKQL Threat Hunting Enablement
Advanced hunting and KQL enablement for US security teams: permission
Learn moreSOC-as-a-Service
24/7 security operations delivered as a service
Learn more