Azure's Assistants API Retires Aug 26
Eight days. The Assistants API held threads and state for you; the replacement asks you to be explicit about both. That is the migration, and it is the part that takes an afternoon rather than an hour.
Founder, Automation Squad ·
The short answer
Azure OpenAI's Assistants API is deprecated and will be retired on August 26, 2026. Microsoft directs users to the Microsoft Foundry Agents service, which is generally available, and publishes a migration guide. The retirement applies to the Assistants API feature inside Azure OpenAI on Foundry (classic); models and chat completions are unaffected.
What you are actually moving, and what has no equivalent
Most of the work is not the endpoint change. It is that Assistants kept threads, runs and tool state on Microsoft's side, and the thing you are moving to has a different idea about who owns that.
Find every caller before you design anything
Search your code for the assistants and threads route segments rather than for a client class name — wrappers hide the SDK. Include notebooks, scheduled jobs and whatever someone stood up for a demo and never turned off. The forgotten caller is the one that pages you on the 27th.
Write down which threads you cannot lose
This is the decision the migration actually turns on. If a conversation's history lives only inside an Assistants thread, it lives on infrastructure that stops answering next week. Export what matters now, while the API still responds.
Read the migration guide before porting the first one
Microsoft publishes a mapping. Porting one assistant by hand and generalising from it is how you discover a structural difference on the fourth one and redo the first three.
Port the least important workload first
You want the surprise to land on something nobody is waiting on. Run the old and new side by side and compare outputs on real inputs, not on the example from the docs.
Set a reminder for the 25th, not the 26th
Retirement dates are when things stop, not when you start. A day of margin costs nothing and has saved this exact kind of migration more than once.
| What you built on | Where it goes |
|---|---|
| An assistant with instructions + tools | An agent definition in Foundry Agents |
| Threads you never persisted yourself | You decide: agent-managed state, or your own store |
| Runs polled until completed | The Agents run lifecycle — re-check your polling assumptions |
| File search over uploaded files | Foundry's retrieval — re-index, do not assume a copy |
| Code interpreter | Check availability for your region and tier before you plan around it |
| Function calling | Carries over conceptually; re-verify the schema shape |
| Anything on Azure OpenAI models or chat completions | Not affected. Leave it alone. |
Microsoft is retiring the Azure OpenAI Assistants API on August 26, 2026. The documentation is blunt about it — the feature is deprecated, the date is fixed, and existing workloads are directed to the Microsoft Foundry Agents service, which is already generally available.
The facts: the retirement covers the Assistants API feature inside Azure OpenAI on Foundry (classic). Models and chat completions are untouched, so the blast radius is narrower than the phrase "Azure OpenAI deprecation" suggests. Microsoft publishes a migration guide and names Foundry Agents as the destination. GitHub-hosted and gitlab.com-style managed conveniences do not apply here: if you run against the Assistants endpoints, the work is yours and the deadline is eight days out.
Automation Squad's take: the endpoint swap is not the migration. Assistants was attractive precisely because it held things for you — a thread you did not have to store, a run lifecycle you did not have to model, retrieval over files you uploaded once. Moving to an agent framework means being explicit about all three, and being explicit is more work than being lazy was. The teams who will find this easy are the ones who already treated the thread ID as a foreign key into their own database. The teams who will find it painful are the ones for whom the thread *was* the database. That is worth ten minutes of honest checking today rather than a discovery on the 26th.
Run this now: grep your codebase for the assistants and threads route segments rather than for an SDK class name, because wrappers hide the client. Then answer one question in writing — is there any conversation history that exists only inside an Assistants thread? If yes, export it this week while the API still answers. Port the least important workload first, run it beside the old one on real inputs, and set your calendar reminder for the 25th.
Questions people are asking
- What is the exact retirement date?
- August 26, 2026. Microsoft's documentation states the Assistants API is deprecated and will be retired on that date.
- What replaces it?
- The Microsoft Foundry Agents service, which is generally available. Microsoft publishes a migration guide for moving workloads across.
- Does this affect the rest of Azure OpenAI?
- No. The notice covers the Assistants API feature within Azure OpenAI on Foundry (classic). Models, chat completions and the other capabilities are not part of this retirement.
- What is the piece people underestimate?
- State. Assistants held threads and run state server-side. If your application never persisted conversation history itself, that history is on infrastructure with an expiry date, and exporting it is a task in its own right.
Further reading
- Microsoft Learn — Azure OpenAI Assistants API deprecation — States the retirement date and names Foundry Agents as the replacement.
Last checked August 18, 2026 against the primary sources above, by Automation Squad Research. Spot an error? [email protected].