The Timeline
The dates are staggered, but the endpoint is December 11 for most users.
According to OpenAI's published schedule, the migration experience and in-product banners appeared in mid to late September 2026. Creation of new custom GPTs ends in late October — sources vary on whether it is October 25 or October 26. Custom GPTs and their GPT pages stop working on December 11, 2026. Enterprise, Education, and Healthcare workspaces can apply for a deferral that extends the deadline to February 11, 2027.
The replacement is plugins. OpenAI positioned plugins as more capable than custom GPTs: they can run in multiple environments including Codex, they support more sophisticated integrations, and they are where OpenAI is putting development investment. The message is that plugins are the future and custom GPTs were a step along the way.
Whether you agree with that framing, the practical implication is that custom GPTs stop working in December. If you have one that matters to you, migration is not optional.
What Transfers
The migration path moves some components from your custom GPT into a plugin. Instructions become a skill within the plugin — the carefully worded system prompt that defined your GPT's behavior carries over. Knowledge files transfer, though you may need to re-upload if the format changed. Connected apps are added to the plugin, though you may need to re-authorize them.
The migration is creator-initiated. Only the person who created the GPT, or a workspace admin, can run it. You go to My GPTs, select the GPT, and choose Migrate to Plugin. The process is not automatic, and if you do not do it before December 11, the GPT simply stops working.
After migration, the original GPT remains usable until retirement but becomes read-only. You cannot update it, only use it. The plugin starts private regardless of the GPT's previous sharing status, and making it public requires a separate review by OpenAI. Users who had access to your shared GPT do not automatically have access to the plugin; they need a new invitation.
What Does Not Transfer
The gaps are significant if you relied on any of these capabilities.
Custom actions do not transfer. If you built API integrations that let your GPT call external services — check inventory, submit forms, query databases — those integrations do not migrate automatically. You may be able to rebuild them using an available app or a custom MCP server, but the work is manual and the architecture is different. For some users, the custom actions were the entire point of the GPT.
The model you selected does not transfer. If you chose a specific model version because it behaved better for your use case, the plugin will run on whatever model the plugin environment defaults to. You lose the ability to pin to a particular model's behavior.
Conversation history does not transfer. Every conversation users had with your GPT — the context it built, the examples that refined its behavior, the corrections that taught it your preferences — is not carried over. The plugin starts with the instructions and knowledge files, but no memory of how the GPT was actually used.
Sharing settings do not transfer. A GPT that was public remains in the GPT directory until retirement but the plugin starts private. A GPT that was shared with specific people requires re-inviting those people to the plugin. Your audience does not automatically follow you.
| Component | Transfers? | Notes |
|---|---|---|
| Instructions | Yes | Becomes a skill in the plugin |
| Knowledge files | Yes | May need re-upload |
| Connected apps | Yes | May need re-authorization |
| Custom actions | No | Rebuild manually if needed |
| Selected model | No | Plugin uses its default |
| Conversation history | No | Starts fresh |
| Sharing settings | No | Plugin starts private |
| User access | No | Re-invite required |
What This Reveals About Ownership
A custom GPT always felt like something you built. You crafted the instructions, refined the tone, uploaded documents, tested and iterated. The GPT had a name and an identity. It appeared in the GPT store with your attribution. Users bookmarked it. It felt like a product.
But what you built was a configuration of someone else's system. The instructions were text stored on OpenAI's servers, interpreted by OpenAI's models, running in OpenAI's environment. You never had a file you could download that was your GPT. You had access to a set of settings that defined how ChatGPT behaved when invoked under a particular name.
The retirement reveals this. OpenAI is changing how their system works, and your configuration is migrating to a new structure, with losses. You do not have a fallback. You cannot run your GPT somewhere else. You cannot preserve it in amber. You can take the parts that transfer and leave the parts that do not, because that is what was ever available to you.
This is not a complaint about OpenAI specifically. It is how all platform-native creations work. A Notion template, a Figma component, a custom Slack workflow — each is valuable work that exists only within its platform. The platform can change the rules, sunset the feature, or evolve in a direction that leaves your creation behind. The work is real. The ownership is conditional.
What to Do Before December
If you have custom GPTs that matter, there is work to do before they stop.
- Export your instructions now. Copy the full text of your GPT's instructions somewhere you control — a text file, a note, your own documentation. This is the part that transfers, but you should have your own copy regardless.
- Save your knowledge files locally. Download every document you uploaded. The migration may re-upload them, but having local copies means you can use them elsewhere.
- Document your custom actions. If you built API integrations, write down exactly what they do, what endpoints they call, what parameters they use. You will need this to rebuild them, and the GPT interface that shows them is going away.
- Run the migration early. Do not wait until December. Migrate in October or November, verify that the plugin works, and identify what is missing while you still have time to address it.
- Re-invite your users. If people depended on your shared GPT, tell them it is moving and send them the new plugin link. They will not find it automatically.
- Consider whether the plugin is worth it. For some GPTs, the migration losses are acceptable. For others, the custom actions were the whole point and the resulting plugin is not useful. Better to know now than to spend time migrating something you will not use.
Mindly stores your knowledge in files you control, so the next platform change does not take your work with it. Own your files →
The Broader Pattern
Custom GPTs are not the first feature OpenAI has retired and will not be the last. The Assistants API was deprecated earlier this year. Various model versions have been sunset. The platform evolves, and features that were central become legacy. This is normal for a fast-moving field, and it is not unique to OpenAI.
The lesson is about where to put your effort. Work that lives inside a platform is work that depends on the platform's continued support. Work that lives in files you control, in formats that are portable, in systems that do not require a particular vendor to keep running — that work is more durable. Not because vendors are untrustworthy, but because the timeline of their product decisions is not your timeline.
If you build something that matters, build it in a way that you can take with you. Instructions and knowledge files are text. They can live anywhere. Custom actions and conversation history live only in the platform, and when the platform changes, they are gone. Know the difference, and put the irreplaceable work in the durable place.