Microsoft has set September 14, 2026, as the end-of-support date for both Azure Functions version 1.x and the older HTTP Data Collector API that feeds logs into Azure Monitor. That gives teams two years to move function apps to version 4.x and rework any custom telemetry pipelines that still rely on the retiring ingestion endpoint.

What's Changing

Azure Functions 1.x will stop receiving security updates, non-security patches, and assisted support on September 14, 2026. Microsoft's lifecycle policy treats that as a hard cutoff: after that date, any function app still pinned to the 1.x runtime is officially unsupported. The recommendation is to upgrade to version 4.x, which runs on .NET 6 and later, supports more triggers, and benefits from ongoing investments.

On the same day, the legacy HTTP Data Collector API—often used by scripts, on-premises services, and function apps to push custom logs into Log Analytics workspaces—will also be retired. Microsoft is steering users toward the Logs Ingestion API, a newer pipeline built around Data Collection Rules (DCRs). Instead of a simple HTTP post with a workspace ID and shared key, the modern approach defines a rule that specifies how incoming data is transformed and which table it lands in.

The shared deadline means that some workloads will need both a runtime upgrade and a logging pipeline redesign. A function app running on version 4.x isn't automatically shielded if its code—or a downstream component it calls—still sends logs through the old collector endpoint.

Who Is Affected

If you manage any of these, the clock is ticking:

  • Developers with older serverless apps: Any Function App whose FUNCTIONS_EXTENSION_VERSION setting shows ~1 or 1.x must be modernized. These apps were often built years ago on .NET Framework 4.x or early Node.js runtimes and may have accumulated technical debt.
  • IT administrators and site reliability engineers: Custom monitoring setups that rely on PowerShell scripts, scheduled tasks, CI/CD pipelines, or legacy deployment tools to send telemetry to the HTTP Data Collector API need to switch to the Logs Ingestion API. The sender might not even be a function—it could be a script running on a Windows Server, a SQL Agent job, or an external SaaS tool.
  • Observability teams: Alerts, workbooks, and saved queries that depend on the exact schema of those custom logs must be revised. A naive cutover could break dashboards and incident response routines.

Microsoft's documentation confirms that the Logs Ingestion API uses Azure AD authentication and DCRs, which require more upfront configuration than the old shared-key method. That is by design: the new approach gives you control over transformations and destinations, but it demands a more deliberate setup.

How We Got Here

Azure Functions 1.x launched in 2016 as part of the initial serverless offering. It targeted the .NET Framework runtime and had a different architecture from later versions. Version 2.x, released in 2018, moved to .NET Core and a new host model, marking a clean break. Microsoft continued to support 1.x for years, but the product team has been clear that version 4.x is the long-term replacement—it unifies the programming model and aligns with current .NET and Linux container support.

The HTTP Data Collector API dates back even earlier, before Azure Monitor rebranded from Log Analytics. It was a simple, widely adopted way to ingest custom data, but its static key-based authentication and lack of schema enforcement became limitations. Microsoft introduced the Logs Ingestion API in 2021 alongside the Azure Monitor Agent, promising finer-grained access control and transformation capabilities via DCRs. The 2026 retirement formalizes the end of the old approach.

The two-year notice aligns with Microsoft's Modern Lifecycle Policy, which requires at least 12 months of advance notice for feature retirements. The September 2026 date was first published on Microsoft's product lifecycle page, though the exact day may appear earlier for some regions.

What You Should Do Now

Treat this as a migration project with two interconnected workstreams: one for the functions themselves, one for the logging plumbing.

1. Discover Your 1.x Functions

Run an inventory across all subscriptions. Use the Azure portal, CLI, or PowerShell to list function apps and filter by FUNCTIONS_EXTENSION_VERSION. The exact query might look like:

Get-AzFunctionApp | ForEach-Object {
    $settings = Get-AzFunctionAppSetting -Name $_.Name -ResourceGroupName $_.ResourceGroupName
    if ($settings["FUNCTIONS_EXTENSION_VERSION"] -match "1") {
        $_
    }
}

Record owner, business purpose, trigger type, and deployment source. Not every app needs to be saved—some may be unused or have been replaced by other services.

2. Find Every Data Collector API Caller

The old endpoint looks like this:

POST https://<workspace-id>.ods.opinsights.azure.com/api/logs?api-version=2016-04-01

Scan code repositories, script libraries, SQL Agent job steps, Windows Task Scheduler tasks, and any automation that can reach the internet. Look for workspace IDs, shared keys, and references to ods.opinsights.azure.com. Even scripts that wrap a curl or Invoke-RestMethod call must be tracked down.

Don't assume your function apps are the only callers. A scheduled task on an old management server might be silently pushing logs, and nobody will remember it until the ingestion stops.

3. Plan the Function Upgrade

For each function app that you decide to keep:

  • Create a branch and a deployable test environment.
  • Verify the code compiles and publishes against the version 4.x runtime. This may involve updating bindings, fixing deprecated APIs, or changing the target framework.
  • Run functional tests with each trigger—HTTP, timer, queue, etc.—and confirm expected output.
  • Schedule a maintenance window to switch the FUNCTIONS_EXTENSION_VERSION setting to ~4 in production, after a successful deployment.

Microsoft provides an Azure CLI command to help:

az functionapp config appsettings set \
  --resource-group <resource-group> \
  --name <function-app-name> \
  --settings FUNCTIONS_EXTENSION_VERSION=~4

But never run that without a full backup and rollback plan.

4. Design the Logs Ingestion Replacement

For each Data Collector API sender, you'll need to create a Data Collection Rule. The workflow:

  • Document the JSON payload fields the sender currently transmits.
  • Identify the destination workspace and table.
  • In the Azure portal, navigate to Azure Monitor > Data Collection Rules and create a new rule.
  • Configure the data source (custom logs), transformation (if needed), and destination table.
  • Save the rule and note its immutable ID.

For automation, you can define the rule in JSON and deploy it with the CLI:

az monitor data-collection rule create \
  --resource-group <resource-group> \
  --name <dcr-name> \
  --location <region> \
  --rule-file <dcr-definition.json>

The rule file must specify the stream name, transformation KQL, and output table. After the DCR is in place, update the sender to use the new Logs Ingestion API endpoint (https://<dataCollectionEndpoint>/dataCollectionRules/<dcrImmutableId>/streams/Custom-<table>?api-version=2021-11-01-preview) with Azure AD authentication.

5. Validate and Cut Over

Where possible, run the old and new log pipelines in parallel for a defined test period. Compare records: ensure all required fields arrive, timestamps are consistent, and no data is lost or malformed. Update alerts, workbooks, and saved queries to reference the new table schema if it changed.

Assign clear ownership for each migration artifact—function app, DCR, sender update—and for the final cutover decision. After the old endpoint is disabled, document the new configuration and support contacts.

What Happens If You Miss the Deadline

After September 14, 2026, Microsoft will not guarantee that Azure Functions 1.x workloads will run. While historically Azure has not immediately pulled the plug on unsupported services, continued operation is risky: you'll have no SLA, no patches for vulnerabilities, and no path to support if something breaks.

The Data Collector API may simply stop accepting requests. In similar past retirements, Microsoft has sometimes allowed a grace period, but it should not be relied upon. If your monitoring pipeline goes dark, incident response, compliance reporting, and business analytics could fail without warning.

Looking Ahead

The two-year window is generous by cloud standards, but the complexity of the migration shouldn't be underestimated. Organizations with dozens of functions and scattered logging scripts will need dedicated cycles. The shift to DCR-based ingestion is an architectural improvement that brings better security and data governance, but it requires learning a new model.

Microsoft is likely to publish more prescriptive tooling and migration guides as the date approaches. Keep an eye on the Azure Updates page and the application insights blog for accelerators. In the meantime, start the discovery process now—the hardest part is often finding all the pieces before you can fix them.