Somewhere in your account, there is probably a custom GPT you built in an afternoon and now use without thinking. Maybe it drafts first-pass proposals in your firm’s voice. Maybe it triages inbound briefs, or turns messy meeting notes into something a client can read. It works well enough that you stopped noticing it was ever a decision.
OpenAI has scheduled custom GPTs to retire on 11 December 2026. That is the standard date; some Enterprise workspaces have a deferral to February 2027, and creation of new GPTs is due to stop earlier, on 25 September 2026. The instinctive response is to start planning the move: which replacement, which platform, which afternoon to set aside.
That is a reasonable second step. The first step is to look at what is inside the thing you are moving.
The tool was never the valuable part
When you built that GPT, you did something more interesting than configure a tool. You wrote down a piece of how your business actually works.
Think about what went into it. The instructions you rewrote until the tone came out right. The examples you fed it because they represented good work rather than average work. The edge cases you added after it got something wrong. The small corrections, the “no, more like this,” the tacit standards you have never written down anywhere else.
That is a business process, made explicit for the first time. The GPT was simply where it happened to live.
Most firms have processes like this scattered everywhere, held in the heads of the people who are good at the work. The custom GPT was unusual because it forced you to say the quiet part out loud, and turn judgement into instruction. That act of articulation is the asset. The interface it sits behind is incidental.
What OpenAI’s migration will and won’t carry over
OpenAI is offering a migration route to what it calls plugins. As described in its guidance, your instructions become a skill, your knowledge files become reference files, and connected apps can come along. That is genuinely useful, and it will save you time.
It will not carry the things that never made it into the configuration. It won’t know when you trusted its output and when you quietly rewrote it. It won’t know what it consistently got wrong that you learned to fix on the way past, or what made a result good in your judgement rather than the model’s. Reports also say custom actions and your chosen model don’t transfer, so anything that depended on them needs rebuilding from an understanding of what it did.
A converter moves the text. It can’t move what only you know about the text.
What to actually do before December
Open the GPT and read it, before you migrate anything.
Copy out the instruction set, the reference files and the examples. Then write down what surrounds them. A page is enough, with five headings:
- What it is for: the job, in one sentence, as you would explain it to a new colleague.
- What goes in: the inputs it needs, and what a bad input looks like.
- What good looks like: the standard you hold the output to, in your words.
- What you always fix: the recurring mistakes you correct on the way past.
- What only a person would catch: the judgement calls you never trusted it with.
Take a proposal-drafting GPT. Its instructions might say “professional but warm.” The fifth heading is where you write that you always cut the opening paragraph, that it over-promises on timelines, and that you never let it quote a price. None of that is in the configuration, and all of it is the reason the tool works.
Do that once and the December deadline stops being a problem. Whatever you rebuild it in, whether that is the migrated version or something else entirely, you start from a clear specification and don’t have to reconstruct months of small refinements from memory.
The deadline is doing you a small favour
Tools will keep being retired. This is not the last time a platform you rely on will announce an end date and give you a window to react. If your response each time is to migrate, you spend your energy chasing containers and learn nothing durable.
If your response is to document what the tool encoded, something quieter happens. You build a growing record of how your business does its best work, in language that outlives any single piece of software. The next tool becomes easy to set up because you already know exactly what you are asking it to do.
You built a small piece of intelligence into a tool and then forgot it was there. Before it disappears, it is worth asking what else in your business works the same way: essential, invisible, and written down nowhere.
