Azure API for FHIR retired on 30 September 2026: the migration plan for hospital IT

Summary. Microsoft's retirement date for Azure API for FHIR was 30 September 2026, and it has passed. New customer deployments have been blocked since 1 April 2025. Until 5 October 2026 Microsoft's FAQ said that after this date customers could not create or manage accounts, reach data through the Azure portal or APIs, use SDKs against the service, receive updates or get support. It has since removed that list and now says it deprecated the service on that date, with questions going to a support request called Azure API for FHIR Extension Request. The replacement is Azure Health Data Services FHIR service, and the move is not a lift-and-shift of data alone: local RBAC is gone, SMART on FHIR Proxy had an end date of 21 September 2026, the IoT connector is supported only on the old service, and every application endpoint and permission has to be rebuilt. If your instance holds more than 2 TB, Microsoft asks you to open an Azure support request before you start. Anyone still evaluating can test the target on the standard $200 Azure free credit before committing.

Update, 2 November 2026. The 30 September 2026 date for Azure API for FHIR has passed. On 5 October 2026 Microsoft reworded its documentation. It now says it deprecated the service on that date, sends questions to a support request called Azure API for FHIR Extension Request, and no longer lists what customers lose after the date. It does not say what that request grants, so if you are still on the old service, ask Microsoft what applies to your instance. The migration steps below still match Microsoft's current page. We have replaced the countdown and corrected the dates that have passed.

The billing model also changes in your favour, which is the part most migration plans miss. Azure API for FHIR charges provisioned throughput in Request Units per second whether you use it or not, adds a 50% increase to that throughput cost when autoscaling is on, and doubles the total service cost when disaster recovery is enabled. Azure Health Data Services enables autoscaling by default at no extra charge and bills API requests with a monthly free allotment.

What breaks, not just what moves

Copying FHIR resources is the easy half. Microsoft's own readiness comparison lists the capability differences that actually break running systems.

Four dependencies deserve a named owner on your plan before anything else happens.

Sync agent is being deprecated. If you connect to Dataverse through it, the replacement path is the data integration toolkit.

FHIR Proxy is being deprecated. Teams using it for events move to the built-in eventing feature, or build an alternative on the Azure Health Data Services toolkit.

SMART on FHIR Proxy had an end date of 21 September 2026, nine days before the service's own retirement date, and Microsoft removed its proxy guidance on 5 October 2026. Microsoft had warned that apps relying on the proxy would report errors after 21 September. If patient-facing or third-party app authorisation still runs through it, treat the move to the SMART on FHIR capability as urgent.

The IoT connector is supported only on Azure API for FHIR. To move existing IoT connector device FHIR data, Microsoft directs you to the bulk export and import functionality in the migration tool.

The five-step sequence Microsoft publishes

The documented approach is deliberately staged, and the order is the point.

Step 1, assess readiness. Compare the two services against your architecture and list every difference that affects you. This is where the local RBAC and SMART on FHIR Proxy dependencies surface.

Step 2, prepare to migrate. Pick a migration pattern, identify the data you are actually moving, decide whether historical resource versions come with it, deploy an Azure Health Data Services workspace, then deploy the FHIR service inside it, then configure it to match your existing settings before any data moves.

Step 3, migrate data. Execute the chosen pattern.

Step 4, migrate applications and reconfigure settings. Repoint every application to the new FHIR server URL, set up permissions again, recreate scheduled jobs such as $export, and compare both metadata endpoints to confirm the two servers agree on capabilities.

Step 5, cut over. Once the new server is stable, retire pipelines on the old service, delete data from the intermediate storage account used by the migration tool, delete data from the old server and decommission the account.

Until 5 October 2026, Microsoft's documentation put the reason plainly:

"Azure API for FHIR will be retired on September 30, 2026, so you need to migrate your FHIR data to Azure Health Data Services FHIR service as soon as feasible."

Choosing a migration pattern

Two patterns are documented, and the choice is a downtime question, not a technical preference.

For lift and shift, Microsoft's GitHub repository provides guidance on running the commands and a script that helps automate creating the $import payload. For incremental copy, the open-source migration tool exists specifically for that pattern, and Microsoft asks you to read its documented capabilities and limitations before relying on it.

One instruction is easy to miss and expensive to skip: if your Azure API for FHIR instance contains more than 2 TB of data, open an Azure support request before starting, including both the source instance name and the target FHIR service instance name so Microsoft can help with planning.

The cost case for moving

Migration business cases usually treat the deadline as the only driver. The billing difference is a second one.

Azure API for FHIR bills three things: service runtime per hour for the RESTful API layer, structured storage per GB per month for SSD-backed data and index, and provisioned throughput in Request Units per second, scalable in increments of 100 RU/s. Provisioned throughput is capacity you buy in advance. Turning on autoscaling raises the cost of that provisioned throughput by 50%, applied as a 1.5x multiplier on throughput units. Turning on disaster recovery replicates the instance into another supported region and doubles the total cost of the service.

Azure Health Data Services bills consumption instead: structured storage and BLOB storage per GB per month, API requests per 100,000 with a lower tier up to 50,000, transformation operations, export batch per GB and eventing per million events, with a monthly allotment that lets you try the product at no cost. Operations returning status codes 429 or 500 and above do not incur a charge, and initial-mode import is not charged. Autoscaling, which costs 50% more on the old service, is on by default at no extra charge on the new one.

There is one billing subtlety worth designing around. In a batch bundle, every operation that executes successfully incurs a charge. In a transaction bundle, all operations succeed or fail together, and only successful transactions incur a charge. If your integration engine posts large bundles with a meaningful failure rate, the bundle type you choose has a direct cost consequence on the new service that it did not have on the old one.

A seven-week plan that actually finishes

Week 1: inventory. List every application, integration engine, analytics pipeline and scheduled job that touches the FHIR endpoint. Record which use local RBAC, SMART on FHIR Proxy, FHIR Proxy for events, sync agent to Dataverse, or the IoT connector. Measure current data volume and raise the Azure support request now if you are above 2 TB.

Week 2: stand up the target. Deploy the workspace, deploy the FHIR service, replicate configuration, and compare metadata endpoints against the current server. Rebuild identity: register applications against the tenant authentication endpoint, since custom authority is not available.

Weeks 3 and 4: move data in a rehearsal. Run the chosen pattern against a copy first and time it. The timing result decides whether lift and shift is still viable or you need the incremental tool.

Week 5: repoint non-critical consumers. Analytics, reporting and research pipelines move first, because they tolerate a rollback.

Week 6: repoint clinical consumers with a rollback plan, then run both servers in parallel long enough to reconcile.

Week 7 and the buffer: cut over, retire old pipelines, clear the intermediate storage account and decommission. Leave the last week empty on purpose. Every healthcare migration we have run needed it.

The 21 September 2026 end date for SMART on FHIR Proxy has already passed. If any patient-facing app still depends on the proxy, that work belongs in week 1, not week 6.

India-specific considerations

Indian hospital and healthtech teams are usually carrying two interoperability programmes at once: the Azure retirement and ABDM. They interact more than most plans assume.

ABDM health information provider integration is FHIR-based, so the resource profiles, terminology handling and consent artefacts you build for ABDM sit on top of whichever FHIR server you run. Migrating servers mid-programme means validating those profiles twice. If your ABDM work is in flight, do the Azure migration first and build ABDM on the target, not the retired service. Our guide to ABDM health information provider integration for hospitals covers that side.

The DPDP Act adds a second constraint. Patient records are personal data, and a migration moves them through an intermediate storage account that the migration tool uses. That account is in scope: it needs the same access control, encryption and retention treatment as the FHIR server, and the documented cutover step of deleting data from it after migration is a compliance action, not housekeeping. We design applications aligned with DPDP Act requirements, and our clinical AI data architecture guidance for India sets out the pattern.

Region choice matters for both. Microsoft's regional availability page lists the FHIR service in Central India, the only Indian region it names, so a data-residency requirement does not force the workload offshore. The same page shows no Events support there. Confirm feature parity for the specific capabilities you need in the region you pick before you commit the plan.

Who should not do this in-house

Two situations argue for outside help. The first is a dependency on local RBAC or SMART on FHIR Proxy, because the replacement is an identity redesign rather than a configuration change, and it touches every third-party app that reads your data. The second is an estate above 2 TB with a clinical downtime window measured in hours, where the incremental pattern is the only option and reconciliation becomes the real project.

The real cost is usually the application repointing and the identity rebuild, not the data copy.

How eCorpIT can help

eCorpIT runs healthcare platform migrations for hospitals and healthtech companies from Gurugram, with senior-led engineering teams. For this migration we inventory every FHIR consumer and dependency, stand up and configure the Azure Health Data Services target, choose and rehearse the migration pattern against your real data volume, rebuild application identity against the tenant authentication endpoint, and run the parallel-reconciliation and cutover. We are ISO 27001:2022 certified, CMMI Level 5 appraised and MSME certified, we are a Microsoft partner, and we design applications aligned with DPDP Act and ABDM requirements. If you are running FHIR workloads on Azure and have not started, contact us and we will start with the dependency inventory.

Related reading: our healthcare app development service for India, clinical AI deployment, and data residency and DPDP cloud architecture.

FAQ

References

1. Migration strategies for moving from Azure API for FHIR - Microsoft Learn, updated 5 October 2026

1. FAQ about migrations from Azure API for FHIR - Microsoft Learn

1. What is Azure API for FHIR? - Microsoft Learn

1. Azure Health Data Services documentation - Microsoft Learn

1. What is the FHIR service in Azure Health Data Services? - Microsoft Learn

1. Azure Health Data Services pricing - Microsoft Azure

1. Azure API for FHIR migration tool - Microsoft, GitHub

1. FHIR data migration tool documentation - Microsoft, GitHub

1. Migration tool capabilities and limitations - Microsoft, GitHub

1. Configure import data for the FHIR service - Microsoft Learn

1. Export data from Azure API for FHIR - Microsoft Learn

1. SMART on FHIR in Azure Health Data Services - Microsoft Learn

1. Events in Azure Health Data Services - Microsoft Learn

1. Azure Health Data Services toolkit - Microsoft, GitHub

1. Deploy a FHIR service within Azure Health Data Services - Microsoft Learn

1. Update Azure API for FHIR deprecation notices - Microsoft, GitHub, 5 October 2026

1. Remove retired SMART on FHIR proxy guidance and deprecation notices - Microsoft, GitHub, 5 October 2026

1. Regional availability of services and features - Microsoft Learn, updated 5 October 2026

Last updated: 2 November 2026.