On September 30, 2026, at 10:59:59 PM Pacific Time, Microsoft will shut down Azure API for FHIR, the managed cloud service that thousands of healthcare organizations rely on to store, exchange, and process protected health information using the FHIR standard. New deployments of the service have been blocked since April 1, 2025, and after the retirement date, any remaining endpoints will become permanently inaccessible—along with all data still housed inside them.

There is no extension, no exception. For IT teams still running production workloads on the older service, the next year and a half is not a leisurely migration. It’s a deadline with hard operational consequences: lost clinical data access, broken integration pipelines, and a compliance scramble if someone forgot to move one last Windows Server application or nightly reporting job.

The Clock Ran Out on Azure API for FHIR

Microsoft launched Azure API for FHIR in 2019 as a quick-start gateway for healthcare organizations adopting HL7’s Fast Healthcare Interoperability Resources (FHIR) standard. It offered a pre-provisioned, managed FHIR server that could ingest, store, and query clinical data. But the product never reached the breadth of its successor, Azure Health Data Services, which spans FHIR, DICOM imaging, and a unified identity model powered by Microsoft Entra.

On the retirement date, your Azure API for FHIR accounts will stop accepting management operations, data requests through the portal or APIs, and any form of customer support. Microsoft explicitly warns that there is no “wait and see” option for production endpoints carrying protected health information. You can’t keep the old endpoint around as a temporary fallback; the service physically turns off.

What This Means for Your Team

If you’re a developer, architect, or system administrator in a health system, clinical software vendor, or payor, this retirement touches more than just the Azure resource you provisioned years ago. It reaches into every client, script, and service that calls that endpoint.

Developers and integration engineers need to replace the endpoint URL in application configuration, update any certificate thumbprints or secret references, and revalidate authentication flows. A successful data export and import does not prove that an unattended Windows service, an IIS-hosted web app, or a partner’s EHR connector can actually read and write from the new service.

Operations and support staff will inherit a minefield of “forgotten integrations.” Scheduled tasks running on Windows Server, PowerShell automation scripts, monitoring probes, and even ad-hoc reporting queries may be hard-coded to the retiring endpoint. The migration isn’t complete until every single one of those consumers points to the new Azure Health Data Services FHIR endpoint and has been tested with real identities.

Compliance and security officers face a different kind of deadline: proving that the migration was clinically safe. Raw resource counts don’t qualify. You need audit-ready evidence that patient-linked references resolve, that key searches behave identically, and that no data was silently lost or excluded.

How Health IT Ended Up in This Crossroads

Microsoft’s FHIR story started with the standalone Azure API for FHIR, a purpose-built service that let teams get to “in production” quickly without deploying and hardening their own open-source FHIR servers. Over time, the company folded that capability into Azure Health Data Services, a more comprehensive platform that also handles DICOM imaging and adds deeper integration with Azure’s machine learning and analytics services.

The first written notice of retirement appeared in early 2024, but many organizations didn’t treat it as an urgent migration. For some, the April 1, 2025 cutoff for new deployments passed without internal alarm—after all, they weren’t spinning up new instances. But the September 2026 retirement date remained abstract until recently, when Microsoft began surfacing reminders directly in the Azure portal and publishing more explicit migration guidance.

Now the remaining window is finite, and the work is not as simple as “move the data.” Microsoft’s own documentation says: “migration requires data migration and application changes.” That means every consumer of the old API—whether a desktop application, an integration engine, a third-party connector, or a cron job—must be tested against the replacement service.

What You Need to Do Right Now

Treat this as a deadline-bound engineering project with a binary outcome: each workload is either cut over safely before September 30, 2026, or it fails hard on October 1. There is no graceful half-state. The following steps form a practical roadmap, distilled from the migration challenges Microsoft and early movers are encountering.

1. Inventory Every Last Consumer

You can’t cut over what you don’t know exists. Build a register of every production workload that calls Azure API for FHIR. Include:
- Applications running on Windows Server or Azure VMs
- IIS sites and application pools
- Scheduled tasks and Windows services
- PowerShell scripts, CI/CD pipelines, and infrastructure-as-code templates
- Integration engines (Mirth, Rhapsody, Redox, etc.)
- Third-party connectors and external vendor endpoints
- Ad-hoc queries run by analysts

For each consumer, record the current FHIR endpoint URL, the business function, the data classes involved, and a named owner. Search your source code repos, environment variable files, Key Vault entries, and operational runbooks for the retiring endpoint string. This inventory is the foundation; skip it and you will have silent outages.

2. Replace the Endpoint, Not Just the Data

The target is the FHIR service inside Azure Health Data Services. You’ll need to provision it, record its endpoint URL, and then update every configuration location you uncovered in step one. Relying on redirects or DNS tricks is dangerous—clients may handle redirects inconsistently, and you lose the chance to test the exact network path.

Update:
- Application connection strings and app settings
- Environment variables on servers and containers
- Stored secrets in Azure Key Vault, AWS Secrets Manager, or local credential stores
- Hard-coded URLs in compiled code or configuration files
- Any CI/CD definition that deploys or tests against FHIR

3. Verify Identity and Access—For Every Caller Type

The new FHIR service uses Microsoft Entra (formerly Azure Active Directory) for authentication, and the security model differs from the old API. Test interactive access for human users and non-interactive access for daemons, services, and automation accounts separately. A successful admin login from the portal does not guarantee that a Windows service running under a group-managed service account can acquire a token and make the FHIR calls it needs.

Specifically:
- Confirm token-acquisition paths (client secret, certificate, managed identity)
- Test from the actual runtime environment, not just a developer workstation
- Validate that required FHIR scopes and application roles grant exactly the operations needed—no more, no less
- For each client ID, run a representative FHIR query and ensure it returns the expected data

4. Reconcile Data Migration with Clinical Context

Data export from Azure API for FHIR and import into Azure Health Data Services is a necessary step, but it’s not a sign-off. Raw resource totals can match while critical subsets are missing:
- Patient-linked resources whose references don’t resolve
- Search parameters that return different result sets
- Write-heavy workflows that behave differently in the new service

Reconcile by workload. For a reporting pipeline that retrieves patient encounters, run that exact search and verify the returned Bundle. For a write-intensive operation, inject a test record and confirm it can be read back through the normal application path. Document exceptions: if a resource type was intentionally excluded from export, or a template conversion altered FHIR profiles, log the decision and its clinical owner.

Microsoft’s $convert-data endpoint can help transform legacy HL7v2, C-CDA, or JSON into FHIR, but conversion is not validation. A transformed payload that is accepted by the target still needs business-level verification.

5. Test Integrations as the Real World Does

This is where most migration projects stumble. A test client that exercises read, search, update, and delete operations from a development workstation may miss the exact failure that a production integration engine hits at 3 AM. Match the test to the real caller:
- Use the same identity and token-acquisition method
- Run from the same network segment or Azure subscription
- Test expected success paths and expected authorization denials (a permissive bind can mask security holes)
- Include multi-step workflows: a patient discharge message triggering a FHIR write, then a subsequent read

If a workload runs overnight or on a weekly schedule, schedule its test during the actual time window. Don’t assume silence means success. Some integrations only fire on certain events; trigger them deliberately.

6. Plan the Cutover with a Binary Go/No-Go

Pick a change window well before September 30, 2026, and own every step. Freeze unrelated configuration changes. Assign an execution owner, an approver, and a communication chain for support.

For each workload, define the cutover moment—the exact second you flip the endpoint URL or update DNS. Immediately afterward, run focused monitoring: watch for authentication failures, connection timeouts, authorization denials, and application error spikes. Have owners execute a small set of clinical or business transactions that prove the service is usable, not just reachable.

Keep the old endpoint alive until monitoring confirms all clients have switched, but remember: after the retirement date, that endpoint shuts down permanently. Your rollback plan must account for that. Rollback is only safe before the deadline; after it, the old service can’t be revived.

For any workload that fails the cutover gate, you have a hard choice: go with an explicitly accepted exception (rarely advisable) or leave it marked “no-go” and escalate. A workload that’s “in progress” on September 29 is a guaranteed outage on September 30.

Outlook: Owning the Last Mile

The final milestone isn’t the date you exported data or provisioned the new FHIR service. It’s the moment every single production workload is confirmed to be running against Azure Health Data Services before the retirement timer hits zero. That requires a disciplined register, six checkpoints per workload, and an organizational commitment that nothing is truly migrated until it’s proven with a real test by the designated owner.

After September 2026, any remaining Azure API for FHIR endpoint will be dead weight in your Azure subscription, inaccessible and unsupported. For healthcare IT teams, this isn’t just another cloud lifecycle event—it’s a patient-safety and business-continuity exercise that will test how well you really know your integration landscape. Start the inventory now, and treat every forgotten client as an outage waiting to happen.