Microsoft Foundry vs Azure AI Foundry: What Changed and What to Migrate

📋 Quick reference

Audience: Enterprise architects, platform leads and Microsoft partners with Azure AI workloads already in production
Read time: ~12 minutes
What you'll get: What the Microsoft Foundry rebrand changed underneath the name, what happens to your hubs and standalone Azure OpenAI resources, which migration actually costs engineering time, and a 30-day plan that starts with governance rather than a portal

Azure AI Foundry is now Microsoft Foundry. If that were only a name change you could ignore it, put a note in the wiki and move on. It is not. Underneath the rebrand sits a different resource model, a different agent API, a different SDK surface and a different governance boundary — and the old world still runs, in a portal now labelled classic.

Which means the decision in front of most architects is not "do we adopt the new name". It is "do we migrate, and in what order, given that nothing is broken today".

Let me answer the version of the question I get asked in meetings. If your workload only calls models for completions, you can stay where you are for now. If you are hosting agents, running evaluations, or trying to explain to a security team how twelve AI resources across four subscriptions are governed, the new resource model is the reason to move, and the rebrand is incidental.

Is Microsoft Foundry the same product as Azure AI Foundry?

Same lineage, materially different shape. Microsoft Foundry unifies agents, models and tools under a single management grouping, with tracing, monitoring, evaluations and enterprise setup configuration built in, managed through unified role-based access control, networking and policy under one Azure resource provider namespace.

Microsoft publishes the mapping from old concepts to new ones plainly, which I appreciate more than I expected to. The brand went from Azure AI Studio to Azure AI Foundry to Microsoft Foundry. Azure AI Services are now Foundry Tools. The Assistants API became the Responses API. Monthly api-version parameters became stable v1 routes. And the resource model went from a hub plus Azure OpenAI plus Azure AI Services to a single Foundry resource with projects inside it.

The terminology change is the one that will bite your codebase quietly: threads, messages, runs and assistants are now conversations, items, responses and agent versions. Nothing about that is hard. It is just spread across every file where someone wrote an integration in a hurry.

What actually changed in the resource model?

The hierarchy did, and it is the part worth understanding properly because it is the part your security team will ask about. The Foundry architecture documentation lays out three levels plus a category most diagrams get wrong.

At the top, the Foundry resource: the Azure resource where you manage governance settings — networking, security, model deployments. Inside it, projects: the development boundary where teams build and evaluate use cases, reusing existing model deployments and connections without asking IT to set anything up again. Inside those, project assets: files, agents, evaluations, traces.

And then the category that causes the confusion: connected resources. Storage, Key Vault and Azure AI Search are referenced through connections, but they are independent Azure resources with their own governance boundaries. You manage their networking, access policies and compliance settings separately. Microsoft flags this explicitly, and I would put it on the diagram in a different colour, because "it's in Foundry" is not a statement about where your documents live.

Concretely, the Foundry resource is Microsoft.CognitiveServices/accounts with kind AIServices, and a project is a subresource of it. That matters because Foundry shares the Microsoft.CognitiveServices provider namespace with Azure OpenAI, Speech, Vision and Language — so management APIs, Azure RBAC actions, networking configuration and Azure Policy aliases line up across all of them. If you are upgrading from Azure OpenAI, your existing custom Azure policies and RBAC actions keep applying.

That is a genuinely well-designed migration path, and it is the single strongest argument for making the move deliberately rather than reluctantly.

Do I have to migrate my hub-based projects?

Not today. Hub-based projects remain accessible in the Foundry (classic) portal, and some use cases — open-source model deployments among them — still require a hub resource. But new investment is going into Foundry projects in the new portal, and Microsoft says so in the first paragraph of the overview page rather than burying it.

Read that as a soft deadline with no date attached. Those are the hardest kind to plan against, because nothing forces the decision until a capability you want is only available on the new model.

The practical guidance: don't migrate hubs as a project in its own right. Migrate them when a workload needs something new anyway, using the migration path from hub-based to Foundry projects, and use the classic-to-new navigation guide to stop your team from re-learning the portal by clicking around. A migration with no user-facing outcome is the first thing cut when a quarter gets busy, and it should be.

What happens to my standalone Azure OpenAI resource?

You can upgrade an Azure OpenAI resource to a Foundry resource while preserving your endpoint, API keys and existing state. That is not a migration in the painful sense — no new endpoint to roll out, no key rotation, no coordinated client release.

Should you? Microsoft's own answer is refreshingly non-maximalist: if your workload only requires Azure OpenAI completions without agent hosting or evaluation, a standalone Azure OpenAI resource might be sufficient. If your IT security team has not enabled the superset of Foundry capabilities in your environment, you might actually need the standalone resource.

So the decision is per workload, not per estate. Agent hosting, evaluation tooling, multi-team project isolation, or a compliance design that needs RBAC scoped at two levels — those are reasons. "Everything should be on the newest thing" is not.

Which migration actually costs engineering time?

The API one. Everything else is configuration; this is code.

The Assistants API (agents v0.5 and v1) gives way to the Responses API (agents v2). Alongside it, the SDK surface collapses: where you had multiple packages — azure-ai-inference, azure-ai-generative, azure-ai-ml, a separate AzureOpenAI() client — against five or more endpoints, you now have a unified project client (azure-ai-projects 2.x) plus OpenAI() against a single project endpoint. API versioning moves from monthly api-version parameters to stable v1 routes under /openai/v1/.

The end state is better in every direction. Getting there means touching client code, retiring pinned api-version strings that someone hardcoded during an incident, and rewriting whatever you built on threads and runs. Budget it as engineering work with a test plan, not as a platform task somebody does between meetings.

One thing I would do first, before any of it: check the retirement date of every model you have deployed. On a recent engagement I ran the version check almost as a formality and found the production model was scheduled for retirement shortly after the planned go-live — nobody on the delivery side had looked, because a model that works today does not feel like a dependency with an expiry. Provisioned deployments are not silently upgraded for you, which means the failure mode is inference errors on a date in a calendar nobody read. Fifteen minutes on the Foundry Models catalog is the cheapest risk reduction available in this whole exercise.

What does the governance story look like for IT?

Better than it was, and this is the honest reason to care about the new resource model.

The Foundry control plane gives you Microsoft Entra identity, role-based access control, content filters, network isolation and Azure Policy applied at the resource level, with projects as a development boundary underneath. Observability brings tracing, monitoring and evaluation of agents and models into built-in dashboards rather than something each team wires up itself. Private Link configuration is documented as a first-class deployment option, and the rollout guidance exists specifically for organisations doing this at scale.

Compare that with what it replaces. A hub here, three Azure OpenAI resources there, an AI Search instance somebody connected for a proof of concept, and RBAC granted at whatever scope was convenient on the day.

I am describing something real. On an architecture review for a manufacturing group earlier this year, I audited the staging subscription against the architecture diagram the delivery team had been working from. Six resources existed that were not on the diagram — including three separate Azure OpenAI resources, a database nobody mentioned, a compute service that was not the one the diagram claimed, and no API gateway in front of any of it. The access review was worse than the resource review: an implementation partner held Owner at subscription scope, and two customer administrators held elevated access at tenant root.

Nobody had done anything wrong on purpose. Each resource had been created for a reason, by someone competent, in a hurry. That is exactly how AI estates grow — and it is why a single governance boundary with projects underneath is worth the migration cost. Not because the portal is nicer. Because "what do we actually have, and who can reach it" becomes a question with one answer instead of six.

If you are building agents on top of this, the platform choice still matters as much as the resource model — Copilot Studio versus Azure AI Foundry covers that decision, and Microsoft Agent Framework covers what you write once you have chosen. For orchestration beyond a single agent, the multi-agent orchestration patterns still hold under the new naming.

What would I do in the next 30 days?

Week one: inventory. Every hub, every standalone Azure OpenAI resource, every model deployment with its retirement date, every connected Storage, Key Vault and AI Search instance. Then compare that list against your architecture diagram, and treat the difference as the real finding. In my experience the delta is never zero.

Week two: decide per workload. Three buckets. Completions-only workloads that stay put. Workloads that need agents or evaluations, which move. Workloads where security policy limits what capability set is available, which need a conversation before a plan.

Week three: governance first. Design the Foundry resource as a governance boundary before you create a single project — RBAC scope, Azure Policy, private networking, content filtering. Your existing custom policies and RBAC actions carry over from Azure OpenAI, which makes this less work than it sounds. Then draw the connected resources in a different colour and assign each one an owner.

Week four: migrate one thing. One workload, end to end, including the API and SDK change, with a test plan. What you learn in that week is what the rest of the estate costs. Estimating it any other way is guessing with more steps.

My honest opinion

The rebrand is the least interesting part of this and it is what everybody is talking about. Names cost nothing to change and generate an enormous amount of noise — half of the "what's new" content on this consists of a table of old and new names, which is exactly the part your architecture does not care about.

The consolidation into one Azure resource with projects inside it is the actual news, and it fixes a problem that was genuinely painful: AI resources multiplying faster than anyone could govern them, with access granted at whatever scope got the demo working. If you have more than three AI resources and cannot name the owner of each, the migration pays for itself in the inventory step alone — before you deploy anything.

What I would resist is the migration-for-its-own-sake reflex. Preserved endpoints and preserved policies mean you can move on your schedule, workload by workload, and the answer for a stable completions workload with no agent ambitions is genuinely "not yet". Anyone telling you the whole estate must move this quarter is selling a project, not solving a problem.

Frequently asked questions

Is Azure AI Foundry being retired?

The name is superseded by Microsoft Foundry, and hub-based projects continue to work in the Foundry (classic) portal. New investment is focused on Foundry projects in the new portal, and some use cases such as open-source model deployments still require a hub resource. No end-of-support date is attached to the classic experience in the documentation.

Will upgrading my Azure OpenAI resource break my application?

The documented upgrade path preserves your endpoint, API keys and existing state, so clients keep working. Your custom Azure policies and RBAC actions continue to apply because Foundry shares the same resource provider namespace. Test it in a non-production subscription first regardless — that advice has never cost anyone anything.

What is the difference between a Foundry resource and a Foundry project?

The resource is the top-level Azure governance boundary where networking, security and model deployments are managed. A project is a development boundary inside it where a team builds and evaluates use cases, reusing the resource's model deployments and connections. Most new APIs are available at project scope, though a few capabilities remain only at resource level.

Do connected resources like Storage and Key Vault inherit Foundry's security settings?

No. They are independent Azure resources with their own governance boundaries, and you manage their networking, access policies and compliance settings separately. This is the most common misreading of the architecture, and the one most likely to surface in a security review.

Do I need to rewrite my agent code?

If you built on the Assistants API, yes — it gives way to the Responses API, and threads, messages, runs and assistants become conversations, items, responses and agent versions. The SDK also consolidates to a unified project client against one endpoint. Treat it as scoped engineering work with tests, not a configuration change.