Manu Shukla

Posted on Aug 14 • Originally published at ecorpit.com

Azure API for FHIR retires in 47 days: the 2026 migration plan for hospital IT

#fhir #azure #healthcareinteropera #migration

Azure API for FHIR retires in 47 days: the 2026 migration plan for hospital IT

Summary. Microsoft retires Azure API for FHIR on 30 September 2026, 47 days from 14 August 2026. New customer deployments have been blocked since 1 April 2025. After the retirement date you cannot create or manage accounts, reach data through the Azure portal or APIs, use SDKs against the service, receive updates, or open a support case. 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 is scheduled for deprecation on 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.

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.

Capability	Azure API for FHIR	Azure Health Data Services FHIR service
Local RBAC and custom authority	Supported	Not supported; the token issuer must be the authentication endpoint for the tenant the FHIR service runs in
SMART on FHIR Proxy	Supported	Planned deprecation 21 September 2026; use the new SMART on FHIR capability
Data ingress	Tools available in open source	`$import` operation
Autoscaling	Supported on request, incurs a charge	Enabled by default at no extra charge
Search parameters	Batch bundles only; include, revinclude and iterate modifier not supported	Batch and transaction bundles; selectable search parameters; include, revinclude and iterate supported
Events	Not supported	Supported through built-in eventing
Storage volume	More than 4 TB	4 TB currently supported; raise an Azure support request above that
Resilience	Cross-region disaster recovery	Point-in-time recovery; availability zone support listed as upcoming

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 is being deprecated on 21 September 2026, nine days before the service itself retires. That ordering matters: if patient-facing or third-party app authorisation runs through the proxy, it stops working before your migration deadline, not after.

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.

Microsoft's documentation states the reason for starting now 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.

Pattern	When it fits	Mechanism	Main risk
Lift and shift	The data pipeline can absorb a longer outage	`$export` from Azure API for FHIR, then `$import` into Azure Health Data Services	Export and import duration scales with data volume; a large estate can exceed the outage window you promised clinicians
Incremental copy	Large datasets, or the old service must keep serving during the move	Microsoft's open-source migration tool on GitHub, or your own incremental tooling	Requires reconciliation; you are running two servers and must prove they agree before cutover
Do nothing until September	Never	Not applicable	New deployments have been blocked since 1 April 2025, and support ends at retirement

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 early

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 47-day 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.

Note the SMART on FHIR Proxy deprecation on 21 September 2026 sits inside week 6. If any patient-facing app depends on it, that work belongs in week 2, 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 retiring 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. Azure Health Data Services is available in Indian regions including Central India, South India and West India, so a data-residency requirement does not force the workload offshore. 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 deadline 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.

FAQ

What exactly happens on 30 September 2026?

Azure API for FHIR is retired. After that date customers cannot create or manage accounts, access data through the Azure portal or APIs, use SDKs and client tools against the retired service, receive updates, or obtain Microsoft support. New customer deployments have already been blocked since 1 April 2025, so the service has been in wind-down for over a year.

Can I just copy the data and be done?

No. Microsoft's documented sequence has five steps, and only one is the data copy. You also have to 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 servers report the same capabilities.

What is the difference between lift and shift and incremental copy?

Lift and shift is the simpler pattern, using export from the old service and import into the new one, and suits pipelines that can afford longer downtime. Incremental copy is a continuous version with less downtime, intended for large datasets or where the old service must keep running during migration.

Does anything break before the retirement date?

Yes. SMART on FHIR Proxy has a planned deprecation date of 21 September 2026, nine days before the service retires. Sync agent and FHIR Proxy are also being deprecated. Any patient-facing or third-party application authorising through the proxy needs the new SMART on FHIR capability first.

What if we hold more than 2 TB of FHIR data?

Open an Azure support request before starting the migration, and include both your Azure API for FHIR instance name and your Azure Health Data Services FHIR service instance name so Microsoft can assist with planning. Azure Health Data Services currently supports 4 TB; above that, raise a support request as well.

Will the new service cost more or less?

The models differ. Azure API for FHIR bills service runtime per hour, structured storage per GB per month, and provisioned throughput per 100 request units per second, with autoscaling adding 50% to throughput cost and disaster recovery doubling total service cost. Azure Health Data Services bills consumption with a monthly free allotment and includes autoscaling at no extra charge.

Does the IoT connector migrate automatically?

No. The IoT connector is supported only on Azure API for FHIR. To move existing IoT connector device FHIR data to Azure Health Data Services, Microsoft directs teams to the bulk export and import functionality in the migration tool rather than any automatic path.

How does this interact with our ABDM programme?

ABDM health information provider integration is FHIR-based, so profiles, terminology and consent artefacts sit on whichever server you run. Migrating servers mid-programme means validating those profiles twice. If ABDM work is in flight, complete the Azure migration first and build ABDM integration on the target service.