Migrating from Azure AI Foundry to Microsoft Foundry: SDK and Config Changes

6 min read3.5k

At Ignite 2025 (November 18), Microsoft renamed Azure AI Foundry to Microsoft Foundry — the second rename in twelve months after Azure AI Studio became Azure AI Foundry at Ignite 2024. This post isn't another "here's what the rebrand means" explainer. It's a runbook: what actually breaks, what's cosmetic, and a checklist to run against your own repo.

The rename, visually

Step 1: Inventory before you touch anything

Before changing a single line, catalog what you have:

bash
grep -rn "azure.ai.resources\|AIClient\|azure-ai-resources" --include="*.py" .
grep -rn "Azure AI Studio\|Azure AI Foundry" --include="*.md" --include="*.py" .
grep -rn "azureml-sdk\|azureml.core" --include="*.py" .

Categorize each hit into: (1) purely cosmetic references in docs/comments, (2) SDK calls that still work under the new name, (3) SDK calls that are on a deprecation path regardless of the rebrand.

What's cosmetic (safe to defer)

  • Portal URLs and branding in internal wikis/runbooks — update opportunistically, not urgently.
  • The resource provider naming in the Azure portal UI — your existing resources kept working under the new name automatically; no resource migration was required.
  • References to "Azure AI Studio" in old ADRs — leave them, they're historical record, just add a note.

What's load-bearing (needs actual code changes)

Azure OpenAI Service → Foundry Models. The service itself wasn't deprecated — it's still creatable as a standalone resource and also surfaced inside the broader Foundry model catalog. But if you were calling the older azure.ai.resources client pattern, you should move to azure-ai-projects:

python
# Before
from azure.ai.resources.client import AIClient
client = AIClient(
    subscription_id="...",
    resource_group_name="...",
    project_name="...",
    credential=DefaultAzureCredential(),
)

# After
from azure.ai.projects import AIProjectClient
client = AIProjectClient(
    endpoint="https://your-foundry-resource.services.ai.azure.com/api/projects/your-project",
    credential=DefaultAzureCredential(),
)

Note the shift from subscription/resource-group/project-name params to a single project endpoint URL — this is the bigger structural change, and it means any code building connection strings from separate ID fragments needs to be rewritten, not just renamed.

Azure Cognitive Services / Azure AI Services → Foundry Tools. Same capability set (vision, speech, language, document processing), now exposed through Foundry's tools layer with shared identity and observability. If you were calling these as standalone Cognitive Services endpoints with their own API keys, migrating to Foundry Tools means moving auth to the shared Entra ID / managed-identity model — this is a real change to your auth code, not just an endpoint rename.

Assistants API → Foundry Agent Service. This one has a hard deadline: the Assistants API retires August 26, 2026. Foundry Agent Service runs on the Responses API instead. If you have Assistants API code in production, this is the most time-sensitive item on your migration list — start planning now even though the deadline is eight months out, because the API shape is meaningfully different (see Part 6 for the deeper dive).

Old name to new name, at a glance

OldNewMigration urgency
Azure AI Studio / Azure AI Foundry portalMicrosoft Foundry portalLow — both portal versions currently supported
Azure OpenAI Service (via azure.ai.resources)Foundry Models (via azure-ai-projects)Medium — constructor signature changed
Azure Cognitive Services / Azure AI ServicesFoundry ToolsMedium — auth model shifts to managed identity
Assistants APIFoundry Agent Service (Responses API)High — hard retirement Aug 26, 2026
AzureML SDK v1SDK v2 / azure-ai-projectsHigh — end-of-support June 30, 2026

Migration checklist

Run this against your repo before calling the migration "done":

  • No remaining imports from azure.ai.resources
  • All AIClient(subscription_id=..., resource_group_name=..., project_name=...) calls replaced with AIProjectClient(endpoint=...)
  • Cognitive Services calls that used standalone API keys now use managed identity via Foundry Tools
  • Any Assistants API usage flagged with a migration ticket and owner (deadline: Aug 26, 2026)
  • AzureML SDK v1 usage flagged separately (deadline: June 30, 2026 — covered fully in Part 4)
  • CI/CD pipelines pinning SDK versions updated to azure-ai-projects>=2.0.0
  • Internal docs/runbooks updated opportunistically, not blocking release

The trap: treating this as "just a rename" end to end

The failure mode we see most often: a team greps for "Azure AI Foundry" → "Microsoft Foundry", does a find-and-replace across the codebase, ships it, and calls it done — without noticing that the AIClient constructor signature actually changed, or that Cognitive Services auth needs to move off static keys. The string rename is the easy 20%. The constructor and auth changes are the 80% that actually determines whether your pipeline works.

The auth migration in more depth

The auth shift deserves more attention than a one-line checklist item, because it's the part most likely to cause a production outage if rushed. Under the old Cognitive Services model, many teams authenticated with a static subscription key passed as a header:

python
# Old pattern — static key, works but doesn't survive the Foundry Tools migration cleanly
import requests

headers = {"Ocp-Apim-Subscription-Key": "your-static-key"}
response = requests.post(cognitive_services_endpoint, headers=headers, json=payload)

Under Foundry Tools, the recommended (and in many enterprise environments, enforced-by-policy) pattern is Entra ID token-based auth via managed identity:

python
from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()
token = credential.get_token("https://cognitiveservices.azure.com/.default")

headers = {"Authorization": f"Bearer {token.token}"}
response = requests.post(foundry_tools_endpoint, headers=headers, json=payload)

The practical migration risk: static keys don't expire on a schedule you control, so teams sometimes don't notice they're still using them until a security review flags it or the key is rotated centrally and everything using the old key breaks at once. Audit for hardcoded or environment-variable-stored subscription keys specifically, not just import statements — the auth change is a separate migration axis from the SDK import change, and needs its own line item on your checklist and its own testing pass (confirm managed identity has the right RBAC role assignments before cutting over, not after).

What's next

Part 4 covers the other migration on your plate — AzureML SDK v1's June 30, 2026 end-of-support — with an actual migration script and a test harness for catching behavioral drift, not just import errors.

References