Update, 12 Sep 2026. This post was written before the deadline. The deadline has passed. OpenAI's migration guide now states: "The Assistants API was officially sunset on August 26, 2026, and is no longer available. Use the Responses API for new integrations." Everything below has been rewritten to reflect that. If you are reading this because something stopped working, skip to the section on what to do if your code still points at it.
On 26 Aug 2026, an OpenAI API that a lot of UK businesses were quietly running on stopped existing.
You may not know whether you are one of them, and that is the normal position rather than an embarrassing one. Somebody commissioned an AI thing in 2024 or early 2025. It reads the inbox, or drafts the quotes, or answers questions about your product documentation. It has worked ever since, which is precisely why nobody has looked at it. The contractor who built it may have moved on. The internal champion may have left.
So the question is not technical. It is: are we exposed, who fixes it, and by when.
OpenAI announced the retirement on 26 Aug 2025 and gave twelve months. That is fair notice by any standard. It only helped you if somebody in your business was reading. The sunset is confirmed on OpenAI's migration guide at developers.openai.com, checked 12 Sep 2026.
What to do if your code still points at it
Requests to the old endpoints now fail. There is no grace period and no compatibility shim. The immediate work is the same whether you knew this was coming or not.
- Establish the blast radius. Run the four checks below to find every system that calls the old endpoints, not just the one that surfaced the problem.
- Map the objects, not the code line by line. OpenAI's guide gives a one-for-one mapping, set out in the table further down.
- Rebuild the conversation state. Any message history you want to keep has to be converted into conversation items and loaded into a new conversation. OpenAI never provided an automated tool for this.
- Decide before you port. If the system was already marginal, an outage is a legitimate moment to switch it off rather than pay to rebuild it. See the three options below.
Establishing whether you are affected takes an afternoon, not a project
Four checks, in the order that gets you an answer fastest.
Ask the person who built it one question. Not "is it affected", because the honest answer from a busy supplier is often a reassuring one. Ask this instead: "Does this system call the Assistants API or the threads endpoints, and if so what is the migration plan and the date?" A supplier who is on top of it will answer in a sentence. A supplier who goes quiet has told you something.
If nobody can answer, look at the code. You do not need to read it. You need somebody to search it for a short list of strings and report back what they find: assistants, threads, v1/assistants, v1/threads, and in the OpenAI libraries beta.threads or beta.assistants. Any of those appearing in a live system means you are affected, and that code is now calling endpoints that no longer exist. The word beta in the method name is the giveaway, because the current supported route does not use it.
Check the account, not just the code. Log in to the OpenAI account the business pays for and look at API usage by project. This also answers a second question worth knowing: whose name and card the account is in. It is often somebody in finance who has never heard of any of this.
The behavioural tells. OpenAI released the Responses API on 11 Mar 2025 as the replacement. If your system was built before then, the Assistants API was the mainstream route at the time, so the odds go up. Two symptoms point the same way: the thing remembers a conversation across sessions without your own application storing anything, and it answers from documents that somebody uploaded into it once rather than from a live system.
If all four come back clean, you are done, and it was worth an afternoon to know.
What changes is the plumbing, not the product
Nothing your staff see is supposed to change. The Assistants API was one way of getting a model to hold a conversation, use tools and refer to documents. OpenAI names the Responses API and the Conversations API as the replacement, with the Agents SDK sitting on top as the orchestration layer for anything that genuinely behaves like an agent. The concepts map across almost one for one, and OpenAI's migration guide sets the mapping out directly.
| Assistants API object | What replaces it | What changes in practice |
|---|---|---|
| Assistants | Prompts | The configuration holding model, tools and instructions. Prompts are versioned in the dashboard rather than managed through the API. |
| Threads | Conversations | History is stored as items (messages, tool calls, outputs) rather than messages alone. |
| Runs | Responses | Executes against input items and returns output items. The tool-call loop is now managed explicitly in your own application code. |
| Run steps | Items | A generalised object covering messages, tool calls, outputs and other data types. |
The third row is the one that costs money. Under the Assistants API the tool-call loop was OpenAI's to run. Under Responses it is yours, which means a port is not a find-and-replace: somebody has to write and test the loop your system relied on.
The part that mattered commercially was the failure mode, and it is worth recording because the next deprecation will behave the same way. This was not a service that got slower, or noisier, or more expensive as the date approached. The endpoints were removed. Affected systems worked exactly as well as they always had, right up until they did not work at all.
That has a specific consequence for how you plan for the next one. No signal comes. Nothing degrades to warn you, no error rate creeps up, no user complains that it feels off. Monitoring looked perfect on 25 Aug and the thing was dead on 26 Aug. If your plan relies on noticing, you do not have a plan.
One more thing OpenAI did not say. The published material covered the removal of the API but not what happens to the data that was sitting inside the assistants and threads already created. If you have not extracted conversation history you wanted to keep, establish now whether it is still reachable, and do not assume it is.
Three options, and retiring it is a real one
Most coverage of this assumes you migrate. That is one of three defensible answers.
| Option | When it is right | The honest catch |
|---|---|---|
| Migrate | The system earned its keep, the behaviour was right, and someone can still read the code | You are porting a design somebody made in 2024 onto 2026 tooling, including its mistakes |
| Rebuild | It began as a prototype and quietly became load-bearing, or nobody can explain how it worked | Costs more up front, and the temptation is to do it under deadline, which is the wrong moment |
| Retire | You cannot name what it produces or who relies on it | Somebody will be annoyed. Establish who uses it before you switch it off, not after |
Retiring deserves more airtime than it gets. A fair number of these were built in the enthusiasm of 2024, demonstrated well, and have run since on nobody's budget line and nobody's evidence. A forced deadline is an unusually good moment to ask what a thing actually returns, because it is the one moment when doing nothing has a cost attached.
If the answer is that nobody can point to what it produces, switching it off is a legitimate result and it is free.
The one option that was never on the list was waiting to see whether the date would slip. It did not. That is the useful precedent to carry into the next deprecation notice you receive.
What makes a migration cheap or expensive
The work has a predictable shape. What moves the number is not the size of the system. It is four things, and you can assess all four before commissioning anybody.
How much behaviour has to be preserved exactly. "It should keep doing roughly this" and "the output must match what it produces today, because it feeds a downstream process" are different jobs. The second needs a way to compare old and new output across real examples, and that is often more work than the migration itself. Be clear which one you are buying.
How much state is trapped in the old objects. This is the item that surprises people, so it is worth being blunt. OpenAI never provided an automated tool for moving threads across to conversations, and now that the old endpoints are gone the conversion has to be done from whatever export or copy of the history you hold. If your system holds a year of conversation history that has value, moving it is bespoke work that somebody has to write. If the history has no value, say so early and save the money.
Whether anyone wrote anything down. A documented system with prompts in a repository is a straightforward port. An undocumented one built by somebody who has left means paying an engineer to work out what it does before anybody can move it, and that reverse-engineering is usually the largest line.
Whether you hold the assets. Is the source in your repository or the supplier's, and is the API account in the company's name? If the answer is no to either, sort that out first, because it changes your negotiating position on everything else.
Two things to insist on while somebody has the lid off. Ask for prompt text to live in your own codebase rather than in dashboard objects. OpenAI's own migration guide notes that reusable prompt objects are themselves being deprecated, so moving onto them buys you a short reprieve and a second migration. Check OpenAI's deprecation timeline for the current shutdown date before anyone builds on them. And ask for the basics that make the next deadline cheap: logging you can read, usage tagged so you can see what each workflow costs, and one named person who owns the system. If you want the wider version of that exercise across every AI dependency you have, we set it out in our OpenAI dependency risk audit.
A forced migration is the worst moment to make architectural decisions
If you are now doing this in a hurry, the lesson is worth banking for next time rather than only regretting.
The decisions in the third section above are genuinely open while you have time, and closed once you do not. With three weeks in hand you can ask whether the system is worth keeping. With three days in hand, or none, the only available answer is the fastest port somebody can execute, which means you migrate the design unchanged, including the parts you would have thrown away, and you keep them for another two years.
Deadline work is also the most expensive way to buy engineering. You are asking for a specific person, at short notice, with no slack for the thing they find on day two. Suppliers price that accurately.
And if you missed the date, you are repairing a live outage rather than running a project, without the option of running old and new side by side to check the new one behaves. That comparison is the cheapest quality control available in a migration, and it only exists while the old system is still up. That option is gone here, which is precisely why the same mistake is worth avoiding on the next deprecation.
The decision in front of you
Run the four checks. Most businesses will find they are unaffected and can stop reading, and that certainty is worth the afternoon. If you are affected, you already have an outage rather than a deadline.
The decision is still not technical. It is whether this system deserves a migration, a rebuild or a switch-off. Make that call deliberately, even under pressure, rather than defaulting to the fastest port because something is down.
For how this sits against the alternatives, see the full guide to OpenAI for UK businesses.
We are an OpenAI Select Partner and we do this work, but we would rather you knew where you stood than bought something. If you want the exposure established and priced, request a quote and tell us what you think is running. If it turns out nothing needs to change, or the right answer is to turn it off, we will tell you that. We will not talk you into a rebuild, and the same team handles OpenAI implementation and Claude implementation on identical terms.
Stay Updated with Our Latest Insights
Get expert HubSpot tips and integration strategies delivered to your inbox.
