The Data Collector API Is Going Away: How to Migrate Your Azure Monitor Logs

If you run anything on Azure Monitor, you may have recently received an email like this:

Data Collector API will be retired on 14 September 2026 – transition to DCR-based custom log ingestion.

On 14 September 2026, we’ll retire the Data Collector API for ingesting custom logs to Azure Monitor logs. Before that date, you’ll need to transition to the Data Collection Rules based log ingestion API… While existing integrations may continue to function, support for the Data Collector API will be limited beyond this date.

It’s easy to skim past. But if your application ships its logs to a Log Analytics Workspace through a custom table, this one is about you. Here’s what it means and what to do about it.

Why This Is Happening

For years, the Data Collector API was the easiest way to get application logs into Azure Monitor. You POSTed some JSON to a Microsoft endpoint, authenticated with a shared workspace key, and your data showed up in a custom table with a _CL suffix. Done.

Easy, but not great. The shared key was a long-lived password sitting in your config. The table schema was inferred on the fly, so you had little control over it. And you couldn’t filter or reshape anything on the way in. Whatever you sent is what landed.

The newer Logs Ingestion API fixes all three. It authenticates with Entra ID tokens instead of a shared key, lets you define the table schema yourself, and can filter and transform records as they come in. It’s a better design, and as of next September it’s the only one Microsoft supports.

Does This Affect You?

It depends on how your logs reach the workspace today.

If you only use Azure Monitor for platform logs (Container Insights, AKS, VM diagnostics), you’re fine. Those already run on the modern Data Collection Rules pipeline. Nothing to do.

If you have an application writing to a custom _CL table, you’re in scope. And there’s one very common way teams got there.

The Serilog Case

Take a typical .NET service. It uses Serilog for structured logging, and somewhere in its config there’s a sink pointed at a Log Analytics Workspace, usually the old Serilog.Sinks.AzureAnalytics package. Every log line flows through Serilog, gets batched, and is POSTed into a custom table that your dashboards and queries read from.

That sink only speaks one protocol: the Data Collector API that’s being retired. The package isn’t actively maintained anymore, and the transport it relies on loses support on 14 September 2026. Your logs might keep flowing for a while after that, but with no guarantees and no one to call when they stop.

If that’s your setup, you have a decision to make. There are two good ways forward.

Option 1: Keep Serilog, Replace the Plumbing

You can keep everything about how your logs look today (the same Serilog pipeline, the same custom table, the same dashboards) and only swap out the transport underneath. This is the change-as-little-as-possible path.

The problem is there’s no ready-made Serilog sink for the new Logs Ingestion API. So “as little as possible” still means building and owning several pieces:

• A custom Serilog sink. You write the C# that batches events, gets Entra ID tokens, handles throttling and retries, and serializes each event into the shape the new API expects.
• A Data Collection Endpoint (DCE). A managed Azure resource that gives you an authenticated ingestion URL. Microsoft hosts it; you just create it.
• A Data Collection Rule (DCR). This is where the work happens. It declares the incoming schema, optionally transforms each record, and routes the result into your table.
• A custom table plus the schema mappings. This is the part that trips people up. The mapping lives in two places that have to stay in sync: your sink’s JSON and the DCR’s stream declaration. Change a column in one and forget the other, and rows just vanish at ingestion with no error.

The payoff is that your historical data, queries, and dashboards keep working untouched. The cost is that you now own a hand-written sink and a few pieces of Azure infrastructure, indefinitely, so that you don’t have to change your logs.

Option 2: Move to Application Insights and Stop Maintaining Plumbing

The other path asks a more basic question: why are we hand-building a logging transport at all?

For new .NET work, Microsoft points you to the Azure Monitor OpenTelemetry Distro exporting to a workspace-based Application Insights resource. You drop Serilog’s Azure sink, add the distro, point it at a connection string, and you’re done. It authenticates with your existing workload identity. No DCE to create, no DCR to keep in sync, no custom sink to maintain. Microsoft owns the whole ingestion path and the schema.

You also come out ahead. Because it’s OpenTelemetry, the same pipeline that carries your logs also carries traces, metrics, and dependency calls. You can follow a request’s full timeline, catch an N+1 query, and tie a log line back to the exact operation that produced it. The Serilog-only setup never gave you that.

The catch: your logs move from a custom _CL table into Application Insights’ standard tables (AppTraces, AppExceptions, and the rest). That’s a schema change, so you’ll rewrite the queries and dashboards built on the old shape. You pay that once, and in return you delete a pile of code and infrastructure you’d otherwise maintain forever.

Which One to Pick

If you’re heavily invested in custom-table dashboards and have to keep that exact schema, Option 1 leaves everything in place. Just go in knowing you’re signing up to own a sink and three Azure resources.

For most teams, Option 2 is the better long-term call. Less code, less infrastructure, and a path Microsoft is actively investing in, plus a real step up in observability. You take a one-time dashboard rewrite and end up with less to maintain than you have now.

Either way, the date is 14 September 2026, and the one option that isn’t on the table is doing nothing. Need help moving off the Data Collector API, or getting more out of Azure Monitor in general? Trailhead can help you pick the right path. Contact us to find out more.