Azure API for FHIR retirement needs cutover proof

The retirement date creates a cutover decision

The direct answer in Microsoft's Azure Health Data Services overview is that Azure API for FHIR is scheduled to retire on September 30, 2026. The same page says new customer deployments stopped on April 1, 2025 and directs existing customers toward the Azure Health Data Services FHIR service. This is a scheduled change documented on a page last updated February 23, 2026—not evidence of a new September 2 announcement, a completed rollout, or migration by any particular customer.

An affected-asset register should identify every subscription, resource group, region, Azure API for FHIR instance, environment, data owner, client, service identity, user role, network dependency, encryption configuration, log destination, export or analytic job, downstream application, and accountable operating team. The word evolved describes Microsoft's product relationship; it does not establish that a buyer's configuration, data, integrations, performance, security controls, or operating behavior will transfer without change.

Preserve data and access behavior across the move

Migration evidence should reconcile the source and target data stores at the level needed by the deployed workloads. Teams should retain the extraction and import method, timestamps, resource types and counts, logical identifiers, references, version and history behavior where relied upon, deleted or superseded records, validation results, rejected items, transformation rules, and unresolved differences. A target endpoint returning FHIR resources is not proof that every historical or operational assumption survived.

The page describes SMART on FHIR support and Microsoft Entra role-based access control for the Azure Health Data Services FHIR service. It also distinguishes platform capabilities such as Private Link, customer-managed keys, and logging from the older offering. Buyers should map user, application, and service access anew; test allowed and denied paths; verify private-network and key dependencies; retain comparable audit evidence; and prevent a migration convenience from silently broadening access or changing the authority assigned to an existing client.

Prove client and operating parity before decommissioning

Every client contract should identify the current and target base URL, authentication audience and identity, scopes or roles, supported FHIR release and implementation guides where applicable, resource and operation use, search behavior, scheduled jobs, timeouts, limits, monitoring, support owner, and change window. A successful health check or sample read proves only that the tested request succeeded. It does not establish complete application compatibility, workflow continuity, profile conformance, semantic fidelity, privacy compliance, or clinical fitness.

A staged cutover plan should name entry and exit criteria, a configuration freeze or controlled-change method, data-reconciliation checkpoints, client test results, observability thresholds, exception owners, user communication, rollback trigger, and the evidence required before disabling the legacy service. The old environment should not be decommissioned merely because the successor exists or because a small sample passed. Retention, backup, audit, contractual, regulatory, and records obligations need their own qualified review.

Test a controlled cutover and rollback

A representative evaluation should use appropriately governed synthetic or sanitized resources and the actual client classes that matter to the organization. Exercise creation, update, read, search, history, and authorization behavior where those functions are used; include linked resources, an invalid resource, an unauthorized identity, a revoked or narrowed role, a private-network path, key access, log reconstruction, an interrupted migration step, and a client that still points to the former service. Compare source and target results, record every exception, and demonstrate rollback before any irreversible shutdown decision.

Microsoft's documentation establishes the retirement schedule and the described Azure Health Data Services scope. It does not prove migration feasibility, data completeness, behavioral equivalence, FHIR or implementation-guide conformance, client compatibility, security, privacy, regulatory compliance, performance, rollback, or continuity for a customer. Health-data platform, integration, clinical informatics, records, security, privacy, compliance, procurement, and legal owners should approve their respective evidence before the organization treats the cutover or decommissioning as complete.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.