Custom GPT Retirement on December 11: What Moves to Plugins and What You Rebuild

OpenAI’s custom GPT retirement is scheduled for December 11, 2026. On that date, custom GPTs and their GPT pages become inaccessible, according to OpenAI’s migration FAQ. The replacement is plugins, which package instructions, reference files and connected apps. Affected Enterprise workspaces have two more dates: new GPT creation is planned to end October 26, and workspaces with an approved deferral keep their GPTs until February 11, 2027.

This piece walks through the custom GPT retirement dates by plan, what the built-in migration carries over, and what it leaves behind. It covers how custom actions get replaced, what happens to GPTs that members reach by public link, and the admin steps for Business and Enterprise. It ends with an inventory and a migration checklist. We wrote it for nonprofits and associations that built a member-facing GPT or a set of staff GPTs.

The short version of the custom GPT retirement: instructions, knowledge files and connected apps move across with one button. Custom actions, the model choice, conversations and sharing settings do not. A migrated plugin starts private, so every GPT your members or staff use today needs a new sharing decision. If a GPT calls your own API through an action, start now. That work needs a developer, and on OpenAI’s current documentation it points to an MCP server.

The custom GPT retirement dates, by plan

OpenAI posted the plan on September 11 in its ChatGPT release notes. The same entry appears in the Business release notes. OpenAI says it is "planning to retire custom GPTs across ChatGPT plans and provide a migration path to plugins." Neither entry lists dates. Both say timing may vary by plan and workspace.

The dates sit in the Custom GPT retirement and migration FAQ. It states that "Custom GPTs are scheduled to retire on Dec 11, 2026." It also says the transition affects all ChatGPT plans, while migration and plugin access may differ by account or workspace. The other dates appear in its Enterprise guidance.

Does the October 26 cutoff apply to your plan?

For anyone outside Enterprise, it is unclear. The FAQ lists October 26 only in its Enterprise guidance. As of September 27, we found no creation cutoff for Free, Plus, Pro or Business on the pages we read. That is not proof there is none. Business workspaces should plan as if the Enterprise date applies. Building new GPTs now only adds to the migration list.

The February 2027 deferral is the only published extension to the custom GPT retirement. It is narrower than it sounds. The FAQ says the extension "applies only to workspaces with a qualified, approved deferral." It does not explain how a workspace qualifies or how to ask. An Enterprise customer would raise it with its OpenAI account contact. Do not build a plan around it until you have it in writing.

What the built-in migration carries over

Migration starts from the GPT itself. When it is available for your account, go to My GPTs and select Migrate to plugin. According to the FAQ, three things move:

• Instructions: become a skill inside the new plugin.
• Knowledge files: copied into the plugin’s reference files.
• Connected apps: added to the plugin as apps.

Migration uses the GPT’s latest published version. Drafts and unpublished edits do not transfer. Publishing does not mean making a GPT public, so a private publish is enough. After migration, the original GPT turns read-only. It keeps working until retirement, but its creator cannot delete it. Future edits happen in the plugin.

Who can press the button matters for organizations. The creator can. In the planned Enterprise workflow, a workspace admin can too, once migration is available and plugins are enabled. The FAQ does not describe an admin path for Business. People who only use a GPT cannot migrate it. If the staff member who built a GPT has left, sort out ownership now.

What the custom GPT retirement leaves behind

Five things do not come across in the built-in migration:

• Custom actions: the calls a GPT makes to outside APIs. The FAQ says features that depend on them “will not work in the plugin until you set up a replacement.”
• Model selection: the GPT’s chosen model does not carry over. In Enterprise workspaces, Enterprise defaults apply.
• Conversations: they stay with the original GPT until it retires.
• Sharing settings: public sharing included. Existing users get no access to the replacement.
• Identical behavior: the FAQ warns that “a migrated plugin may respond differently.”

The FAQ does not mention the GPT Store at all. What it does say covers the outcome. GPT pages become inaccessible at retirement. A migrated plugin starts private. Making a plugin public "requires a separate plugin submission process." A Store listing does not turn into a plugin listing by itself. We found no published detail on that submission process.

Conversation history is the item people overlook. The FAQ does not say whether past chats with a GPT stay readable after retirement. If staff treat those chats as a record, copy what you need before December 11.

Replacing custom actions with MCP apps

Custom actions are the hard part. OpenAI’s GPT Actions documentation describes them as a way to turn a request into the JSON an outside API expects. Associations used them to look up member records, check event registrations or search a resource library. None of that migrates.

The FAQ says rebuilding the connection "may require a custom MCP server and technical setup." It does not name one official replacement. OpenAI’s developer docs point the same way. The MCP guide is now titled "Building MCP servers for plugins and API integrations." Custom apps in ChatGPT are built from remote MCP servers in Developer mode. Our guide to the Model Context Protocol covers the basics if MCP is new to your team.

Your plan decides who can build one, per OpenAI’s Developer mode article:

Developer mode runs on the web only, not mobile. On Business and Enterprise, admins and owners create the app under Workspace settings, then Apps, and publish it to the workspace. The article lists OAuth or no authentication. OpenAI does not verify custom apps, and it warns that untrusted MCP servers raise prompt injection risk.

What an action rebuild involves

The OpenAPI schema behind an action is still useful. An MCP server can wrap the same endpoints, so most of the API work carries over. Authentication is where rebuilds stall. If an action used an API key, check it against the auth options Developer mode lists. A member database should never sit behind no authentication.

This is the same pattern we saw with the Assistants API shutdown in August. The business logic survives. The plumbing gets rewritten.

Budget review time as well as build time. The FAQ tells Enterprise teams to involve "the appropriate technical and security teams" on rebuilt integrations. Our piece on what CMS platforms let agents do covers the permission questions worth asking before an MCP app gets write access to member data.

Member-facing GPTs: public links and the GPT Store

This is where the custom GPT retirement hits associations hardest. A public GPT reached by link or through the Store stops working when its page goes dark. The migrated plugin starts private. Making it public needs the separate submission process. Members then need "an account where plugins are available," in the FAQ’s words.

OpenAI’s plugins article says the directory is available across plans, but features vary by plan, rollout and account. We could not confirm whether a Free account can install a publicly submitted plugin. Treat the public GPT as ending December 11 and choose a replacement:

• Submit a public plugin once OpenAI documents the process, and test it from a Free account.
• Move the tool to your own site as a search or chat tool you control.
• Retire it if usage does not justify the work.

Then update every place the old link lives: member emails, the website, the learning platform and handouts.

One Enterprise detail catches people. Public GPTs built in affected Enterprise workspaces follow the Enterprise timeline, even for people who use them from a personal account.

Custom GPT retirement admin steps for Business and Enterprise

Admins run most of this from Admin > Plugins. Per the plugins article, they set each plugin to Available, so members can install it, or Installed, so it installs for eligible members. Enterprise and Edu can assign plugins to custom roles. Admins control whether members can share or publish plugins. They can also export the plugin catalog as a CSV.

Workspace sharing has three levels: people you invite, anyone in the workspace with the link, or visible in the workspace directory. Publishing to the workspace directory does not publish a plugin publicly.

OpenAI’s admin controls article adds per-app switches for read actions and write actions, plus a policy for new actions. Keep write actions off until someone has reviewed them.

Credits are the other admin question. In Enterprise, the FAQ says using a migrated GPT without apps in Instant chat has no incremental cost. Creating and editing plugins through a conversation uses Work or Codex, and actions in Work consume credits. OpenAI does not state the Business equivalent. If you already watch the shared pool, our look at the ChatGPT Business Premium seat and the ChatGPT for Word default cover the other draws on it.

An inventory checklist for the custom GPT retirement

Start with a list. For each GPT, record:

• Name, creator, and whether the creator still works for you.
• Who uses it (staff, members or the public) and how they reach it.
• Whether it is published, and where its links appear.
• Its knowledge files, and whether they are current.
• Its connected apps, and whose account authorizes each one.
• Its custom actions, the API behind each, and how each authenticates.
• The model it uses, and whether answers depend on that model.
• Recent usage, so you can retire the ones nobody opens.

Sort the list into three piles. GPTs without actions migrate with a button. GPTs with actions need a developer. GPTs nobody uses get retired. For staff tools, compare what ChatGPT now does natively in Chat, Work and Codex. Some GPTs may not need a plugin at all.

Migrating a GPT to a plugin, step by step

1. Publish the latest version of the GPT. A private publish is enough.
2. In My GPTs, select Migrate to plugin.
3. Open the new plugin and check its skill, reference files and apps.
4. Reconnect the apps. Each needs its own authorization.
5. Rebuild any custom actions as an MCP app, and have security review it.
6. Test with familiar prompts and at least one harder case, as the FAQ advises. Check output formats and files.
7. Share the plugin at the right level. Ask one intended user to install and test it.
8. Tell users how to call it: an @ mention, or + and then More.
9. Update links and remove the old GPT from your documentation.

Pilot on one low-risk staff GPT first. Member-facing tools come next, since they carry the most work and the most visibility.

What we could not confirm about the custom GPT retirement

• A creation cutoff for Free, Plus, Pro, Business or Edu.
• How an Enterprise workspace qualifies for the February 2027 deferral.
• How public plugin submission works, and whether Free accounts can use a submitted plugin.
• What happens to GPT Store listings beyond pages becoming inaccessible.
• Whether GPT conversations stay readable after December 11.
• Whether Plus and Pro creators get the same migration button. OpenAI’s skills documentation covers only workspace plans.

OpenAI’s GPT Actions developer docs carried no deprecation notice when we checked on September 27. Expect OpenAI’s custom GPT retirement pages to change before December.

Frequently Asked Questions