OpenAI is retiring custom GPTs. On 11 December 2026 they stop working on every ChatGPT plan, unless an Enterprise workspace has an approved deferral, and OpenAI plans to stop Enterprise workspaces building new ones on 26 October. Most companies that use ChatGPT have a few GPTs that quietly hold up real work: a proposal writer, a policy helper, an onboarding guide, one that drafts replies from your price list. The awkward part isn't the migration button. It's that nobody has a list of which GPTs matter, who built them, or which ones talk to other systems through actions that won't survive the move.
What is the custom GPT retirement?
Custom GPT retirement is OpenAI's plan to switch off custom GPTs on 11 December 2026 and move them to plugins, which bundle a GPT's instructions, files and connected apps into a new format, while custom actions, sharing settings and model choices don't carry over. OpenAI announced it on 11 September 2026 in its release notes and in a notice to Enterprise admins. Its help centre says "The transition affects all ChatGPT plans."
This guide is for the people who'll be asked to sort it out: IT leads, operations leads and the COO or founder who owns your ChatGPT rollout. It covers the dates, what moves and what breaks, who can migrate what, and a five-step plan. It's based on OpenAI's own help centre as of October 2026. OpenAI says the dates "are subject to change", so check your workspace notice too.
When are custom GPTs retiring?
The standard retirement date is 11 December 2026 for every plan. On that date, in OpenAI's words, "custom GPTs and their GPT pages become inaccessible." Enterprise workspaces with "a qualified, approved deferral" get until 11 February 2027. That extension "does not apply to every workspace", and the standard admin emails don't mention it, so ask your account team if you think you have one.
For affected Enterprise workspaces, OpenAI has published a timeline:
| Date | What happens |
|---|---|
| 11 September 2026 | Admin notice sent |
| 22 September 2026 | Target for the migration option and user banner (a target, not a guarantee) |
| 1 October 2026 | Banner target for workspaces that opted into delayed banners |
| 26 October 2026 (planned) | Creation of new custom GPTs ends |
| 11 December 2026 | Standard retirement |
| 11 February 2027 | Retirement for workspaces with an approved deferral |
The 26 October freeze stops new GPTs, not edits. OpenAI says it "does not prevent edits to existing, unmigrated GPTs." Migrating does freeze them, though. Once a GPT is migrated, the original stays usable until retirement but becomes read-only, and its creator can't delete it.
Your chat history is safe. OpenAI says "existing conversations with custom GPTs will remain accessible after retirement" and you don't need to do anything to keep them.
What replaces custom GPTs?
Plugins. OpenAI describes a plugin as a package of "reusable instructions, connected tools, and other capabilities." It can hold skills (instructions and workflow guidance), connected apps (links to other accounts and systems) and app templates that admins configure for a workspace. Some plugins work in both ChatGPT and Codex.
When a GPT is migrated, three things move across:
- Instructions become a skill inside the new plugin.
- Knowledge files are copied into the plugin's reference files.
- Connected apps are added to the plugin as apps.
Migration uses the GPT's latest published version. "Drafts and unpublished edits do not transfer." Publishing doesn't mean sharing publicly, so a builder can publish a GPT privately just to migrate it.
What breaks when you migrate a custom GPT?
Four things don't make the trip, and the first one is the one that hurts.
| Doesn't carry over | What it means for you |
|---|---|
| Custom actions | Any GPT that calls another system through a custom action (your CRM, a booking tool, an internal database) loses that connection until someone rebuilds it. Connections made through connected apps move across |
| The selected model | In Enterprise workspaces, the plugin uses your Enterprise defaults |
| Sharing settings | The plugin "starts private". Nobody who used the GPT gets it automatically |
| Unpublished drafts | Only the last published version moves |
Custom actions. OpenAI is blunt: "GPT custom actions do not transfer through the migration workflow." Features that depend on them stop working in the plugin until there's a replacement. That might be an existing app that does the same job, or it "may require a custom MCP server and technical setup". MCP is a standard way of connecting an AI tool to another system. Either way, OpenAI warns that a rebuilt integration "should not be assumed to provide every capability of the original action."
Custom actions are the GPTs most likely to matter, because they're the ones that do something rather than just answer. They're also the ones most likely to have been built by one enthusiast on a weekend, with an API key nobody else knows about. Rebuilding them is a technical job with a security review attached, so start these first.
The answers may change too. OpenAI says "A migrated plugin may respond differently." A GPT that people trust because it always formats the proposal the same way needs testing before anyone relies on the plugin.
Who can migrate a custom GPT?
The person who built it, or a workspace admin. Using a GPT doesn't give you the right to migrate it: "Permission to use someone else's GPT does not give you permission to migrate it." In Enterprise workspaces, "a GPT's creator or a workspace admin can migrate it when migration is available and plugins are enabled." The GPT has to be published first.
That creates a gap in most companies. The GPTs a team depends on were often built by someone who has since changed role or left. If the builder's account has gone, an admin has to do it. If nobody knows a GPT exists, nobody does it, and it disappears on 11 December.
Public GPTs need their own check. If your company published a GPT that customers or partners use, it follows your workspace's timeline. OpenAI says public GPTs created in affected Enterprise workspaces "are included in the Enterprise transition, even if you access them from a personal account or another workspace." And "Access to a public GPT does not guarantee access to its replacement plugin."
The admin settings that decide whether the replacement reaches anyone
In Enterprise workspaces, a migrated plugin is useless until three permissions line up. People need Use plugins and a policy that lets them install the plugin, or installs it for them. Sharing needs Share plugins. Putting it in the workspace directory needs Publish plugins to workspace. OpenAI notes "These are separate permissions."
Two defaults are worth knowing. In ChatGPT Business, apps are enabled by default. In Enterprise and Edu, "new plugins and apps are disabled by default." Check your own plan's settings before you assume a replacement will reach anyone.
What it costs
In Enterprise workspaces, OpenAI says "using a migrated GPT without apps in Instant Chat has no incremental cost." Building and editing plugins is different: "Creating and editing plugins through a conversation use Work or Codex. Actions in Work consume credits." If you've set credit limits, the people doing the migration may hit them.
How do you prepare for custom GPT retirement?
Five steps, in order. Each one produces what the next one needs.
01 · List every GPT your teams rely on
OpenAI's own advice to Business admins is to "review your team's GPTs and identify their creators and the people who need access." Do it as a list, not a memo. For each GPT, record its name, who built it, who uses it and how often, whether it has knowledge files, whether it has custom actions, and whether it's public. Ask teams directly as well as checking the workspace, because the GPT that matters most is often one a single team uses every day.
This step produces your GPT list: everything that will stop on 11 December, with a builder and users against each one.
02 · Decide keep, rebuild or retire for each one
Not every GPT deserves a plugin. Many were experiments that nobody has opened in months. Sort each one into three groups:
- Migrate: in regular use, no custom actions. These are quick.
- Rebuild: in regular use, with custom actions. These need technical time and a security review.
- Let it retire: unused, duplicated or replaced by something better. Tell its users and let it go.
This step produces a shorter list with a decision on each line, and a separate list of rebuilds that need technical help.
03 · Publish before 26 October, then migrate
Migration only uses the published version, and in Enterprise workspaces nobody can create a new GPT after 26 October. If a builder has unpublished improvements, they should publish them now (privately is fine). Then the creator or an admin migrates each GPT on the keep list from My GPTs by selecting Migrate to plugin. Do the rebuilds in parallel: check whether an existing app covers the custom action before anyone writes a custom MCP server.
This step produces a private plugin for every GPT you're keeping.
04 · Test each plugin against the old GPT
OpenAI's test is a good one. Run a few familiar prompts "and at least one harder case" through both, and check that the plugin "selects the right skill and follows your instructions", uses the right reference material, produces complete answers or files in the format you need, and "has the tools and integrations the workflow needs." Ask a regular user to do the testing, not the builder. Users know what good looks like.
This step produces a pass or fail for each plugin, with the differences written down.
05 · Share it, switch users over, then retire the old GPT
The plugin starts private. Share it with the people on your list, or publish it to the workspace directory, and check one of them can install and use it. Then tell users to switch, and give each plugin an owner who'll keep it up to date. The old GPT is read-only now, so every future change happens in the plugin.
This step produces working plugins with owners, and nothing left that depends on a GPT.
A forced migration is a free audit
A retirement deadline does something a policy rarely manages. It makes everyone find out what they actually use. Most companies have never had a full list of the GPTs their staff built, and between now and December they'll need one whether they like it or not.
Treat the GPT list as the start of your AI list, not a one-off. Our framework keeps one record of every AI tool and use in the organisation, gives each a review date where you keep it, fix it or retire it, and says that when you retire something you cover its data, anything that depends on it, and the people who relied on it. That's this migration in one sentence. Keep, replace or retire, in module 3 of our free course, walks through the same sort that step 02 needs. Owners and backups, in module 7, covers step 05, so the plugin doesn't become the next thing nobody owns. If you're working out how GPTs and plugins fit into a wider rollout, our guide to AI deployment covers the stages and why pilots stall.
The custom actions deserve one more thought. A GPT that writes to your CRM through an action is an agent in all but name: software acting on your systems with credentials someone set up once. Rebuilding it as a plugin is a chance to ask the questions you'd ask of any agent. Who owns it, what can it reach, and who can switch it off? Our AI agent governance article sets out those decisions.
What's still open
- Whether the dates hold. OpenAI says the Enterprise milestones "are subject to change", and the creation freeze is marked "planned".
- Creation cutoffs outside Enterprise. OpenAI's help centre gives 11 December as the retirement date for all plans, but publishes a creation cutoff only for Enterprise workspaces. Business and personal accounts should follow their in-product notice.
- Who gets a deferral. OpenAI doesn't publish the criteria for the 11 February 2027 extension.
- How well rebuilt actions match the originals. It depends on which apps exist for your systems, and OpenAI makes no promise that a rebuild will do everything the action did.
We'll update this article if OpenAI moves any of these dates. The date at the top of the page shows when we last checked.
Sources
- Custom GPT retirement and migration FAQ, OpenAI Help Center, October 2026: the retirement and deferral dates, the Enterprise timeline, what transfers and what doesn't, who can migrate, testing advice, permissions and credits. The help centre blocks automated access, so we read the version archived on 7 October 2026.
- ChatGPT Business release notes, OpenAI Help Center, September 2026: the 11 September 2026 announcement and OpenAI's advice to review your team's GPTs and their creators.
- Plugins in ChatGPT and Codex, OpenAI Help Center, September 2026: what a plugin contains, installation policies and sharing.
- Admin controls, security, and compliance for plugins and apps, OpenAI Help Center, September 2026: the default app and plugin settings by plan.
- OpenAI Getting Rid of Custom GPTs and Moving to Plugin Architecture, THE Journal, October 2026 (secondary): independent confirmation of the dates and of custom actions needing a rebuild.