On 26 Aug 2026, an OpenAI API that a lot of UK businesses are quietly running on stops 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.
The date is 26 Aug 2026, taken from OpenAI's own deprecations page, checked on 08 Aug 2026. OpenAI announced it on 26 Aug 2025 and gave twelve months. That is fair notice by any standard. It only helps you if somebody in your business was reading.
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. 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: assistants become prompts, threads become conversations, runs become responses.
The part that matters commercially is the failure mode. This is not a service that gets slower, or noisier, or more expensive as the date approaches. The endpoints are removed from the API. Your system works exactly as well as it does today, right up until it does not work at all.
That has a specific consequence for how you plan. There is no signal coming. Nothing degrades to warn you, no error rate creeps up, no user complains that it feels off. Whatever monitoring you have will look perfect on 25 Aug and the thing will be dead on 26 Aug. If your plan relies on noticing, you do not have a plan.
One more thing OpenAI has not said. The published material covers the removal of the API, but does not state what happens to the data sitting inside the assistants and threads you have already created. Treat anything in there that you would want to keep, conversation history above all, as something to extract before the date rather than after it.
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 earns its keep, the behaviour is 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 works | 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 is not on the list is waiting to see whether the date slips. OpenAI published it a year ahead and has restated it since.
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's migration guide states plainly that it will not provide an automated tool for moving threads across to conversations. 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, because OpenAI has deprecated reusable prompt objects too, with the v1/prompts API scheduled to shut down on 30 Nov 2026. Migrating onto them buys you about three months. 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
The argument for doing this now rather than late is not that late costs more per day, although it does.
It is that 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, 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 miss the date entirely, you are then 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.
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, the decision is not technical. It is whether this system deserves a migration, a rebuild or a switch-off, and you should make that call deliberately and soon, rather than by default in the last week before the date.
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 take no margin on your usage, so we have no reason to 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.
