Moving Microsoft Foundry classic agents before they retire in March 2027.
Azure AI Foundry is called Microsoft Foundry now. Foundry Workflows retire on 1 December 2026 and classic agents on 31 March 2027. Hub-based projects won't open in the new portal. We plan those migrations and build new agents on Foundry projects.
Cohash builds and migrates AI workloads on Microsoft Foundry, which used to be Azure AI Foundry.
We move hub-based projects and Azure OpenAI resources onto Foundry resources. Classic agents we rebuild on Foundry Agent Service before they retire on 31 March 2027, and Foundry Workflows we replace with Microsoft Agent Framework. Model upgrades get planned against Foundry's lifecycle policy. Every build ships with evaluations and Entra ID access controls.
you probably need this if
Agents (classic) are running in production, and nobody has put the 31 March 2027 retirement on the roadmap.
A Foundry Workflow runs a business process and retires on 1 December 2026.
Hub-based projects stopped appearing when the team opened the new portal.
Foundry estate inventory with owner and retirement date per resource
Hub-to-project and Azure OpenAI resource migration runbook
Classic agent rebuild plan with side-by-side evaluation results
+ 3 more documents
who does it
Forward deployed AI engineer (Microsoft Foundry)Microsoft Agent Framework developer (Python, .NET)Azure AI platform engineer (Entra ID, private networking)
Microsoft Certified: Azure AI Apps and Agents Developer Associate
Microsoft Certified: Azure AI Fundamentals
03 Apr 2026Microsoft Agent Framework 1.0 The production release has stable APIs and combines Semantic Kernel with AutoGen's orchestration patterns. source ↗
today · Oct 22, 2026
01 Dec 2026aheadFoundry Workflows retirement Foundry Workflows retire on 1 December 2026. Microsoft's guidance is to use Microsoft Agent Framework instead. source ↗
31 Mar 2027aheadAgents (classic) retirement Classic agents are deprecated and retire on 31 March 2027. source ↗
no date yetAzure AI Foundry renamed Microsoft FoundryMicrosoft's brand table maps the old names. Azure AI Studio and Azure AI Foundry go to Microsoft Foundry. Azure AI Services goes to Foundry Tools. The Assistants API goes to the Responses API (Agents v2).source ↗
the story · microsoft foundry estate
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Microsoft Foundry estate, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · microsoft foundry estate3 open
openAgents (classic) are running in production, and nobody has put the 31 March 2027 retirement on the roadmap.
recurringA Foundry Workflow runs a business process and retires on 1 December 2026.
blockedHub-based projects stopped appearing when the team opened the new portal.
exposure
Hub-based project migrationClassic agent migrationMicrosoft Agent Framework buildsIdentity and network controlsEvaluations and monitoringModel lifecycle planning
startrehearsehandover
Foundry estate inventory
Migration and build plan
Build with evaluations
Cut-over and handover
we are here
ready to hand over
Nothing is still running when it retires, and every switch has evaluation results on file.
Each deployment has an owner now and we plan retirements ahead.
Foundry estate inventory with owner and retirement date per resource
Hub-to-project and Azure OpenAI resource migration runbook
chapter 01 · where it hurts
Why teams reach out
Agents (classic) are running in production, and nobody has put the 31 March 2027 retirement on the roadmap.
A Foundry Workflow runs a business process and retires on 1 December 2026.
Hub-based projects stopped appearing when the team opened the new portal.
chapter 02 · what we change
How we solve it
Hub-based project migration
Classic agent migration
Microsoft Agent Framework builds
Identity and network controls
Evaluations and monitoring
Model lifecycle planning
chapter 03 · how it runs
Our approach
Foundry estate inventory
Migration and build plan
Build with evaluations
Cut-over and handover
chapter 04 · where you end up
What changes
Nothing is still running when it retires, and every switch has evaluation results on file.
Each deployment has an owner now and we plan retirements ahead.
Foundry estate inventory with owner and retirement date per resource
Hub-to-project and Azure OpenAI resource migration runbook
what we do
Our Microsoft Foundry work
6 kinds of Microsoft Foundry work, each run by engineers who have done it on live tenants.
Hub-based projects and standalone Azure OpenAI resources moved to Foundry resources and projects, keeping endpoints and keys where Microsoft's upgrade path allows.
Agents (classic) rebuilt on the current Foundry Agent Service and Responses API, with tools, files and threads mapped and behaviour compared on a test set.
Multi-step and multi-agent workflows written with Microsoft Agent Framework 1.0, replacing Foundry Workflows and older Semantic Kernel or AutoGen code.
Entra ID roles, managed identities, private endpoints and agent identities designed so each agent reaches only the data and tools it needs.
Evaluation sets from real cases run in CI, with tracing and alerts so quality and cost are visible after launch.
A register of deployed models with their deprecation and retirement dates, and a tested replacement for each before Microsoft's notice period runs out.
capability 01 / 06in production
Hub-based project migration
Hub-based projects and standalone Azure OpenAI resources moved to Foundry resources and projects, keeping endpoints and keys where Microsoft's upgrade path allows.
Agents (classic) rebuilt on the current Foundry Agent Service and Responses API, with tools, files and threads mapped and behaviour compared on a test set.
Multi-step and multi-agent workflows written with Microsoft Agent Framework 1.0, replacing Foundry Workflows and older Semantic Kernel or AutoGen code.
A register of deployed models with their deprecation and retirement dates, and a tested replacement for each before Microsoft's notice period runs out.
We pieced these together from Microsoft Foundry situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Five classic agents and two Foundry Workflows in a hub-based project
composite · not a client story
Beforethe situation
A hub-based project runs an internal support assistant plus four other classic agents, and two Foundry Workflows handle approval routing. The workflows retire on 1 December 2026. The agents follow on 31 March 2027.
What we dothe work
We start with the two workflows, since their date is earlier, and rewrite them in Agent Framework. Next we create a Foundry project and rebuild each agent on the current Agent Service, running old and new against the same evaluation set.
Afterwhere you end up
Nothing is still running when it retires, and every switch has evaluation results on file.
case file 02
An Azure OpenAI resource with fourteen deployments and no owners
composite · not a client story
Beforethe situation
A standalone Azure OpenAI resource has fourteen model deployments, called by apps all over the business. Deprecation notices keep arriving, and nobody can say which app sits behind which deployment.
What we dothe work
We go through the logs to match deployments to callers, and give each deployment an owner. Then we upgrade the resource to a Foundry resource and leave its endpoint as it is. Last comes a lifecycle register, with a test set for each app.
Afterwhere you end up
Each deployment has an owner now and we plan retirements ahead. The apps call the same endpoint they did before the upgrade.
We don't start a step until the last one has produced something you can check.
step 01
Foundry estate inventory
Hubs, projects, Azure OpenAI resources, deployed models, classic agents, workflows: all of it goes on a list. Next to each we put an owner and the retirement date that applies.
step 02
Migration and build plan
We upgrade resources to Foundry resources, rebuild agents on the current Agent Service and rewrite workflows in Agent Framework. Whatever has the earliest date goes first.
step 03
Build with evaluations
No agent reaches users until it has an evaluation set from real cases. Migrated or new, it also gets Entra ID roles and managed identities, and tracing.
step 04
Cut-over and handover
We run old and new side by side and move traffic once the scores match. Then your team gets a model lifecycle register and the runbooks.
ai on microsoft foundry
Where AI fits on Microsoft Foundry, and where it needs guardrails.
Microsoft Foundry hosts models and agents on Azure (it used to be Azure AI Foundry). Foundry Agent Service runs agents on the Responses API. Microsoft Agent Framework 1.0 handles multi-step workflows. Classic agents retire on 31 March 2027 and Foundry Workflows on 1 December 2026. Teams need a migration order and an identity design.
AI agentasks for data or an action
Scoped identityonly the access it needs
MCP serverthe one door into the platform
Logged, approveda person signs off on writes
Microsoft Foundrydoes the work
There's an MCP tool in Foundry Agent Service that reaches public or private MCP endpoints, and it authenticates with OAuth, a user Entra token or the project managed identity. For high-risk tools Microsoft recommends require_approval. We set allowed_tools per agent and log every approval and every tool call.
Foundry Agent Service
The current Agent Service is built on the Responses API, with tools like file search and MCP. We rebuild classic agents on it, then run old and new against the same evaluation set before switching traffic.
Microsoft Agent Framework
Version 1.0 was released on 3 April 2026. It joins Semantic Kernel and AutoGen patterns, and Microsoft made it the replacement for Foundry Workflows. Foundry Workflows retire on 1 December 2026, and we rewrite each workflow before then.
Retirement dates
Classic agents retire on 31 March 2027, but Foundry Workflows go sooner, on 1 December 2026. We inventory projects, agents and workflows with owners, and move the earliest dates first.
Identity and approvals
An agent can authenticate to a tool with OAuth, a user Entra token or the project managed identity, and we pick per tool. We use private MCP endpoints where the data's sensitive and require approval for any write.
How a Microsoft Foundry agent connects to your Microsoft estate
Users reach the agent through Teams or a business app after signing in with Entra ID. The agent runs in a Foundry project, calls models deployed in Foundry, and reads company data from Fabric and Dynamics 365 using managed identities with scoped roles.
01 · Users
Entra IDsign-in · roles → Teams or business app · OIDC sign-in
Teams or business appchat · Power Apps → Foundry project · agent request
02 · Microsoft Foundry
Foundry projectAgent Service · Responses API → Foundry Models · model call→ Microsoft Fabric · managed identity→ Dynamics 365 · scoped API call→ SharePoint · file search
These are working documents, written against your configuration, so your team can run them without us.
inventory01
Foundry estate inventory with owner and retirement date per resource
yours to keep
runbook02
Hub-to-project and Azure OpenAI resource migration runbook
yours to keep
plan03
Classic agent rebuild plan with side-by-side evaluation results
yours to keep
code04
Agent Framework code replacing each Foundry Workflow
yours to keep
design05
Entra ID role and managed identity design per agent
yours to keep
tests06
Model lifecycle register with tested replacements
yours to keep
talent and delivery · microsoft foundry
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Microsoft Agent Framework developer (Python, .NET)
Azure AI platform engineer (Entra ID, private networking)
LLM evaluation engineer
Copilot and Teams integration developer
due diligence · microsoft foundry
Questions to ask any partner, including us.
Put these to anyone bidding on your Microsoft Foundry work. The ones who've done it answer differently from the ones who've read about it.
Q1
Which of our resources fall under the 1 December 2026 and 31 March 2027 dates?
Workflows and classic agents retire on different dates. Without the inventory you can't even sequence the work.
Q2
Can our Azure OpenAI endpoints stay the same when we move to Foundry resources?
There's a documented Microsoft upgrade path that keeps endpoints and keys. Work out which apps can keep theirs, and that's one round of client changes you don't have to make.
Q3
How will you prove a rebuilt agent behaves like the classic one?
Run one shared evaluation set against both versions and compare. If you skip that, users will find the differences for you.
Q4
How will each agent authenticate to Fabric, Dynamics 365 or SharePoint?
With managed identities and scoped roles, an agent can't inherit broad access. Shared keys and over-privileged service principals get flagged by auditors a lot.
Q5
Who will own model retirement notices after you leave?
Foundry gives at least 60 days' notice for GA models. Inside that window someone still has to read the notice, run the tests and switch the deployment.
01Is Azure AI Foundry the same as Microsoft Foundry?
Yes. Microsoft's own brand table maps Azure AI Studio and Azure AI Foundry to Microsoft Foundry, and Azure AI Services to Foundry Tools. You'll still see the earlier names in older documentation, SDK names and portal links.
02Do we have to migrate our hub-based projects?
Hub-based projects open only in the Foundry (classic) portal, and Microsoft says new investment goes into Foundry projects in the new portal. We haven't found a retirement date for hub-based projects. Agents (classic) do retire, on 31 March 2027, so most teams migrate the two together.
03What replaces Foundry Workflows?
Microsoft's guidance is Microsoft Agent Framework. Foundry Workflows retire on 1 December 2026. We rewrite each workflow in Agent Framework, keep the same evaluation set, and run both side by side before we switch.
04How much notice do we get before a model is retired?
Foundry's lifecycle policy promises at least 60 days' notice for GA models and 30 days for preview models. A GA model normally has an 18-month lifecycle, and some partner models get less. We keep a register so notices don't catch anyone out.
05Can you embed engineers with our business team?
Yes. Our forward deployed engineers work inside your team and build on your real data and systems. When they hand over, the evaluations, access controls and runbooks come with it. We staff onsite in the US, or nearshore and offshore, in any time zone.
services
Related services
Projects on Microsoft Foundry usually end up touching one of these, so they're worth a look.