Azure Anomaly Detector retires on October 1, 2026 — here are all your migration options

Updated July 2026 · 7 min read

Microsoft is shutting down the Azure AI Anomaly Detector service on October 1, 2026. New resources have been blocked since September 2023; existing resources stop working on the retirement date. If your alerting, monitoring, or IoT pipeline calls the /anomalydetector/v1.1 API, you need a migration plan — ideally with enough buffer to test before the deadline.

This guide compares every realistic option, including the ones that don't involve us.

Disclosure: this guide is published by Anomatik, one of the drop-in replacement options listed below. We've tried to keep the comparison honest — including when another option is the better fit for you.

Your options at a glance

Option	Effort	Best when…	Watch out for
Microsoft Fabric (time-series-anomaly-detector package)	High	You already use Fabric/Eventhouse and want to stay all-Microsoft	Not an HTTP API — you rewrite your integration as Spark/Python code; Fabric capacity pricing
Open-source engine (microsoft/anomaly-detector on PyPI)	Medium–High	You have Python infrastructure and want zero license cost	You own hosting, scaling, monitoring, and updates; heavy dependency chain (incl. PyTorch for multivariate)
Azure Stream Analytics / Data Explorer	Medium	Your data already flows through these services	Different programming model (SQL functions, not a REST call); results differ from the old API
Drop-in API replacement (Anomatik, Canary Edge)	Minimal	You want your existing integration to keep working unchanged	Third-party dependency; check data residency and pricing
Build your own (Prophet, PyOD, statsmodels…)	High	Anomaly detection is core to your product and you have DS capacity	Months of effort for something that was one API call

Option 1: Microsoft Fabric — the official path

Microsoft's recommended migration is to Microsoft Fabric, which integrates the same algorithms via the time-series-anomaly-detector package, running as Spark or inline Python against Eventhouse. If your organization is already invested in Fabric, this keeps everything under one roof and adds multivariate detection.

The catch: it is not an API. The old integration — POST a JSON series, get flags back — has no direct equivalent. You'll re-implement your detection step inside notebooks or pipelines, and you pay for Fabric capacity, which is a very different cost model from per-transaction pricing. For a team that only ever used the REST endpoint, this is the heaviest migration on the list.

Option 2: Run Microsoft's open-source engine yourself

Microsoft open-sourced the detection engine (PyPI: time-series-anomaly-detector). It's genuinely the same math that powered the service, and it's free. If you have a Python service anyway, you can import it and detect locally.

Budget for the operational reality: the package pulls a large dependency chain (PyTorch and MLflow for the multivariate part), you'll wrap it in your own service for HTTP access, and you own uptime, scaling, and security patching from then on. "Free" here means "free like a puppy".

Option 3: Stream Analytics or Azure Data Explorer

Both offer built-in anomaly functions (AnomalyDetection_SpikeAndDip, series_decompose_anomalies()). If your telemetry already lives there, using the native functions is pragmatic. But it's a different paradigm — SQL-style functions over streams instead of a stateless REST call — and the detection results won't match the old API exactly, so re-tune your thresholds and alerts.

Option 4: Drop-in API replacements

If your goal is "keep everything working, change as little as possible", a compatible third-party API is the shortest path. Your code, SDK calls, parsing, and dashboards stay untouched — you swap the endpoint URL and the API key:

# before
https://<resource>.cognitiveservices.azure.com/anomalydetector/v1.1/timeseries/entire/detect
# after
https://api.anomatik.de/anomalydetector/v1.1/timeseries/entire/detect

Two services currently offer this:

Anomatik (that's us) — EU-hosted (Germany), GDPR-focused, built for sensor/IoT data. Detection quality is benchmarked at 99% flag agreement with Microsoft's open-source engine; payloads are processed in memory and never stored. Private beta with free migration help — waitlist here.
Canary Edge — US-based drop-in replacement with the same API contract. If EU data residency doesn't matter to you, compare both and pick per pricing/latency.

Migration tip regardless of vendor: while your Azure resource still works (until Oct 1), run the same series through Azure and the replacement in parallel and diff the results. We provide an open comparison script that does exactly that — ask us for it, it works against any endpoint.

Option 5: Build your own

Prophet, PyOD, statsmodels, or a hand-rolled seasonal-decomposition + robust-scoring pipeline can absolutely replicate what the API did — we know, because that's essentially what we built. Realistically it's weeks to months of work to get edge cases right (seasonality detection, margins, sensitivity semantics), plus permanent ownership. Worth it only if anomaly detection is a core differentiator of your product.

Decision guide

Deep in the Fabric ecosystem already → Option 1.
Python shop, ops capacity, zero budget → Option 2.
Data already in ASA/ADX → Option 3.
You just want your existing integration to keep working → Option 4 (EU: Anomatik, US: Canary Edge).
Anomaly detection is your core product → Option 5.

Whatever you choose: don't wait until September. The teams that migrate calmly in July and August get to A/B-test against the live Azure API while it still exists — that option disappears forever on October 1, 2026.