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:
anomalypersonalizermetricsadvisorcognitiveservices- Team-specific abbreviations for recommendation, forecasting, alerting, quality, or incident workflows
For every possible resource or endpoint, record:
- Resource or endpoint identifier
- Subscription, tenant, or account boundary
- Environment: production, staging, development, test, or sandbox
- Technical owner and business owner
- Application, job, or service believed to call it
- Authentication method and where its configuration is maintained
- Last known deployment or configuration change
- 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:
anomalydetectorpersonalizermetricsadvisorcognitiveservices.azure.comENDPOINTAPI_KEYSUBSCRIPTION_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.
