Azure API for FHIR Retires in September — Your Options

If your organization runs on Azure API for FHIR, you have less than six months to move. Microsoft is retiring the service on September 30, 2026, and after that date, you lose access to your data, your APIs, and your support contract. No grace period.

This isn't a deprecation notice you can ignore. It's a hard shutdown.

The Timeline

Here's what's already happened and what's coming:

Date	Event
March 2022	Azure Health Data Services (AHDS) went GA as the successor
April 1, 2025	New Azure API for FHIR deployments blocked
September 21, 2026	SMART on FHIR proxy stops working
September 30, 2026	Full shutdown — no portal, no APIs, no SDKs, no support

After September 30, you won't be able to create or manage accounts, access data through the portal or APIs, receive service updates, or contact support. Microsoft's own FAQ is unambiguous about this.

What Actually Breaks

The retirement isn't just "swap one endpoint for another." Several components that Azure API for FHIR customers rely on are being deprecated outright:

SMART on FHIR proxy is gone. If you built patient-facing apps using Azure's SMART proxy for OAuth2 authorization, you need to migrate to SMART on FHIR (Enhanced) on AHDS by September 21 — nine days before the main shutdown. Applications that don't migrate will start returning errors.

Sync Agent is deprecated. If you're syncing FHIR data to Dataverse (common for organizations using Power Platform for analytics), you need to switch to Microsoft's Data Integration Toolkit. Different architecture, different setup.

IoT Connector is replaced by MedTech service. If you're ingesting data from medical devices through the IoT connector, you'll need to set up the MedTech service in AHDS — which has its own configuration requirements and data mapping format.

Pricing model changes. Azure API for FHIR used fixed pricing. AHDS uses consumption-based pricing. Depending on your usage patterns, your bill could go up or down. Worth modeling before you migrate.

Option 1: Migrate to Azure Health Data Services

This is the path Microsoft recommends, and for most organizations already invested in Azure, it's the most straightforward.

Microsoft's migration guide breaks it into five steps:

1. Assess readiness — compare feature differences between the old and new services
2. Deploy a new AHDS workspace — stand up the FHIR service in your Azure subscription
3. Configure the server — replicate your existing settings (custom search parameters, CORS, auth)
4. Migrate data — use Microsoft's open-source migration tools to move FHIR resources
5. Repoint applications — update every client, integration, and webhook that talks to the old endpoint

The migration tools handle bulk export from the old service and bulk import into the new one. But "migrate" undersells the work involved. You're not just moving data — you're re-validating every integration, re-testing every workflow, and dealing with behavioral differences between the old and new services.

For example, the March 2026 release notes document changes to bulk export cancellation behavior, search parameter URL validation, and versioning configuration that already caused 500 errors in production. Small differences in FHIR server behavior can cascade through downstream applications in ways that are hard to predict.

If you have a dedicated cloud infrastructure team and your architecture is Azure-native, this is still the right call. AHDS gives you the same FHIR service plus DICOM support, better analytics connectors (Synapse, Power BI, Azure ML), and a consumption model that scales with usage.

Option 2: Evaluate Alternative FHIR Servers

If you were already considering a multi-cloud strategy, or if your team has outgrown Azure's managed FHIR offering, now is a natural point to evaluate alternatives.

Several mature FHIR server implementations exist:

HAPI FHIR — the open-source Java FHIR server that many organizations self-host. Battle-tested, highly customizable, large community. The trade-off is operational overhead: you own the infrastructure, scaling, and patching.

Firely / Vonk — a commercial .NET FHIR server with strong conformance tooling. Firely also maintains the Simplifier.net IG registry. Popular in European health systems.

Google Cloud Healthcare API — Google's managed FHIR service. Similar concept to Azure's offering but on GCP. Worth evaluating if you're already on Google Cloud or considering a move.

AWS HealthLake — Amazon's managed FHIR data store with built-in natural language processing. Integrates with the broader AWS ecosystem.

Each option involves real migration effort. FHIR servers are not interchangeable — they differ in search parameter support, extension handling, subscription models, and performance characteristics. Any migration requires re-testing your entire FHIR surface area.

Option 3: Rethink the Architecture

A forced migration is also an opportunity to ask whether your current architecture is still the right one.

When many organizations first deployed Azure API for FHIR, it was the fastest path to CMS interoperability compliance. Stand up a managed FHIR server, expose the required Patient Access endpoints, check the regulatory box. The architecture was shaped by deadline pressure, not by long-term data strategy.

Now that you're forced to move anyway, it's worth asking:

Do you need a monolithic FHIR server, or a set of specialized services? Many organizations have learned that a single FHIR server trying to do everything — terminology, storage, search, subscriptions, bulk export — creates coupling that makes every change risky. A more modular approach separates concerns: use a FHIR server for resource persistence and search, a dedicated terminology service for code lookups and value set management, and purpose-built pipelines for analytics and reporting.

Is your terminology layer working for you? If you're running clinical code lookups against your FHIR server's built-in terminology support, you've probably hit limitations. Most FHIR servers implement a subset of the FHIR terminology spec — basic CodeSystem lookup and ValueSet expansion, but not cross-system concept mapping, not daily-updated drug data, not the full depth of SNOMED or RxNorm relationship graphs.

This is where we fit. FHIRfly provides FHIR-native terminology APIs — code lookups, ValueSet expansion, CodeSystem search, and concept mapping across NDC, RxNorm, ICD-10, SNOMED, LOINC, CPT, CVX, NPI, and more. We handle the data freshness (daily updates from authoritative sources), the cross-walks between code systems, and the FHIR R4 response formatting.

We're not a FHIR server replacement. We don't store your clinical resources, handle subscriptions, or manage patient data. If you need a FHIR persistence layer, you still need one of the options above. But if your migration includes rethinking how your applications resolve clinical codes, expand value sets, or map between terminologies — that's the problem we solve, and we do it well.

What to Do This Week

If you haven't started planning, you're behind — but six months is enough time if you start now.

1. Audit your Azure API for FHIR dependencies. List every application, integration, and workflow that touches your FHIR server. Include the non-obvious ones: analytics pipelines pulling bulk exports, SMART apps using the auth proxy, IoT connectors feeding device data.

2. Identify the deprecated components. If you're using SMART on FHIR proxy, Sync Agent, or IoT Connector, those require separate migration paths — not just a server swap.

3. Model the cost impact. Run your current usage patterns through AHDS pricing to understand the consumption-based cost difference. Surprises here are common.

4. Set up a parallel environment. Deploy an AHDS workspace (or your chosen alternative) now. Migrate a subset of data. Run your integration tests against it. The earlier you find behavioral differences, the more time you have to address them.

5. Don't migrate blind. The migration tools handle data transfer, but they don't validate that your applications behave identically on the new service. Build a test plan that covers your critical workflows end-to-end.

Key Takeaways

• September 30, 2026 is a hard shutdown. After that date, Azure API for FHIR is gone — no data access, no APIs, no support.
• The migration to AHDS is real work. It's not a URL swap. Deprecated components (SMART proxy, Sync Agent, IoT Connector) require separate migration paths.
• Alternatives exist — HAPI FHIR, Firely, Google Healthcare API, AWS HealthLake — but every option involves re-testing your FHIR surface area.
• A forced migration is a chance to rethink. If your architecture has outgrown the monolithic FHIR server pattern, now is the time to modularize.
• Start this week. Six months goes fast when you're coordinating across teams, re-testing integrations, and handling surprises.