On August 26, 2026, both OpenAI and Microsoft retire the Assistants API — and they retire it into two different, incompatible successors. OpenAI points you at its Responses and Conversations APIs. Microsoft points you at Foundry Agent Service. Neither one brings your conversation history with it.
That is 15 days from today. If anything in production still calls /v1/assistants, /v1/threads or /v1/runs — or the Azure equivalents — the decision you make under that deadline is not a refactor. It is a cloud commitment, made in a hurry, about the layer of your stack that holds all of your state.
Both Clocks Hit Zero on the Same Day
Two vendors are switching off the same API surface on the same date and sending customers to two products that share no agent definition.
OpenAI announced the wind-down on August 26, 2025 and set the shutdown exactly one year out. Its deprecations page lists the Assistants API with a shutdown date of August 26, 2026 and names the replacement as the "Responses API and Conversations API." The announcement thread has been open for a year; there is no extension in it.
Microsoft's own documentation carries the same date. The Azure OpenAI Assistants API concepts page now opens with: "The Assistants API is deprecated and will be retired on August 26, 2026. Use the generally available Microsoft Foundry Agents service." Azure's model lifecycle page sets the house posture on retirements — a retired model means "all inference requests return 410 Gone" — and answers the obvious follow-up in one word: "Can I get an exception to extend a model's retirement date? No. Retirement dates aren't extendable."
The two migrations agree on the plumbing and disagree on the object that matters. Both map threads to conversations and runs to responses. But OpenAI maps an Assistant to a Prompt, while Microsoft's migration guide maps it to an Agent version, created with client.agents.create_version() and a PromptAgentDefinition. Your agent definition — the model, the instructions, the tool wiring — is the one thing that does not port between the two successors. That is where the lock-in got made.
Azure Customers Were Told They Were "Not Impacted"
Azure teams who checked in 2025 were told, on Microsoft's own support surface, that this did not apply to them.
An answer posted October 1, 2025 on Microsoft Q&A — by a community poster, not Microsoft staff — reads: "Azure OpenAI Service, provided by Microsoft, is not impacted by this deprecation. Azure OpenAI does not use the Assistants API from OpenAI's platform... users of Azure OpenAI can continue building assistants and agents as usual." Five months later, a February 26, 2026 answer on the same site says the opposite: "Yes. The Azure OpenAI Assistants API itself is now deprecated and is scheduled to be fully retired on August 26, 2026."
Worth being precise about what that second answer is: it is an AI-generated answer on a community Q&A board, not a product announcement. The authoritative source is the Learn banner quoted above. The lesson is not that Microsoft lied — it is that a support-forum answer is not a lifecycle commitment, and a lot of architecture decisions in late 2025 were made on one.
The notification channel did not close the gap either. A customer reported on June 24, 2026 that Service Health retirement notice LZ_6-Y1Z listed their subscriptions as impacted while the Impacted Resources tab was "completely empty — no resources are listed." The accepted answer calls this "expected behaviour and a known gap in Service Health," because the notice "is raised at the subscription level based on telemetry signals... not strictly on currently discoverable resources." If you were waiting for Azure to tell you which resources to fix, it cannot.
One date does buy some room, and this one is in the documentation rather than on a forum. Foundry Agent Service classic is on a separate track: Microsoft Learn's classic agents notice states that "Agents (classic) are now deprecated and will be retired on March 31, 2027." A Microsoft staff answer dated July 22, 2026 adds the part the docs do not spell out: "Microsoft has not published any guidance stating that workloads using the azure-ai-agents SDK (AgentsClient) with Foundry Agent Service (classic) will stop functioning on August 26, 2026." If you are on azure-ai-agents rather than raw Assistants calls, you have seven months, not fifteen days. Confirm which one you are actually running before you believe that.
Your Threads Do Not Come With You
Neither vendor moves your conversation history, and both of them say so in writing.
OpenAI's Assistants migration guide is blunt: "We will not provide an automated tool for migrating Threads to Conversations. Instead, we recommend migrating new user threads onto conversations and migrating older ones as necessary." Microsoft ships a migration tool, and scopes it explicitly to code: it "migrates code constructs such as agent definitions, thread creation, message creation, and run creation. It doesn't migrate state data like past runs, threads, or messages."
Then read Microsoft's own troubleshooting row, which is the sharpest sentence in the whole migration: "Old thread data isn't available... Start new conversations after migration. Historical data remains accessible through the previous API until it's deprecated." Your conversation archive is readable only through the endpoint being switched off. If that history is a support record, a regulated audit trail, or the retrieval corpus your assistant grounds on, exporting it is a deadline task, not a follow-up ticket.
Tooling breaks too, and not only for previews. Microsoft's migration guide publishes a tool-availability table comparing Foundry classic to the new service. Azure Functions goes from GA to "No." Connected Agents goes from public preview to "No," with a recommendation to use the Agent-to-Agent tool instead. Deep Research goes to "No," with a recommendation to use a Deep Research model plus the Web Search tool. Code Interpreter, File Search, Azure AI Search, OpenAPI and Grounding with Bing all carry over at GA — but if your agent calls an Azure Function, you are rewriting an integration, not changing an import.
The infrastructure step is heavier than the code step. Reaching Agent Service means upgrading the Azure OpenAI resource to a Foundry resource: kind changes from OpenAI to AIServices, managed identity must be enabled, and you need Owner on the subscription or resource group. Buried in the limitations is the one that will decide your change window: "Resources with existing private endpoints can't be upgraded from Azure OpenAI to Foundry through the Foundry portal or the Azure portal. Delete the private endpoints before you upgrade, and recreate them afterward." Microsoft offers one way around the delete step — "Alternatively, manage the upgrade using Azure Bicep or Terraform" — but that path does not spare you the endpoint work either: Foundry exposes two additional FQDNs, and the same page states you "must recreate your private link endpoint" for them. In a bank or a hospital, touching a private endpoint is a change-advisory-board item with a lead time measured in weeks. You have two.
OpenAI's Guide Warns You Off Its Own Destination
The migration path OpenAI recommended a year ago now carries a warning against using it for anything long-lived.
The migration guide maps Assistants to Prompts, on the reasoning that "Prompts hold configuration (model, tools, instructions) and are easier to version and update." Immediately alongside it sits this: "Reusable prompt objects are also being deprecated. If you use this migration path, review the prompts deprecation timeline before adopting prompt objects in a long-lived integration."
That timeline is on the same deprecations page. The Reusable Prompts API was deprecated on June 3, 2026 and shuts down on November 30, 2026 — 96 days after the Assistants cutoff. A team that did exactly what OpenAI told it to do in August 2025 gets a second migration before the year ends. Developers in the announcement thread had already flagged a related problem: prompt objects can only be created in the dashboard, with one asking plainly, "Is there a API way to create Prompts?"
The replacement guidance is the most useful thing OpenAI has published all year, because it is an argument against its own application layer. The migrate-from-prompt-objects guide says to "move the prompt content out of the managed prompt object and into your application code," to "store the prompt text in your codebase and pass the generated messages directly as input in the Responses API call," and gives the reason: it puts "review, testing, deployment, and versioning" back under your control.
That is the whole thesis of this deprecation cycle, written by the vendor. The model endpoint is durable. The application layer bolted on top of it — assistants, threads, prompt objects, hosted eval dashboards, visual builders — is the least durable software you will ever depend on, because it is the layer each vendor rewrites to differentiate.
The Second Wave Lands November 30
August 26 is not the end of the queue. Three more OpenAI products close on November 30, 2026, and one of them takes your measurement history with it.
Per the deprecations page, all three were announced on June 3, 2026: the Evals platform, Agent Builder, and the Reusable Prompts API. Evals has an earlier trap — it goes read-only on October 31, 81 days from today, before the November 30 shutdown. Agent Builder customers are pointed at the Agents SDK or ChatGPT Workspace Agents.
For Evals, OpenAI's named destination is a third-party open-source project. Its own cookbook, "Moving from OpenAI Evals to Promptfoo", walks through exporting a runnable Promptfoo config and re-running it from the CLI. The export has two shapes and only one of them is worth anything: for supported evals, "the exported Promptfoo configuration carries these pieces into a runnable evaluation" — test data, prompts, providers/models, and the criteria for scoring outputs. A historical result export is separate, and only makes "previous OpenAI Evals runs available in Promptfoo" for comparison; it does not recreate the eval. Not every eval type supports the runnable export, and where it does not, the cookbook's instruction is blunt: "A runnable configuration cannot be exported. Recreate the evaluation in Promptfoo."
An eval is a fixed test set plus a grader that scores model output against it. Its value is entirely in the time series: today's score means nothing without last quarter's. If your regression baseline lives in a dashboard that goes read-only on October 31, you are not migrating a tool. You are deciding whether you keep your evidence. Teams that kept evals in code and a repo — with Langfuse, Braintrust, Promptfoo or a plain CI job — have nothing to do here. Teams that used the hosted dashboard have a deadline, and we have made the same argument about eval portability before.
What To Do Before August 26
The work splits cleanly into two weeks of triage and one quarter of structural repair. Do not conflate them.
This Week:
- Grep for the call sites, do not trust the console. Search your repositories for
/v1/assistants,/v1/threads,/v1/runs,client.beta.assistants, and on Azure/openai/assistants. The Microsoft Q&A thread above points at code search and Log Analytics as the checks that actually work, so run both:GET https://<resource-name>.openai.azure.com/openai/assistants?api-version=<version>against every Azure OpenAI resource, plus a Log Analytics query filtering request URIs for those paths. Service Health's Impacted Resources tab is documented to come back empty. - Establish which Azure surface you are on. Raw Assistants API is August 26. Foundry Agent Service classic via
azure-ai-agentsis March 31, 2027. These are different projects with different urgency, and the retirement email does not distinguish them for you. - Export the threads you are legally or operationally required to keep. There is no bulk export tool on either platform, and after the cutoff the only reader for that data is gone. This is the item that cannot be recovered later.
This Month:
- Move prompts and agent definitions into your repository. Not into Prompts, not into an Agent version — into source control, per OpenAI's own guidance. Both successors accept instructions passed inline. This is the change that makes the next deprecation a config edit.
- Pick the runtime deliberately, not by whichever migration guide you read first. Responses plus Conversations and Foundry Agent Service are not interchangeable, and choosing under deadline pressure is how a 15-day outage risk becomes a three-year cloud commitment. If you are re-opening this question anyway, do it against the full build-to-buy spectrum and read the framework comparison where one option was already retired.
- Book the private-endpoint change window now if you are on Azure with private networking. The portal path makes you delete and recreate them; the Bicep/Terraform path still needs new ones for the Foundry FQDNs. Either way your change board's calendar is the binding constraint, not your engineers'.
Before October 31:
- Export every eval as a runnable Promptfoo config, not just its results. Verify each one actually re-runs before the platform goes read-only. Confirm which of your eval types support the runnable export at all — some do not, and those have to be rebuilt by hand.
- Put the eval suite in CI. A hosted eval dashboard is a vendor's application layer wearing a lab coat. The observability and monitoring stack you buy should read from data you own.
The Bottom Line
We have watched the layer above the model move out from under enterprises twice already this year. Google folded Vertex AI into its Gemini Enterprise Agent Platform — the aiplatform.googleapis.com endpoint came through that change unaltered, while the deprecated SDK modules stacked on top of it did not. OpenAI shut down Sora and pivoted to enterprise. Now both of the largest enterprise AI platforms are retiring the same agent runtime on the same day, into successors that do not agree with each other — and the successor OpenAI recommends carries a warning, in OpenAI's own documentation, not to use it in a long-lived integration.
The pattern is stable enough to plan around. Model endpoints are durable and increasingly interchangeable; a chat completions call written in 2023 still runs. The application layer built above them — hosted threads, managed assistants, prompt objects, eval dashboards, drag-and-drop builders — is where vendors compete, which means it is where they rewrite. Every convenience that layer offers is paid for in migration risk, and the bill arrives with 15 days' notice.
Nothing in this migration is technically hard. What makes it expensive is that four things you never chose to outsource — conversation state, prompt versioning, tool wiring, and your evaluation history — were living inside somebody else's product. Take them back. Threading, state, prompts and evals belong in code you own, running against whichever endpoint is cheapest and best this quarter, on an architecture you can exit.
Rent the model. Own the thread.
Continue Reading
- LangGraph vs CrewAI vs AutoGen: One of Them Is Retired
- Google Kills Vertex AI: What 200,000+ Enterprises Must Do Next
- OpenAI Kills Sora After $200M Loss: Enterprise-Only Pivot
- DeepSeek Swapped the Model. Your Eval Didn't Notice.
- Snowflake Cortex vs Databricks Mosaic AI: Pick on Exit Cost
- The Build-to-Buy Spectrum: 5 Tiers for Enterprise AI Agents
- Best AI Agent Monitoring: Langfuse, Then a Real Kill Switch
- MCP Goes Stateless: Enterprise AI Governance Just Got Real