Azure Anomaly Detector and Personalizer retire October 1, 2026: a migration playbook

Summary. Azure AI Anomaly Detector and Azure AI Personalizer both retire on October 1, 2026, and after that date their API endpoints, trained models and configurations are deleted with no extension period and no legacy mode. A third service in the same family, Metrics Advisor, already retired on May 18, 2026, after its portal was disabled on March 31, 2026. You have not been able to create new resources for any of them since September 20, 2023, so a fresh instance is not a fallback. Microsoft points Anomaly Detector users to Microsoft Fabric and the open-source time-series-anomaly-detector package, and Personalizer users to the open-source microsoft/learning-loop project or Azure Machine Learning. Fabric capacity starts at about $0.36 per hour for an F2 SKU, roughly $263 a month always-on. This guide gives the dates, the destination for each service, and the migration steps.

If your production system calls one of these three endpoints, the clock is real. This is not a deprecation warning that quietly extends year after year. Microsoft has confirmed there is no extension and no legacy mode, which means a scheduled job or an app that still hits the Anomaly Detector REST API on October 2, 2026 gets an error, not a grace period. The teams that get hurt are the ones that treated a managed AI service as permanent infrastructure and never wrote down where the dependency lived.

Microsoft's Anomaly Detector documentation states plainly that the service "is being retired October 1, 2026," and that from September 20, 2023 "you won't be able to create new Anomaly Detector resources." Read literally, that second sentence is the more dangerous one: it means the usual escape hatch of spinning up a clean resource to buy time is already closed. The only safe move is a real migration to a supported replacement, and the replacement differs for each service.

The three retirements, with accurate dates

The three services are often grouped because they retired in the same window, but the dates are not identical, and one has already passed. Treat them separately.

The practical read: if you still run Anomaly Detector or Personalizer, you have until October 1, 2026 to cut over. If you ran Metrics Advisor, the decision was already made for you, and the lesson is to not repeat the pattern with the other two.

Migrating Anomaly Detector to Microsoft Fabric

Anomaly Detector has the cleanest path because Microsoft rebuilt its core as open source and folded it into Microsoft Fabric. Fabric ships a package called time-series-anomaly-detector that replicates the functionality of the retired service. It runs multivariate anomaly detection on Spark with inline Python, integrates with Eventhouse for real-time data ingestion, supports training custom models, deploys them with MLflow, and exposes predictions through KQL functions. In other words, the algorithm you relied on is preserved, but the hosting model changes from a metered REST endpoint to a data-engineering workload you run inside your own Fabric capacity.

The migration is a rebuild, not a config change, and it follows a set sequence. Log in to Microsoft Fabric and create a workspace. Create an Eventhouse to store the streaming or historical series you want to score. Enable OneLake availability so older data is reachable for training. Enable the KQL Python plugin so you can run inline Python for real-time scoring. Then create a Spark environment with the time-series-anomaly-detector package installed. From there you retrain on your historical data and repoint your application at the new prediction path.

A minimal Spark setup for the replacement package looks like this:

            # In a Microsoft Fabric notebook (Spark environment)
# Install the open-source replacement for Azure AI Anomaly Detector
%pip install time-series-anomaly-detector

from anomaly_detector import MultivariateAnomalyDetector

model = MultivariateAnomalyDetector()
# train_df: a Spark/pandas frame of your historical multivariate series
model.fit(train_df, window_size=28)
scores = model.predict(live_df)   # anomaly scores you can threshold and alert on
          

The cost model changes with the hosting model. Instead of paying per API call, you pay for Fabric capacity. An F2 SKU runs about $0.36 per hour, roughly $263 a month if left always-on or about $156 a month on a reservation, while a large F64 capacity is about $8,410 a month pay-as-you-go or about $4,982 reserved. Reservations cut roughly 37 percent for a one-year commitment and 52 percent for three years. For a low-volume anomaly job, an always-on F2 is usually overkill; you can run detection on a schedule and pause capacity between runs so you are not paying for idle compute.

Migrating Personalizer to learning-loop or Azure Machine Learning

Personalizer is a reinforcement-learning service: it takes a context and a set of possible actions, returns the action most likely to earn a reward, and learns from the reward feedback your application sends back in near-real time. There is no drop-in managed replacement, so this migration is more involved than Anomaly Detector's.

Microsoft's recommended path is the open-source microsoft/learning-loop project on GitHub, described as a "Joiner and Trainer for online reinforcement learning loop." It reproduces the two hard parts of Personalizer: joining actions to their delayed rewards, and training the ranking model online. You host it yourself, which gives you control over where the data sits and how the model updates, at the cost of owning the infrastructure. The alternative is to implement the same contextual-bandit logic in Azure Machine Learning, which suits teams that already run training pipelines there and want managed compute rather than a self-hosted loop.

Whichever you pick, budget engineering time, not just a code swap. Personalizer hid a real amount of machine-learning plumbing behind a simple API. Rebuilding it means re-implementing reward attribution, exploration settings and model evaluation, then validating that the new loop makes decisions at least as well as the old service did before you cut traffic over.

Metrics Advisor: the one that already lapsed

Metrics Advisor is the cautionary example. It retired on May 18, 2026, after Microsoft disabled its portal on March 31, 2026. Microsoft lists Azure Monitor as a destination, but there is no feature-for-feature equivalent, and the product team did not name a like-for-like replacement service. Teams that depended on its automated multi-dimensional metric monitoring have had to rebuild that capability on Azure Monitor, on the same Fabric time-series tooling used for Anomaly Detector, or on a third-party product.

If you still have Metrics Advisor resources lingering from before the retirement, treat them as already dead: export any configuration you need for reference, then rebuild the monitoring and root-cause path on a supported platform rather than hoping for a degraded mode that will not return.

A migration timeline that fits before October 1

The failure mode is starting in September. Work backward from October 1, 2026 with margin. A workable sequence is to complete discovery within the first three months, stand up a working replacement prototype within six months, and run both systems in parallel before decommissioning the old one. Discovery means finding every caller: grep your codebase and infrastructure for the Anomaly Detector and Personalizer endpoints, list the scheduled jobs and apps that hit them, and note which are business-critical.

Validate the replacement before you cut traffic

A migration is only done when the new path makes the same decisions the old one did and you can prove it. Run the old and new systems in parallel on the same live data, then compare, rather than trusting a one-off test.

For Anomaly Detector on Fabric, feed the identical historical series into the time-series-anomaly-detector package and check that it flags the same points the retired service did. Microsoft's guidance is that the Fabric package uses the same algorithms as the old service, so on clean data the anomaly timestamps should line up. Where they diverge, tune the training window and sensitivity before you trust the new alerts. Keep the old endpoint scoring in shadow mode until the counts match for a full business cycle, including a month-end or a known spike, so you are not comparing two quiet weeks.

For Personalizer on learning-loop, comparison is harder because the service learns online, so two loops will not produce identical decisions. Measure the reward instead. Run the new loop on a slice of live traffic, track the average reward it earns against the old service on the rest, and shift the majority of traffic only once the new loop matches or beats the incumbent over a meaningful window. Re-create the exploration setting and reward-wait time you used before, since those, not the model alone, drive the results.

Two mistakes catch teams here. The first is mishandling the delayed reward: personalization rewards often arrive minutes or hours after the decision, and a loop that joins them incorrectly looks worse than it is. The second is under-sizing capacity during the parallel run, then blaming the model when a starved Fabric SKU cannot keep up. Size the capacity to the real load before you judge the output.

India-specific considerations

For teams in India, two points sharpen the plan. First, control over data location improves. A managed Azure AI endpoint processed your series or contexts inside Microsoft's service; a self-hosted learning-loop or a Fabric workload you own lets you keep personal data inside a chosen region, which is easier to reconcile with the Digital Personal Data Protection Act 2023 (DPDP) and its residency expectations. Design the replacement so personal data used for personalization or anomaly scoring stays within a permitted boundary.

Second, budget in rupees with the hosting shift in mind. Moving from per-call pricing to Fabric capacity means a predictable monthly line rather than a variable one: an always-on F2 at about $263 a month is roughly Rs 22,000, while a reservation lowers it. For a low-volume workload, schedule the capacity rather than running it around the clock, and size it to the job instead of defaulting to a large SKU.

How eCorpIT can help

eCorpIT is a Gurugram-based, ISO 27001:2022-certified engineering organisation that runs cloud service migrations end to end. Our senior engineers inventory every call to the retiring Azure AI services, rebuild anomaly detection on Microsoft Fabric or reinforcement-learning personalization on learning-loop or Azure Machine Learning, and run the old and new systems in parallel so the cutover is safe. If you have an Anomaly Detector or Personalizer dependency to move before October 1, 2026, talk to us at /contact-us/.

FAQ

References

1. What is Anomaly Detector? — Microsoft Learn

1. Anomaly Detector deprecation notice — Microsoft Docs (GitHub)

1. Azure Anomaly Detector is retiring in 2026: how to prepare — Windows News

1. Multivariate anomaly detection with Foundry Tools in Microsoft Fabric — Microsoft Learn

1. Advanced time series anomaly detector in Fabric — Microsoft Community Hub

1. What is Personalizer? — Microsoft Learn

1. microsoft/learning-loop — GitHub

1. Alternatives to retiring AI Services Personalizer — Microsoft Q&A

1. Azure AI retirements: Metrics Advisor ends, others October 1, 2026 — Windows Forum

1. Time series analysis tools to replace Metrics Advisor — Microsoft Q&A

1. Microsoft Fabric pricing: 2026 SKU and cost guide — AlphaVima

1. Save costs with Microsoft Fabric capacity reservations — Microsoft Learn

_Last updated: 3 August 2026._