Azure AI Retirements: Metrics Advisor Ends, Others October 1, 2026

Azure AI Metrics Advisor is already retired, while Azure AI Anomaly Detector and Azure AI Personalizer remain available only until October 1, 2026; the practical response is to inventory every endpoint and caller now, then rebuild the monitoring, scoring, or ranking function each application actually depends on.
Microsoft’s retirement guidance distinguishes the services clearly: Metrics Advisor’s portal was disabled on March 31, 2026, and the service retired on May 18, 2026. Anomaly Detector and Personalizer are scheduled to retire on October 1, 2026. Because new resources for these services stopped being available in 2023, a cutover plan cannot assume that a fresh retiring-service resource can be created as a fallback.
WindowsForum readers discussing overlooked Microsoft infrastructure—including the operational role of IIS, WSUS, and Windows Server components—have highlighted a familiar problem: the dependency that receives the least attention can carry the most day-to-day operational weight. These AI services may look like narrow API integrations, yet they can sit behind alerts, dashboards, scheduled jobs, analyst review, or customer-facing decisions. Treat this as an application and operations migration, not a package swap.

Choose the replacement by workload, not by service name​

The first decision is not “Which Microsoft product replaces this service?” It is “What job was the service performing?”

• Metrics Advisor users need a monitoring-and-investigation rebuild. The retired service may have been part of a larger path from data feed to anomaly review and operational response.
• Anomaly Detector users need a scoring replacement. Focus on the time-series inputs, expected outputs, calling behavior, and how the application handles uncertain or failed scoring.
• Personalizer users need a ranking-and-reward-loop replacement. Preserve the decision contract: actions, context, rewards, constraints, and safe behavior when ranking is unavailable.

Microsoft lists Azure Monitor, Microsoft Fabric, and Microsoft open-source projects as migration destinations in different scenarios. That destination list is useful for starting evaluation, but it is not evidence of feature-for-feature equivalence.

Retiring workload	Microsoft-listed destination	Appropriate evaluation question	What the team must define
Metrics Advisor	Azure Monitor	Can the organization rebuild the monitoring and investigation process around its own telemetry?	Data collection, detection approach, alert ownership, investigation process, and operational documentation
Metrics Advisor	Microsoft Fabric	Does the organization want to evaluate an analytics-oriented destination for its historical or operational data?	Data workflow, analysis ownership, output handling, notifications, and support model
Metrics Advisor	Open-source microsoft/anomaly-detector	Can the project meet the organization’s technical and operational requirements after review and testing?	Hosting, integration, security, lifecycle ownership, monitoring, and failure handling
Anomaly Detector	Microsoft Fabric	Does a Fabric-based evaluation fit the application’s data and analytics needs?	Input pipeline, scoring process, result storage, caller integration, and operational response
Anomaly Detector	Open-source microsoft/anomaly-detector	Can the project be evaluated as a possible basis for a replacement scoring path?	Deployment, authentication, capacity, application contract, and fallback behavior
Personalizer	Open-source microsoft/learning-loop	Can the project be evaluated as a starting point for the organization’s ranking and learning-loop requirements?	Action and context definitions, reward collection, safeguards, evaluation, model ownership, and deterministic fallback ranking

Metrics Advisor, Anomaly Detector, and Personalizer should not be treated as interchangeable merely because all three involve AI-assisted decisions. Metrics Advisor users need to reconstruct an operating model around monitoring data and investigation. Anomaly Detector users need to validate scoring behavior against representative data. Personalizer users need to preserve a feedback-driven decision system, including the business rules that prevent unsafe or unsuitable recommendations.

Run an executable dependency inventory​

The following is a proposed discovery playbook from an operational perspective. It is not Microsoft-documented service-specific migration procedure. Its purpose is to produce evidence about where the retiring services are used before any replacement decision is made.

1. Build a resource and ownership list​

Start with the organization’s existing cloud inventory, subscription records, resource groups, application registers, billing records, and service ownership documentation. Look for names that include or resemble:

• anomaly
• personalizer
• metricsadvisor
• cognitiveservices
• Team-specific abbreviations for recommendation, forecasting, alerting, quality, or incident workflows

For every possible resource or endpoint, record:

1. Resource or endpoint identifier
2. Subscription, tenant, or account boundary
3. Environment: production, staging, development, test, or sandbox
4. Technical owner and business owner
5. Application, job, or service believed to call it
6. Authentication method and where its configuration is maintained
7. Last known deployment or configuration change
8. Whether the dependency is still active, uncertain, or confirmed unused

Do not place credentials, API keys, tokens, or secret values in a migration spreadsheet. Record only the approved secret location, the responsible owner, and the rotation or access-review status.

2. Search for endpoint and configuration references​

Search application repositories, infrastructure repositories, deployment definitions, environment-variable templates, and CI/CD configuration for known resource names, endpoint hostnames, and service-related terms. Useful search terms include:

• anomalydetector
• personalizer
• metricsadvisor
• cognitiveservices.azure.com
• ENDPOINT
• API_KEY
• SUBSCRIPTION_KEY
• Organization-specific configuration names for scoring, recommendations, alerts, or data feeds

Also inspect configuration systems and secret-management records used by the organization. The goal is not simply to find a key reference; it is to identify the caller behind it. A secret can survive long after the consuming application has changed, while an active dependency can be hidden behind a generic configuration name.
Include scheduled and indirect callers. Batch jobs, integration processes, data pipelines, notebooks, workflow automations, serverless jobs, and background workers often contain the dependencies that are absent from the main application repository. If a service was called only once per day or only during a business event, normal application traffic review may miss it.

3. Identify the business role of every caller​

For each confirmed caller, document:

Question	Evidence to capture
What sends the request?	Application, job, pipeline, workflow, or user-facing feature
What is the input?	Schema, timing, volume, data quality assumptions, and sensitive-data classification
What is returned?	Score, anomaly result, ranking output, decision, or downstream trigger
Who uses the result?	Customer-facing feature, operations team, analyst, product team, or automated process
What happens on failure?	Retry, queue, hard error, manual review, static result, or silent omission
What happens when results look wrong?	Escalation owner, review process, suppression process, and correction path
What must be preserved?	Accuracy expectation, latency target, audit evidence, safety constraint, or business rule

This step frequently changes the migration plan. A caller initially described as “anomaly detection” may actually be a dashboard annotation workflow with no automated action. Another may be a high-impact decision point where an unavailable or incorrect result must trigger a safe fallback immediately.

Rebuild the operational contract​

A replacement is ready only when it satisfies the operational contract around the retiring service, not merely when it produces output in a test environment.
For a Metrics Advisor migration, document the complete path from incoming data to human or automated response. Identify who reviews unusual results, how they distinguish known events from genuine problems, where investigation context comes from, and how alerts are suppressed, acknowledged, or escalated. Since Metrics Advisor is already retired, the migration plan must include a degraded or manual operating mode. There is no valid assumption that traffic can be returned to Metrics Advisor during a failed cutover.
For an Anomaly Detector migration, preserve representative time series and known outcomes. Include normal seasonal behavior, known anomalies, missing values, malformed inputs, sparse periods, and sudden changes in volume. Compare the replacement against the business expectation, not only against a single numerical threshold. If the score drives an automated action, define when automation pauses and a human review process takes over.
For a Personalizer migration, write down the ranking contract before implementing anything new:

• The approved action set
• Context features and their data sources
• The reward event and when it is recorded
• Business constraints, eligibility rules, and exclusions
• User-safety, fairness, privacy, and compliance requirements
• Evaluation method and approval process for changes
• Deterministic fallback ranking when the replacement is unavailable or untrusted

The fallback is not an afterthought. For many Personalizer scenarios, a fixed rules-based ranking, a curated default, or no recommendation at all may be safer than continuing to make unvalidated decisions.

Evaluate destinations with controlled tests​

Microsoft’s listed destinations should be evaluated through a limited, evidence-based pilot. Do not begin with a production cutover.
For Microsoft Fabric or an open-source project, review the project or platform documentation directly for the version, prerequisites, licensing, security model, supported deployment approach, and maintenance expectations that apply to the chosen implementation. Assign named owners for data access, environment administration, code changes, security review, logging, incident response, and support escalation before declaring the pilot viable.
Use representative non-production data where possible. Test normal behavior, expected edge cases, malformed input, delayed input, unavailable dependencies, and load consistent with the actual application. Record what the replacement does, what operators see, and how the application behaves when a result is late, absent, or unexpected.
For Metrics Advisor workloads, test the investigation experience as carefully as the detection result. A team needs a documented answer to: “An alert or unusual result occurred—what does the on-call person do next?” If the answer depends on undocumented tribal knowledge, the migration is incomplete.

Cutover checklist​

Owner	Artifact	Validation criterion	Fallback or rollback action
Application owner	Caller inventory and dependency map	Every production caller has an owner and documented replacement path	Disable the new path if necessary and use the documented application fallback
Platform owner	Replacement deployment record	Access, network controls, health checks, logging, and support ownership are validated	For Anomaly Detector or Personalizer, revert traffic to the prior path only where it remains available; otherwise use degraded mode
Data or analytics owner	Representative test data and comparison record	Normal conditions, known events, malformed inputs, and failure cases are tested	Pause automated processing and move results to manual review
Operations owner	Runbook and escalation evidence	The responsible team can investigate, acknowledge, and escalate an issue	Use the documented temporary monitoring and manual investigation process
Product owner	Personalizer safety and fallback specification	Ranking remains within approved constraints when the new loop fails	Use approved static, curated, or rules-based ranking
Metrics Advisor owner	Degraded-mode procedure	Operators can continue essential review without the retired service	Use manual monitoring and investigation procedures; do not plan a rollback to Metrics Advisor

Metrics Advisor customers should prioritize a working degraded mode while rebuilding the monitoring and investigation path. Anomaly Detector and Personalizer customers still have time to validate a replacement before October 1, 2026, but they should not spend that time assuming the existing endpoint will remain a usable fallback indefinitely.

Frequently Asked Questions​

Is Metrics Advisor still available until October 1, 2026?​

No. Metrics Advisor retired on May 18, 2026, after its portal was disabled on March 31, 2026. October 1, 2026 applies to Anomaly Detector and Personalizer.

Does Azure Monitor replace every Metrics Advisor feature?​

Microsoft lists Azure Monitor as a migration destination, but teams should not assume feature-for-feature equivalence from that listing alone. Metrics Advisor users need to define and test their own monitoring, investigation, escalation, and operational workflows.

What should we preserve from Anomaly Detector?​

Preserve representative time series, known anomalies, input schemas, scoring expectations, caller behavior, and failure handling. Use that material to test the replacement rather than assuming similar API output means equivalent operations.

What is essential to preserve from Personalizer?​

Document the action set, context features, reward event, reward timing, business constraints, evaluation method, and safe fallback ranking. Those are the decision-loop contract that the replacement must honor.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Provide anomaly feedback to the Metrics Advisor service - Azure AI services | Microsoft Learn

   Learn how to send feedback on anomalies found by your Metrics Advisor instance, and tune the results.

   learn.microsoft.com