Azure API for FHIR Retires September 30, 2026: Find Windows Dependencies

Microsoft will retire Azure API for FHIR on September 30, 2026, but healthcare IT teams should treat endpoint discovery—not database migration—as the immediate priority. Before planning a cutover, administrators need to identify every Windows service, IIS application, scheduled task, desktop utility, script, and service account that still references azurehealthcareapis.com or the legacy SMART proxy callback path.
Microsoft’s migration guidance makes clear that moving FHIR data is only part of the transition. Application workloads must point to new endpoints, permissions must be configured again, and jobs previously attached to the legacy service must be recreated or redirected. A missed dependency could therefore remain invisible until a prescription workflow, patient portal, interface engine, or nightly export fails.
New Azure API for FHIR deployments have already been blocked since April 1, 2025. After September 30, 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.

Build the Dependency Inventory Before Moving Data​

A useful inventory begins with the Azure resource but does not stop there. The legacy resource tells administrators what is being retired; it does not necessarily reveal which Windows machines, application registrations, credentials, or third-party integrations depend on it.
Use this sequence to build a defensible inventory:

1. Identify every legacy Azure API for FHIR resource across all subscriptions and tenants.
2. Record each service name, subscription, resource group, region, endpoint, authentication audience, access policy, and SMART proxy setting.
3. Search Microsoft Entra app registrations for endpoint references, redirect URIs, permissions, owners, and credentials associated with those services.
4. Inspect Key Vault secret names and application configuration references without exporting secret values into an unsecured report.
5. Search Windows servers and source repositories for legacy domains and SMART proxy callback paths.
6. Map each match to an application owner, service account, clinical workflow, support team, and acceptable outage window.
7. Confirm the dependency through logs or controlled testing instead of assuming every configuration match represents active traffic.

Azure Resource Graph is the practical starting point for organizations with multiple subscriptions. The legacy service resource type is Microsoft.HealthcareApis/services, while the target FHIR service under Azure Health Data Services uses the workspace-based resource type Microsoft.HealthcareApis/workspaces/fhirservices.
An initial Resource Graph query can separate the two:

Resources
| where type in~ (
    'microsoft.healthcareapis/services',
    'microsoft.healthcareapis/workspaces/fhirservices'
)
| project subscriptionId, resourceGroup, name, type, kind, location, id
| order by type asc, name asc

The output should become the authoritative service register, but not the complete dependency register. Add columns for application owner, technical owner, production status, migration wave, validation state, rollback decision, and final decommission approval.
For Key Vault, Resource Graph can identify vaults but should not be treated as a secret-content search engine. Inventory the vaults, then have authorized application owners inspect secret names, tags, configuration mappings, and deployment templates for references to each legacy FHIR service. Avoid copying credentials or protected configuration into spreadsheets, tickets, or migration chat channels.

Search Windows Where Azure Cannot See​

The most dangerous dependencies are often outside the Azure resource graph: a PowerShell script copied to an integration server, an IIS application with an old web.config, a Windows service installed years ago, or a desktop utility using a locally stored JSON settings file.
Begin with application source, deployment repositories, configuration-management systems, and known integration directories. Search for both the legacy domain and the SMART proxy marker:

$Roots = @(
    'C:\inetpub',
    'C:\ProgramData',
    'C:\Scripts',
    'D:\Apps'
)

$Patterns = @(
    'azurehealthcareapis\.com',
    'AadSmartOnFhirProxy',
    'FhirServerUrl',
    'FHIR_URL'
)

Get-ChildItem $Roots -Recurse -File -ErrorAction SilentlyContinue |
    Where-Object {
        $_.Extension -in '.config','.json','.xml','.yml','.yaml',
                         '.ps1','.cmd','.bat','.cs','.js','.txt'
    } |
    Select-String -Pattern $Patterns |
    Select-Object Path, LineNumber, Pattern

Run searches under an account authorized to inspect the relevant directories, and protect the output. Matching lines can contain client identifiers, Key Vault references, connection details, or other sensitive configuration.
The search scope should include:

• IIS web.config files, application settings, deployment transforms, and environment-specific overrides.
• Windows service installation directories and configuration stored under C:\ProgramData.
• Task Scheduler actions, arguments, scripts, and the accounts under which tasks run.
• PowerShell modules, batch files, integration-engine scripts, and operational runbooks.
• Desktop application configuration under program directories and user profiles where policy permits inspection.
• CI/CD variables, infrastructure templates, release definitions, and configuration-management repositories.
• Registry values used by older Windows applications to store server names or API settings.

Scheduled tasks deserve special attention because they may run weekly, monthly, or only during a reporting cycle. A task can appear healthy for weeks after a test cutover simply because its trigger has not occurred.
Export task definitions and search their command lines:

Get-ScheduledTask | ForEach-Object {
    foreach ($Action in $_.Actions) {
        [pscustomobject]@{
            TaskPath  = $_.TaskPath
            TaskName  = $_.TaskName
            Execute   = $Action.Execute
            Arguments = $Action.Arguments
            RunAs     = $_.Principal.UserId
        }
    }
} | Where-Object {
    $_.Arguments -match 'azurehealthcareapis|FHIR|AadSmartOnFhirProxy' -or
    $_.Execute -match 'FHIR'
}

This will not find an endpoint hidden inside a script or compiled executable, but it identifies where deeper inspection is required. Administrators should also review Windows services by executable path and service account, then trace those binaries back to their configuration and owners.

---

Entra Applications Reveal the Authentication Blast Radius​

Changing the endpoint does not automatically transfer authorization. Microsoft explicitly requires permissions to be set up again for application workloads, making the Entra inventory as important as the data migration.
For every legacy FHIR service, examine App registrations and Enterprise applications for:

• Redirect URIs containing azurehealthcareapis.com or /AadSmartOnFhirProxy/callback.
• Applications whose names, owners, documentation, or deployment records connect them to the service.
• Client applications using service principals rather than interactive user authentication.
• Certificates and secrets that are also deployed to Windows services, IIS application pools, or scheduled tasks.
• Access policies and role assignments that must be reproduced and tested against the target service.
• Authentication audiences or token requests tied to the old resource identifier.

The /AadSmartOnFhirProxy/callback path is particularly valuable as a discovery signature. Its presence in a redirect URI, configuration file, or troubleshooting document strongly suggests that the application was designed around the legacy SMART on FHIR proxy flow and requires more than a simple hostname replacement.
Do not assume a successful token request proves migration readiness. A client may obtain a token but still use the wrong audience, lack the necessary permissions on the target service, send requests to the old URL, or depend on callback behavior that has changed.
This is the same retirement pattern Windows administrators have encountered with Azure AD Graph and other Microsoft service transitions: identity, endpoint, and application dependencies must be migrated together. A technically complete data copy cannot compensate for an unmodified client or an orphaned service principal.

Logs Separate Live Dependencies From Historical Debris​

Configuration searches produce candidates, not proof. A retired test application can contain the same endpoint as an active clinical service, while an active dependency may construct its URL dynamically and never appear as a complete string on disk.
Use available Azure API for FHIR audit and diagnostic records, application logs, proxy logs, IIS logs, endpoint-monitoring data, and Windows Event Log entries to identify actual callers. Correlate request activity with client identities, source systems, operational schedules, and application owners.
The resulting inventory should classify each dependency as:

• Confirmed active through recent request or workflow evidence.
• Expected active but not yet observed because it runs infrequently.
• Configured but apparently inactive, pending owner confirmation.
• Historical or duplicate, approved for removal.
• Unknown, requiring escalation before cutover.

Unknown entries should not silently fall into the decommission category. In healthcare environments, low-frequency workflows may include month-end reporting, external referrals, quality submissions, disaster-recovery processes, or specialist applications that are difficult to reproduce on demand.

Cut Over by Workflow, Not by Server Count​

Microsoft recommends assessing readiness, preparing the target service and its configurations, migrating data and applications, and then cutting over and decommissioning the legacy account. Healthcare organizations should translate that sequence into migration waves organized around clinical and operational workflows.
First, provision and configure the target Azure Health Data Services FHIR service. Recreate the required identity permissions, application settings, jobs, and monitoring before directing production clients to it.
Next, migrate and validate the data using an approved migration pattern. Validation should cover more than a total record count: teams should confirm that the resources needed by representative workflows can be retrieved and interpreted correctly by the applications that consume them.
Then move lower-risk clients first. Update endpoints and permissions, execute both routine and failure-path tests, and monitor authentication failures, authorization denials, unexpected response handling, latency, retries, and application errors.
A production wave should have a written rollback decision. That plan needs to state whether the old endpoint can be restored temporarily, how writes made during the test window will be reconciled, who can authorize rollback, and when rollback becomes unsafe because the two services have diverged.
The final cutover should include explicit downtime and communication planning even if the design aims for minimal disruption. Application owners, clinical operations, service desk staff, security teams, and interface support teams need a shared timeline and clear escalation route.
Only after every confirmed dependency has passed validation should teams stop old pipelines, remove obsolete credentials and configuration, archive the inventory and test evidence, and decommission the legacy account. September 30 must be the retirement backstop, not the first full-scale production test.
The remaining window gives healthcare IT teams a choice: discover dependencies now and conduct a phased, observable cutover, or let the retirement date discover them through failed Windows services and broken clinical workflows. The database may be the largest asset being moved, but the dependency inventory is what determines whether anyone can still use it.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Move Azure API for FHIR instance to a different subscription or resource group | Microsoft Learn

   This article describes how to move Azure an API for FHIR instance

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Azure AD Graph API Retirement: Essential Migration Guide for 2025 | Windows Forum

   Microsoft’s looming retirement of the Azure AD Graph API is no longer a warning on the horizon—it’s now a fixed endpoint for IT departments, software...

   windowsforum.com

 

[ChatGPT]

Azure API for FHIR production workloads should not be cleared for cutover until they pass a documented readiness gate covering endpoint replacement, Microsoft Entra authorization, reconciled data, integration results, rollback, and named operational ownership. Microsoft will retire Azure API for FHIR on September 30, 2026, at 10:59:59 PM Pacific Time; for teams still running Gen 1, the remaining work is not a general migration project but a deadline-bound decision on whether each workload is actually safe to move.
Microsoft’s migration documentation points customers to the FHIR service in Azure Health Data Services, but it is explicit that the move requires both data migration and application changes. That distinction matters: a successful export and import does not prove that a Windows-hosted integration service, scheduled task, IIS application, PowerShell automation, clinical client, or third-party connector can authenticate and work against the replacement service.
The April 1, 2025 cutoff for new Azure API for FHIR deployments is already in the past. The live risk now is different: every remaining account becomes unavailable for management, data access, updates, and customer support after the September retirement. There is no reasonable “wait and see” position for a production endpoint carrying protected health information.

Treat Each Endpoint as a Separate Go/No-Go Decision​

A health system may describe its status as “migrated” while still having one forgotten application pointed at the retiring service. The safer model is a workload register: each client, interface, job, and consumer gets its own migration record and its own approval decision.
Start by assigning a unique workload name and an accountable owner to every production dependency. Include applications running on Windows Server, Azure virtual machines, developer workstations, integration engines, reporting pipelines, external vendors, and any service account used for unattended access. The register should identify the current Azure API for FHIR endpoint, the target FHIR service endpoint, the business function, the data classes involved, and the team authorized to declare success.
The practical inventory work is often less glamorous than data export, but it catches the outages that a platform-only project misses. Review application configuration, environment variables, IIS settings, Windows services, Task Scheduler jobs, deployment pipelines, scripts, monitoring rules, DNS entries, firewall rules, and stored secrets. Search source repositories and operational runbooks for the retiring endpoint and for client IDs associated with the old service.
WindowsForum readers following other Azure retirements will recognize the pattern: endpoint discovery comes before a credible cutover plan. The same discipline applies here. A workload with no confirmed owner, no verified replacement endpoint, or no tested authentication path is not “low risk”; it is not ready for cutover.

---

The Six Gates That Must Pass Before Cutover​

The final checkpoint should be short enough to operate under change-control pressure, but strict enough that it prevents an optimistic migration status from becoming a clinical or operational outage.

1. The replacement endpoint is deployed and recorded. The workload owner must confirm the Azure Health Data Services FHIR service endpoint that will replace the retired Azure API for FHIR endpoint. Update every configuration location rather than relying on redirects, assumptions, or documentation that merely says the target exists.
2. Microsoft Entra authorization works for the real caller. Test interactive and noninteractive access separately. A successful administrator login does not establish that a Windows service account, managed identity, automation credential, application registration, or third-party client can obtain the appropriate access and complete its normal FHIR operations.
3. The data migration is reconciled, not merely completed. Record the source export scope, the target import scope, exceptions, rejected resources, and remediation decisions. Teams need evidence that expected resource populations arrived, that critical references resolve as intended, and that the target contains the records required for normal clinical and business workflows.
4. Integration tests cover the operations that matter. Execute representative reads, writes, searches, updates, and workflow-specific queries from the actual applications or equivalent test clients using production-like identities. Test results should include both expected success paths and expected denials, so a permissive configuration is not mistaken for a secure one.
5. A rollback plan exists inside the remaining service window. Define exactly what triggers rollback, who can authorize it, what configuration will be restored, and how users will be notified. The critical caveat is that rollback is only a meaningful safety mechanism before retirement; after September 30, the old Azure API for FHIR service cannot be used as an operational fallback.
6. Operations has accepted the new steady state. The support owner must have monitoring, escalation contacts, credential-renewal responsibilities, runbooks, and change records for the target service. A migration is incomplete if only the project team knows how the new environment works.

The point of the checklist is not to generate paperwork. It is to make a binary decision visible: go, no-go, or go with an explicitly accepted exception. A workload marked “in progress” near the deadline has no operational meaning.

Data Reconciliation Needs Clinical Context, Not Just Counts​

Raw resource totals are useful, but they are not sufficient evidence for a PHI migration. Counts can match while a subset of important resources is missing, references point nowhere, or a workload’s key searches behave differently after the move.
Build reconciliation around the way each application uses FHIR. For an integration that retrieves patient-linked records, test representative patient flows and verify that the expected connected resources can be retrieved. For reporting or population workflows, test the searches and filters used by the real job. For write-heavy applications, validate that the application can create or update the intended resources and then retrieve the resulting records through its ordinary path.
Document exceptions rather than silently normalizing them. If an export scope excluded data, a target import rejected records, a resource type is intentionally absent, or an application depends on a behavior that has not been reproduced, log it with an owner and disposition. This produces the audit evidence that security, compliance, and clinical stakeholders will need when they ask what “migration complete” actually meant.
Microsoft’s documentation also describes data conversion capabilities such as the $convert-data endpoint and Liquid templates. Those tools can be part of an ingestion design, but conversion is not validation. A transformed payload that is accepted by a target service still needs business-level verification against the workflow it is meant to support.

---

Authorization and Networking Are Where Late Failures Hide​

The target FHIR service is not simply the old endpoint under a new product label. Teams should assume that endpoint addresses, authorization assignments, network paths, quotas, regional design choices, and infrastructure-as-code resource definitions require review. The right question is not whether the target is “configured similarly,” but whether the workload can execute its required operations under the target’s actual controls.
For Microsoft Entra authorization, test the principal used in production, with the same token-acquisition path and same runtime location. A test from an administrator’s desktop may bypass the exact constraint that will affect an unattended Windows service. Confirm that secret locations, certificate handling, renewal processes, and owner contacts are current before the cutover change is approved.
Networking requires the same evidence-first approach. Validate the path from each relevant runtime environment to the target endpoint and verify that any private networking, name resolution, proxy behavior, firewall controls, or allowlists are operating as intended. Do not close the old path until monitoring confirms that clients have stopped calling the retiring endpoint.
Infrastructure teams should also compare their deployment definitions line by line. Any templates, scripts, policy assignments, and automated provisioning that refer to Azure API for FHIR must be replaced or retired. A manually successful migration can still be undone later if a pipeline recreates old assumptions during a repair, scale-out, or disaster-recovery exercise.

Cutover Day Should Be Boring by Design​

The cutover plan should specify a change window, an execution owner, an approver, an application-by-application sequence, and a communication route for support teams. Freeze unrelated configuration work around the change, preserve the final reconciliation evidence, and capture the exact time each endpoint configuration changes.
Immediately after switching clients, use focused monitoring rather than broad confidence statements. Watch for authentication failures, connection failures, unexpected authorization denials, elevated application errors, and signs that a workload is still attempting to use the retiring endpoint. Have owners perform the small number of business transactions that establish the service is usable, not merely reachable.
Do not confuse a quiet monitoring dashboard with proof that every consumer has moved. Some integrations run only overnight, weekly, or on an event-driven schedule. Their readiness gate should include a deliberate execution before the retirement date, not an assumption that silence means success.

Frequently Asked Questions​

Is September 30, 2026 the date to finish planning or the date to finish migration?
It is the retirement date. Microsoft lists the retirement time as 10:59:59 PM Pacific Time on September 30, 2026, so production cutovers, validation, and any rollback period should be completed before then.
Can we keep Azure API for FHIR as a temporary fallback after retirement?
No. Microsoft says customers will no longer be able to manage accounts, access data through the portal or APIs and client tools, receive updates, or receive customer support after retirement.
Does moving data complete the migration?
No. Microsoft states that migration requires data migration and application updates to use the FHIR service in Azure Health Data Services. Endpoint, authorization, network, and workflow testing remain separate work.
What is the minimum sign-off group?
At minimum, the application owner, the platform or Azure owner, the identity/security owner, and the operational support owner should each confirm the portion they control. For clinically significant workloads, the relevant business or clinical owner should accept the workflow validation as well.
The final milestone is not the date a target FHIR service was created or the date an export succeeded. It is the date every remaining production workload has named owners, passed the six gates, and been observed running against Azure Health Data Services before Azure API for FHIR becomes inaccessible on September 30.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Data conversion for Azure API for FHIR | Microsoft Learn

   Use the $convert-data endpoint and customize-converter templates to convert data in Azure API for FHIR.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Azure API for FHIR Retires September 30, 2026: Find Windows Dependencies | Windows Forum

   Microsoft will retire Azure API for FHIR on September 30, 2026, but healthcare IT teams should treat endpoint discovery—not database migration—as the...

   windowsforum.com