Azure Service Retirements Need a Living Inventory Process

Azure service retirement planning fails when a Microsoft notice cannot be connected to the resources, workloads, owners and dependencies it affects. Treat each retirement as a tracked lifecycle record, using Service Health for early warning, Advisor and Resource Graph for correlation, and engineering workflow records to prove migration, removal or a justified exception.

That is why Azure service retirement planning needs an inventory process, not another spreadsheet. A spreadsheet can be a perfectly respectable export, review list or executive summary. It is a poor substitute for a living record that connects Microsoft notices to Azure resource IDs, application ownership, source code, deployment pipelines, operational dependencies and evidence that the response worked.

Microsoft has improved the raw ingredients. Azure Service Health can signal retirement announcements, while Azure Advisor now exposes service upgrade and retirement recommendations, including impacted resources where that data exists. Azure Resource Graph can query the estate at scale. The hard part remains connecting a cloud resource to the business workload and technical dependency behind it.

Why is a spreadsheet-only approach unreliable?

Most retirement spreadsheets start sensibly: service name, deadline, named owner and status column. They fail when the estate changes faster than the document, or when a retirement is more specific than a service name suggests. A platform retirement may apply only to a runtime, API version, VM SKU, networking mode, operating system image or feature flag. “We use Azure Functions” tells you very little if the retirement concerns one runtime version in a particular application.

A useful record preserves the identifier that lets people revisit the evidence. For a Microsoft notice, that usually means the Service Health tracking ID and announcement URL. For affected infrastructure, it means Azure resource IDs, subscription IDs, regions, and the discovery query or API result that produced the match. Without them, a team can’t later tell whether a resource was checked, merely assumed safe, or missed altogether.

There is another limitation worth keeping in view. Microsoft’s current guidance says Advisor retirement recommendations are available through the portal, APIs, Azure Resource Graph, Service Health and workbooks, but it also says impacted-resource information is unavailable for a subset of retirements. The supported recommendation channels apply to Azure public cloud; organisations using sovereign or national partner clouds need a different route for this work. Any claim that one Azure dashboard provides a complete retirement inventory is therefore rather optimistic.

How should an organisation build a reliable Azure retirement inventory?

Start with a repeatable asset inventory, not the notices. Azure Resource Graph is the sensible control-plane foundation because it can query resources across selected subscriptions and retrieve resource-provider properties without individually polling every provider. Feed its results into a scheduled inventory dataset or CMDB integration, rather than treating discovery as a one-off exercise.

At a minimum, collect resource ID, name, type, subscription, resource group, location, tags, key configuration properties and the timestamp of discovery. Add a workload identifier and accountable application owner wherever possible. Resource group ownership is not enough: a shared resource group can hold several applications, while one application can span subscriptions and regions.

Tags help, but only if they are governed. A small mandatory set is normally more useful than a magnificent tagging taxonomy nobody maintains: for example, application, environment, service owner and criticality. Microsoft notes that resources do not automatically inherit tags from a resource group or subscription. Relying on parent-level tags without an inheritance policy or another deliberate control leaves holes exactly where an inventory needs consistency.

Don’t pretend Azure Resource Graph is an application dependency map. It can identify deployed Azure resources and their visible properties. It won’t reliably establish that a particular repository calls an ageing API, that a container image contains an old client SDK, or that an external supplier uses a connection string. Add feeds from infrastructure-as-code repositories, CI/CD variables, container registries, runtime telemetry, API management logs and application configuration management. The exact sources differ by organisation; the principle does not.

How should retirement notices be matched to assets and workloads?

Use a two-stage workflow. First, receive and register the lifecycle signal. Then prove or disprove estate impact.

Azure Service Health is best used for the first job. Microsoft’s current guidance distinguishes it from Advisor: Service Health provides awareness of a retirement announcement and a tracking ID, while Advisor is intended to provide resource-level recommendations and impacted-resource detail. Service Health health advisories can cover service retirements and other action-required changes, and Microsoft says they are normally communicated at least 90 days in advance, except for urgent cases. “Normally” matters: don’t design the process around a minimum notice period.

For the second job, query Advisor retirement recommendations and Azure Resource Graph. Advisor’s Service Retirement workbook is useful as a central operational view because it can show planned retirement dates, impacted-resource counts and migration guidance, with filtering by subscription, resource group and location. It is a strong starting point for triage, not a reason to skip validation.

Each notice should become one retirement record containing:

• The Microsoft tracking ID, announcement link, retirement date and the precise feature or condition being retired;
• The discovery method: Advisor recommendation, Resource Graph query, configuration scan, code search, supplier confirmation or manual assessment;
• Candidate and confirmed Azure resource IDs, plus the last time each was checked;
• The workload, environment, business owner and technical delivery owner;
• Dependencies, including upstream identity, network, data, backup, monitoring and downstream consumer dependencies;
• The selected response: migrate, upgrade, remove, replace, accept a documented exception, or confirm not affected;
• A migration deadline that is earlier than Microsoft’s service deadline; and
• Links to change records, pull requests, test results and approval evidence.

The distinction between candidate and confirmed matters. An Advisor match is strong evidence that a resource needs examination; it is not automatically proof of application impact. Equally, an empty Advisor result is not proof that application code or a non-inventoried dependency is clear.

Which Azure notifications and tools should drive the process?

Use push notifications for awareness and scheduled queries for assurance. Microsoft explicitly recommends this division: Azure Monitor alerts can push a retirement notification when it is announced, while periodic Resource Graph queries can pull active retirements and their impact for inventory and reporting.

Configure Service Health alerts for health advisories across the subscriptions that matter. Send them through a monitored action group to the team responsible for lifecycle triage. An action group can notify people, call a webhook, or trigger a Function or Logic Apps workflow. For Service Health alert handling, Microsoft specifies that the action group must be set to the Global region.

Centralisation has a trap. Microsoft warns that tenant-level Service Health alerts do not include every subscription-level event, and full visibility can require both tenant- and subscription-level rules. Retirement notices also aren’t inherently consolidated. Test the alert design against a non-production subscription and document its scope; don’t infer coverage because an email arrived.

For execution, choose one primary alerting path for a given retirement. Microsoft advises against configuring both Service Health and Advisor alerts for the same retirement because duplicate notifications create noise. A workable pattern is Service Health as the announcement trigger, Advisor and Resource Graph for correlation, and an ITSM or engineering backlog item as the operational record. Where an organisation already consumes Advisor recommendations through API or workbook, Advisor can instead be the principal remediation feed.

This matters when migration isn’t an in-place switch. Some changes require rebuilds, redeployment and explicit verification rather than a vendor-operated move, as with Microsoft Foundry hosted agents that have no automatic migration path. The inventory record needs to state what kind of change is required, not merely that a deadline exists.

How should teams decide which migrations go first?

Don’t sort the list solely by Microsoft’s retirement date. That creates a queue of superficially urgent work while difficult, poorly understood production dependencies are left until they become emergencies.

Prioritise by the combination of deadline and uncertainty. A sensible triage review asks:

• Is this production, customer-facing, safety-critical or subject to a contractual recovery commitment?
• How many applications, business processes or external consumers share the affected component?
• Is the replacement a configuration change, a code change, a data migration, an architectural rebuild, or a supplier-led change?
• Can the work be rehearsed in a representative environment, and is there a credible rollback?
• Are there freeze periods, regulatory controls, certificate dependencies or procurement decisions that consume the apparent notice period?
• Do ownership and dependency records look trustworthy, or is the first task discovery?

Unknown ownership should raise priority, not lower it. Clear the attractive easy wins in parallel, but start investigating the workload with incomplete information and a disruptive migration early. That is where deadline pressure becomes operational risk.

Review associated controls whenever the replacement changes a service boundary. A database move might alter backup, retention or restore procedures; Azure SQL long-term retention capabilities differ between Database and Managed Instance, so a familiar product name is not evidence of equivalent operational behaviour.

What counts as completed Azure service retirement planning?

“Ticket resolved” is not a completion test. Close a retirement response only when there is evidence for the relevant failure mode.

For a resource migration, that normally includes the deployed replacement’s resource ID and configuration, tested application behaviour, monitoring and alert coverage, backup or recovery checks where applicable, and confirmation that the old resource or configuration has been removed. For API, SDK and runtime retirements, include the code or configuration change, build and deployment evidence, a search or scan demonstrating the old dependency is gone, and post-change telemetry.

Keep the original notice and the last re-check result. Advisor can mark recommendations complete automatically if it verifies that they no longer apply, but that is useful corroboration rather than a substitute for an application-level acceptance test. A resource can cease to match a recommendation while the replacement still fails an integration, breaks an audit trail or changes a recovery assumption.

The spreadsheet still has a place: as a quarterly portfolio view, a board report, or an export for teams that need a short list. It should not be the authoritative system. Azure service retirement planning works when the spreadsheet is a view of the process, not the process itself.