Microsoft has confirmed that Azure Anomaly Detector will reach end of life on October 1, 2026. The service, which provides AI-driven anomaly detection for time-series data, will no longer be supported or available after that date. Any application, script, or process still calling the API by then will break without a migration plan in place.

What’s Happening to Azure Anomaly Detector

The retirement notice appears on Microsoft’s official product lifecycle page. While the company hasn’t publicly detailed the reasons behind the decision, it is consistent with Azure’s ongoing consolidation of cognitive services. After October 1, 2026, Azure Anomaly Detector will cease operations. This means both the cloud-hosted API and any self-hosted container images distributed by Microsoft will stop working, and Microsoft will remove the service from its portfolio. There will be no extended support period.

For teams that have embedded the service into production workloads, the 18-month runway is both generous and alarmingly short. The largest challenge isn’t just finding a replacement—it’s uncovering where and how the service is actually used.

Who Needs to Take Action

If your organization has ever experimented with Anomaly Detector, you may have forgotten about it. The service could be buried in a proof-of-concept, a long-running data pipeline, a forgotten test harness, or a critical production monitoring tool. IT administrators, cloud architects, developers, and data engineers all share responsibility for identifying dependencies. Even if you believe your team never adopted it, a thorough audit is necessary because a single misconfiguration or orphaned resource can cause unexpected failures.

The Hidden Risk: Dependencies Are Everywhere

Unlike a virtual machine that can be spotted in the Azure portal, an API-based cognitive service can be called from anywhere—a Python script running on a developer’s laptop, a GitHub Actions workflow, an Azure Function, or a Kubernetes pod. Credentials might be stored in Azure Key Vault, environment variables, or CI/CD secrets. Anomaly Detector also supports containerized deployment, meaning your team could be hosting its own instance outside of Azure’s management plane entirely.

Microsoft’s Azure Advisor can surface some retirement recommendations, but it only sees resources within the subscriptions and scopes your account can access. It won’t find a hard-coded endpoint in a legacy batch file or a secret in a third-party secrets manager. Therefore, a manual, multi-pronged discovery process is necessary.

How to Prepare: A Practical Migration Blueprint

1. Start with Azure Advisor

Navigate to Azure Advisor in the portal and review “Service Upgrade and Retirement” recommendations. If Anomaly Detector resources are detected, record the affected resource IDs, subscriptions, and associated metadata. Export the recommendations or take screenshots for your records. Remember: an empty Advisor view does not guarantee you’re not using the service.

2. Inventory Every Azure Resource

Use Azure Resource Graph to query for Anomaly Detector instances. A sample query might look for resource types containing “anomalyDetector,” but since Microsoft hasn’t published an official query, you’ll need to validate results against your environment. Run the query across all accessible subscriptions and document the scope, date, and exact Kusto query used. Tools like Azure CLI or PowerShell can script this inventory across tenants. For example, Get-AzResource -ResourceType "Microsoft.CognitiveServices/accounts" | Where-Object {$_.Kind -eq "AnomalyDetector"} can help, but adjust based on your actual resource schema.

3. Search Your Code and Configurations

For every discovered endpoint or resource name, search your organization’s repositories, configuration files, and deployment manifests. Tools like Azure DevOps Code Search, GitHub’s search, or even a simple grep -r across your repositories can uncover references. Don’t forget to check archived repositories and branches that may hold older versions of configuration files. Look for:

  • Application settings in Azure App Services, Function Apps, and virtual machines
  • CI/CD pipeline variables in Azure DevOps, GitHub Actions, or Jenkins
  • Infrastructure-as-code templates (ARM, Bicep, Terraform)
  • Scripts (PowerShell, Python, Bash) stored in repositories or on servers
  • Dockerfiles, docker-compose.yml, Kubernetes manifests, and Helm charts

This step often reveals the most surprising dependencies—a one-off script that runs quarterly, a development tool that accesses the service during debugging, or a disaster-recovery process that hasn’t been exercised in years.

4. Trace Credentials and Secrets

Do not copy API keys or connection strings into any document. Instead, locate the protected store (Azure Key Vault, HashiCorp Vault, etc.) and record the secret name, the workload identity authorized to access it, and the consuming service. Check access policies on Key Vaults to see which applications and users can retrieve Anomaly Detector keys. Use Get-AzKeyVaultSecret -VaultName <VaultName> to list secrets, then review metadata, but never extract values. This helps you understand the full chain of trust and identify which components will need new credentials when you switch to a replacement service.

5. Hunt for Self-Hosted Containers

Because Microsoft offers Anomaly Detector as a container, you may have deployments running on-premises, in Azure Kubernetes Service, or on other cloud platforms. Use container orchestration tools (kubectl get pods --all-namespaces, then kubectl describe pod) to list running and stopped containers and inspect image details. For Docker standalone, run docker ps -a and docker images. Review your container registry for images tagged with “cognitive-services-anomaly-detector” or similar. Also check your build pipelines in case containers are spun up temporarily during testing.

6. Validate Every Finding

For each potential dependency, determine whether it is confirmed active, possibly active, inactive (with evidence), or unresolved. This classification must be backed by logs, runtime observations, owner confirmation, or configuration analysis. Don’t assume that an old reference is inactive—some processes run so infrequently that they won’t appear in recent logs. When in doubt, treat ambiguous items as active until proven otherwise.

7. Assign Ownership and Set a Timeline

Create a central register (a spreadsheet, database, or governance tool) with one row per distinct dependency. Columns should include: dependency ID, environment, endpoint, caller, credential reference, owner, status, evidence, and next action. Set deadlines: complete initial discovery within 3 months, have a replacement prototype within 6 months, and fully migrate and decommission before mid-2026 to leave buffer for unexpected issues.

Choosing a Replacement

Microsoft hasn’t designated a direct successor. Likely candidates include Azure Machine Learning’s anomaly detection capabilities, Azure Cognitive Services for Vision or Decision, or even Azure Stream Analytics with custom ML models. Evaluate based on your use case: whether you need real-time detection, batch processing, or integration with IoT Hub. Start prototyping early, because feature parity is not guaranteed, and API changes may require significant code refactoring.

Outlook: The Path to October 2026

Eighteen months is a comfortable window if you start now. By mid-2025, you should have completed discovery and be well into testing a replacement. Leave at least six months for full production rollout and a “cooling off” period to catch stragglers. Microsoft will likely publish additional guidance and migration resources as the date approaches, but waiting for them is risky. The dependency register you build today is your most important tool—it turns an abstract retirement notice into a manageable checklist. The clock is ticking: begin your dependency discovery this quarter.