Microsoft has set a firm retirement date for Azure API for FHIR: September 30, 2026. The clock started ticking on April 1, 2025, when the company stopped accepting new deployments. For the healthcare IT teams that built clinical workflows around the service, the real deadline isn’t the data migration—it’s tracking down every Windows service, scheduled task, and configuration file that still points to the old endpoints.

The Retirement Timeline: Key Dates

Azure API for FHIR was Microsoft’s first managed offering for the Fast Healthcare Interoperability Resources (FHIR) standard, launched to let healthcare organizations exchange data in a cloud-native way. It is now being replaced by the FHIR service within Azure Health Data Services, a more integrated platform that also handles DICOM imaging and offers deeper connections to other Azure services.

After September 30, 2026, the legacy service will no longer function. Customers will be unable to 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. The block on new deployments has been in place since April 1, 2025, meaning only existing users are affected—but that group includes hospitals, clinics, labs, and health-tech vendors who have built custom solutions around the service.

A brief timeline:
- April 1, 2025: No new Azure API for FHIR deployments allowed.
- September 30, 2026: Full retirement. Service goes offline completely.

Organizations still running on the legacy platform must transition to Azure Health Data Services FHIR service before that date.

Why Windows Healthcare Environments Are Vulnerable

The retirement poses a unique challenge for any organization that runs integration engines, web portals, or back-end processes on Windows. A typical setup might include an IIS-hosted web application with a web.config pointing to azurehealthcareapis.com, a Windows service that pulls patient data via an SDK, a scheduled task that exports reports using the old FHIR URL, or even a legacy desktop tool with a hardcoded JSON settings file. None of these are automatically discoverable through the Azure portal.

Microsoft’s migration guidance makes clear that moving FHIR data is only one part of the transition. Application workloads must be redirected to new endpoints, and all permissions must be reconfigured from scratch. A single missed dependency can silently break a prescription workflow, a patient portal, or a nightly batch job weeks after the data appears to be successfully moved.

The timeline adds pressure. While the final day is over a year away, the complexity of discovery alone can consume months, especially in heavily regulated healthcare environments where change control and validation are paramount. Administrators who wait until the summer of 2026 risk uncovering critical dependencies only when they fail in production.

The Road to Here: Azure’s Health Data Evolution

Azure API for FHIR first appeared in 2018, riding the wave of the 21st Century Cures Act and a growing push for interoperability. It let organizations stand up a managed FHIR server without managing the underlying infrastructure. Over time, Microsoft expanded its health-data ambitions, introducing Azure Health Data Services in 2022. That platform combines FHIR, DICOM, and MedTech services within a unified workspace, offering better integration with tools like Azure Synapse Analytics, Power BI, and Microsoft Entra.

The retirement echoes previous transitions in the Azure ecosystem—most notably the sunsetting of Azure AD Graph in favor of Microsoft Graph—where customers had to migrate not just data but identity and application configurations. Microsoft has given a generous notice period, and the block on new deployments serves as a final warning. Healthcare organizations that haven’t started planning are now officially behind.

A Practical Migration Roadmap for Windows Admins

Microsoft’s recommended four-stage plan—assess readiness, prepare the target service, migrate data and applications, then cut over—is sound. Below is a breakdown that emphasizes what Windows administrators can do now to avoid a last-minute scramble.

1. Inventory the Legacy Footprint

Start by gathering every instance of Azure API for FHIR across all subscriptions and tenants. The resource type is Microsoft.HealthcareApis/services. Run an Azure Resource Graph query to list them alongside their workspace-based successors (type microsoft.healthcareapis/workspaces/fhirservices) so you can tell them apart. For each legacy resource, record its subscription, resource group, region, endpoint URL, authentication audience, access policies, and any SMART on FHIR proxy settings. This register becomes your migration source of truth.

Every client application that talks to the FHIR service authenticates through Microsoft Entra (formerly Azure AD). In the Entra admin center, examine app registrations and enterprise applications for redirect URIs containing azurehealthcareapis.com or the string /AadSmartOnFhirProxy/callback. These are hallmarks of the legacy service. Note the application owners, secrets, certificates, and assigned permissions. Because Microsoft requires permissions to be set up anew on the target service, you’ll need to replicate and test each one. Also check service principals tied to Windows services or scheduled tasks—they often use certificates stored in the local machine’s certificate store or in Azure Key Vault.

3. Comb Through Windows Configs

This is where the Azure portal gives way to old-fashioned scripting. Focus on directories likely to contain configuration: IIS root (C:\\inetpub), application folders under C:\\ProgramData, custom script paths, and deployment directories. Use PowerShell to search for the string “azurehealthcareapis.com” and the proxy marker “AadSmartOnFhirProxy” in .config, .json, .xml, .yml, .ps1, .bat, and other common text files. Don’t forget to scan:

  • Web.config files and their transforms (Debug, Release, environment-specific).
  • Windows service install directories (often under C:\\Program Files or custom paths).
  • Scheduled Tasks: export all tasks and search for FHIR-related URLs in the Actions. A task that runs monthly may not appear until later, so it’s easy to miss.
  • Desktop and kiosk applications: some older clinical apps store configuration in the registry. A quick reg scan can surface hidden endpoints.
  • Deployment scripts and CI/CD pipelines: YAML files, Terraform templates, or release definitions might reference the old FHIR URL.

The goal is to generate a candidate list, not a final truth. Later, you’ll validate which are active.

4. Separate Active Traffic from Dead Code

A configuration match doesn’t guarantee active usage. A retired test server may still have an old web.config. To separate live dependencies from debris, tap into Azure API for FHIR diagnostic logs, IIS logs, application logs, and network traffic monitors. Look for recent requests with client identifiers, source IPs, and user agents. Correlate these with the inventory from step 3. Classify each dependency as:

  • Confirmed active (recent traffic).
  • Expected but infrequent (e.g., monthly report).
  • Configured but apparently inactive (needs owner confirmation).
  • Historical or duplicate (safe to retire).
  • Unknown (escalate).

In clinical settings, do not assume that an “inactive” configuration is harmless. Critical workflows like quality reporting or third-party referrals might run only quarterly. Engage application owners and clinical informatics teams to confirm.

5. Stage the Move, Workflow by Workflow

Rather than a single big-bang move, align migration waves with business workflows. First, provision the target Azure Health Data Services FHIR workspace and service. Recreate permissions, application registrations, and monitoring alerts. Then migrate data using Microsoft’s recommended tools or community scripts. Validate not just record counts but that representative clinical resources (patient, observation, medication request) can be consumed correctly by your apps.

Next, move low-risk, non‑clinical applications first—such as analytics dashboards or research tools. Redirect their endpoints, update secrets, and test thoroughly, including failure scenarios. Monitor for authentication errors, unexpected response codes, and latency. Each wave should have a documented rollback decision: can the old endpoint be temporarily re-enabled? How will data written during the test be reconciled? Who can authorize a rollback, and when does it become unsafe because the two systems have diverged?

6. Cut Over and Clean Up

The last wave will involve patient-facing or clinical systems. This requires scheduled downtime, even if the design aims for minimal disruption. Share a precise timeline with application owners, clinical operations, the service desk, security teams, and interface support. Ensure on-call staff knows the escalation path.

After all dependencies are confirmed migrated, decommission the old service: stop legacy pipelines, remove obsolete credentials, archive the inventory, and formally retire the Azure resource. Do this well before September 30, 2026, so that the retirement date is a backstop, not the trigger for chaos.

The Clock Is Loud

Microsoft’s 18-month notice is generous by cloud standards, but the complexity of healthcare IT means that every month of delay shrinks the margin for error. The block on new deployments already forces any expansion or new project onto Azure Health Data Services, so the technical direction is clear. The big unknown is how many organizations will discover critical dependencies only in the final quarter. For Windows administrators in healthcare, the message is straightforward: the database can be migrated in a weekend; the dependency inventory cannot. Start the search now.