Azure AI Foundry vs Azure OpenAI: The 2026 Decision

The architects’ question in early 2026 is the same one they asked in late 2025, just sharper now: do I move my Azure OpenAI deployment to Microsoft Foundry, or do I leave it alone? The Microsoft sales motion says yes, move now. Microsoft Learn says it is opt-in and reversible. Microsoft Q&A is full of teams who upgraded and lost private link configuration, or did not upgrade and got blocked from a feature they needed.

The honest answer is that the right move depends on five things: whether you are building agents, whether you need non-OpenAI models, whether you have an Assistants API deployment, whether your compliance posture tolerates the role-assignment expansion that comes with the upgrade, and whether your platform team is ready to recreate private endpoints. None of these are deal-breakers. All of them deserve a written decision.

This article is the decision tree. It separates the rebrand (which changed almost nothing in the SKU) from the platform consolidation (which changed almost everything in the developer experience), maps the seven scenarios where each path wins, and flags the mechanics that break during migration. It is current as of April 2026, with citations grounded in Microsoft Learn and the Foundry Agent Service announcements at Ignite 2025.

What the Rebrand Actually Changed (and What It Did Not)

The naming convention is the smallest part of this. Five concrete changes happened underneath.

One: the resource model collapsed. Pre-rebrand, a typical AI deployment provisioned three Azure resources: an Azure OpenAI account (kind: OpenAI), an Azure AI Services account, and an AI Hub. Post-rebrand, a single Foundry resource (kind: AIServices with allowProjectManagement: true) hosts everything as Projects. One resource, multiple Projects, each Project a unit of team isolation, RBAC, and connection ownership.

Two: three FQDNs replaced one. A Foundry resource exposes three endpoints:

• {name}.openai.azure.com for Azure OpenAI compatibility (existing AOAI apps keep working)
• {name}.services.ai.azure.com for the Foundry data plane and partner models like Anthropic Claude
• {name}.cognitiveservices.azure.com for legacy Cognitive Services and Foundry Tools

This matters for private link. After upgrade, the existing private endpoint that pointed at *.openai.azure.com is preserved, but it does not cover the two new FQDNs. You must recreate the private endpoint with additional IP configurations or Foundry-only features fail silently from inside the spoke.

Three: the API surface stabilized. Old: monthly preview api-version=2024-10-21 strings and a stack of Azure-specific SDK clients. New: stable /openai/v1/ routes (GA from August 2025) and a vanilla OpenAI() client pointed at https://{name}.openai.azure.com/openai/v1/. Preview features are gated by HTTP headers (aoai-evals: preview) instead of new api-version strings. The new path drops api-version entirely and works for Azure OpenAI, DeepSeek, Grok, and other Foundry-direct models on the same code path.

Four: agents are a different runtime. The Assistants API, which lived under Azure OpenAI, is in a 16-month deprecation runway. Hard retirement: August 26, 2026. The replacement is the Foundry Agent Service, built on the Responses API, with renamed primitives:

Old (Assistants)	New (Foundry Agent Service)
Threads	Conversations
Runs	Responses
Messages	Items
Assistants	Agent Versions

If you have any Assistants API code in production, the migration tool at aka.ms/agent/migrate/tool is your starting point. The migration is a code rewrite, not a configuration change.

Five: the model catalog opened up. Azure OpenAI is one model family inside the Foundry catalog. The catalog now includes 1,900+ models split into two procurement paths. Models sold directly by Azure (Microsoft SLA, single Azure bill): GPT-5 family, MAI-DS-R1, Grok-3 and Grok-4 variants, Llama-3.3-70B-Instruct, Llama-4-Maverick, DeepSeek-V3 and R1 series, Mistral-Large-3, Cohere command-a, Phi-4, gpt-oss-120b, and others. Models from partners and community (via Azure Marketplace, separate billing rules): Anthropic Claude (Opus 4.7/4.6/4.5, Sonnet 4.6/4.5, Haiku 4.5, all preview as of April 2026), Stability, others.

For Anthropic Claude specifically, the integration is not OpenAI-compatible. It uses a separate path (https://{resource}.services.ai.azure.com/anthropic/v1/messages), the AnthropicFoundry SDK, and Anthropic’s Messages API. Claude on Foundry is available in East US 2 and Sweden Central regions. Enterprise Agreement / MCA-E subscriptions only. Azure Content Safety filters are off by default and must be wired separately. Going direct to Anthropic’s API is generally the same price or lower; the reasons to use Foundry-Claude are procurement consolidation, Entra identity, and Azure compliance posture, not cost.

The Naming Cheat Sheet

Term	What it is now	Was previously
Microsoft Foundry	Brand for the unified AI PaaS	Azure AI Foundry, Azure AI Studio
Foundry resource	ARM Microsoft.CognitiveServices/accounts with kind: AIServices and allowProjectManagement: true	Hub + AOAI + AI Services (3 separate resources)
Foundry project	Child resource for team and use-case isolation	AI Studio project / Hub project
Foundry Hub (classic)	Legacy resource type, no new feature investment	AI Hub
Azure OpenAI resource	ARM kind: OpenAI, still GA, still creatable	Same
Foundry Tools	Speech, Vision, Language, Content Safety	Azure AI Services
Foundry Models	The 1,900+ model catalog	Models in Azure AI Studio plus AOAI
Foundry Agent Service	GA agents runtime (Responses API + Conversations)	Assistants API (retiring 2026-08-26)
Foundry IQ	Managed knowledge layer (preview) on Azure AI Search agentic retrieval	”On Your Data” / custom RAG
Foundry Local	On-device runtime + SDK, ONNX-based	(new)

Side-by-Side Capability Comparison

The Decision Tree

Eight scenarios cover most enterprise architectures. Find yours.

Scenario 1: Greenfield, building agents. Use Foundry. The Agent Service is GA, the Responses API is the supported path forward, and Foundry IQ plus distributed tracing remove three classes of integration work that you would otherwise build yourself. There is no reason to start a new agent project on the Assistants API in 2026.

Scenario 2: Existing Azure OpenAI app, single GPT model, stable, latency-critical. Stay on Azure OpenAI until you need a Foundry-only feature. The upgrade is reversible, but it is not free: you will recreate private endpoints, audit role assignments, and verify your DNS configuration for two new FQDNs. If your current deployment is humming and you do not need agents, non-OpenAI models, or built-in tracing, defer.

Scenario 3: Need Claude, Llama, Grok, or DeepSeek alongside GPT. Foundry, with one caveat. If your goal is a single Azure bill, Entra authentication, and Azure compliance posture, Foundry-Claude or Foundry-DeepSeek is the right answer despite the Marketplace billing complexity. If your goal is the lowest token price, going direct to Anthropic’s API or DeepSeek’s API generally wins. The Microsoft margin on Marketplace models is real.

Scenario 4: Heavy regulated workload (financial services, healthcare) running on Azure OpenAI today. Upgrade to Foundry deliberately, with three pre-upgrade tightening steps. Tighten RBAC: replace broad “Cognitive Services User” assignments with the narrower “Cognitive Services OpenAI User” role to avoid implicit access to non-OpenAI models. Define Azure Policy with models-deployment-policy to allowlist specific model deployments. Plan the private endpoint recreation as a maintenance window, not a hot-path operation.

Scenario 5: Building Copilots in M365 or Teams. Use Foundry. The publishing path to M365, Teams, and BizChat is Foundry-native. Building this on standalone Azure OpenAI means rebuilding the publish/share layer that Foundry projects expose by default.

Scenario 6: Want to host on user devices or work offline. Use Foundry Local. It is OpenAI-compatible (same client code), supports CUDA, WebGPU, Vitis NPU, Qualcomm NPU, OpenVINO, and CPU fallback, and runs Phi-4, Qwen, DeepSeek, Mistral, Whisper, and gpt-oss models locally. The CLI is in preview and the CLI-dependent SDK versions retire 2026-08-31, so plan around the GA timeline.

Scenario 7: Already invested in Assistants API. Migrate to the Foundry Agent Service before 2026-08-26. The migration tool at aka.ms/agent/migrate/tool produces a starting point, but expect six to ten weeks of code rewrite for a non-trivial Assistants implementation. Threads become Conversations, Runs become Responses, Assistants become Agent Versions. Any orchestration logic written against Run states needs to be rewritten against Response states. This is the hardest single migration in the Foundry transition, and the deadline is non-negotiable.

Scenario 8: Pure GPT-5 chat completions, no Azure compliance need. Go direct to OpenAI. There is no Microsoft margin, feature access is faster, and you avoid the entire Azure resource model. If your only reason to be on Azure was procurement and you do not have an Azure compliance posture to maintain, the OpenAI API is cheaper and earlier on every release. The time to use Azure is when you need Azure: Entra identity, Azure private link, Azure data residency commitments, single-bill procurement.

The Migration Mechanics

For teams who decided to upgrade, here are the things that bite during the migration.

The upgrade itself is non-destructive. Same resource name, same endpoint, same API key, same fine-tunes, same batches, same network configurations, same tags. Three execution paths: portal banner (“Upgrade to Foundry” prompt), Azure CLI (az cognitiveservices account update --kind AIServices), Bicep (flip kind: 'OpenAI' to kind: 'AIServices' and add properties.allowProjectManagement: true), or Terraform (AzureRM ≥ 4.57.0 required for non-destructive upgrade). Owner role on subscription or resource group is the prerequisite; system-assigned managed identity must be enabled.

The roll-back path exists but is constrained. You must delete Projects, Connections, and non-OpenAI deployments first. After roll-back, watch for the 30-AOAI-instances-per-region cap, which can block recreating resources during the same maintenance window.

Customer-managed key resources require a request form. If your existing Azure OpenAI deployment uses CMK for compliance, the upgrade is not a portal click. File the request, plan the timeline.

Private link must be recreated. The existing private endpoint pointing at *.openai.azure.com is preserved. The two new FQDNs (services.ai.azure.com and cognitiveservices.azure.com) are not covered. Add IP configurations to the existing endpoint or create new ones with the additional zones. Foundry-only features fail silently from inside the spoke until this is done.

SDK migration paths are independent of the resource upgrade. Even if you do not upgrade the resource, you can move from AzureOpenAI() to vanilla OpenAI() pointed at the /openai/v1/ path. The api-version parameter goes away. For agents, install azure-ai-projects ≥ 2.0.0 (Python), Azure.AI.Projects (C#), or @azure/ai-projects ≥ 2.0.0 (JavaScript). The Entra scope for the Foundry data plane is https://ai.azure.com/.default, not https://cognitiveservices.azure.com/.default. Any token-acquisition code hardcoding the older scope will fail against Foundry-only endpoints.

PTU reservations carry over automatically. If you have an existing 1-year PTU reservation on Azure OpenAI, it auto-applies to the upgraded Foundry resource. Reservation discount also applies cross-model under the same scope, region, and deployment type, so a GPT-5 PTU reservation can discount a DeepSeek-R1 deployment in the same region if both are PTU. This is a real cost savings that most teams underestimate during the upgrade case.

What This Tells You

Three takeaways for the IT director writing the 2026 platform plan.

First: the rebrand is consolidation, not deprecation. Azure OpenAI Service still exists, still gets new GPT models, and still works through the OpenAI compatibility endpoint. The strategic shift is at the resource and project level, not the SKU level. Teams who treated the rebrand as “Azure OpenAI is going away” pre-emptively migrated and hit private link gotchas. Teams who treated it as “Foundry is the new umbrella, Azure OpenAI is one model family inside it” planned more carefully and migrated when the trigger was a feature need, not a calendar date.

Second: the Assistants API deadline is the only hard date. Everything else in the Foundry transition is soft, opt-in, reversible. The 2026-08-26 Assistants retirement is not. If you have an Assistants API workload, the migration to Foundry Agent Service is on the critical path for the next four months. Start it now.

Third: the Foundry-only features are real, but they are not Azure-OpenAI-killers. Foundry Agent Service plus connected agents plus multi-agent workflows plus Foundry IQ plus distributed tracing is a genuinely better developer experience for AI applications than rolling these capabilities yourself on raw Azure OpenAI. But “better developer experience” is a different statement from “you must migrate.” If your application does not need agents, does not need non-OpenAI models, does not need built-in evaluation pipelines, the case for upgrading is weak. The case for adopting Foundry on the next greenfield project is strong.

The decision tree above is what most enterprise architectures look like. Pick the scenario that matches yours, document the choice as an ADR, and move on. The platform consolidation is happening either way; the question is whether you migrate proactively or reactively, and the answer depends on what your application actually needs, not on the marketing.

Related Reading

• Azure AI Landing Zone: The 2026 Reference Architecture - the platform-level architecture that hosts both Azure OpenAI and Foundry workloads
• Azure OpenAI PTU vs PAYG: The Real Break-Even Table - the cost layer that does not change with the rebrand
• Claude on Azure: The Marketplace Billing Trap - the procurement details for Foundry-Claude specifically
• AI Governance Framework for Microsoft Enterprises - the operational governance that wraps both platforms

---

If you are working through the Foundry vs Azure OpenAI decision for an enterprise platform plan and want a sanity check on the eight scenarios, reach out.