OpenAI is retiring custom GPTs and moving workflows toward Plugins
OpenAI now says it plans to retire custom GPTs, the no-code assistants people created inside ChatGPT by combining instructions, uploaded knowledge, selected capabilities, apps and custom actions.
The recommended replacement is Plugins. OpenAI describes a plugin as a package that can bring reusable instructions, connected apps and other workflow capabilities together so the guidance that used to live inside a standalone GPT can work alongside the tools and information needed for a task.
This is not an immediate shutdown. Existing GPTs remain usable until the retirement date that applies to their account or workspace. The important work now is to identify which GPTs matter, prepare them for migration, and test the plugin replacement before the old GPT stops running.
OpenAI has not published a long technical post arguing that every GPT failed or explaining one single reason for retirement. Its public guidance focuses instead on the replacement architecture: move reusable workflow instructions into plugin skills and connect the apps those workflows need.
Official sources: Custom GPT retirement and migration FAQ and GPTs in ChatGPT.
The current Custom GPT retirement timeline
OpenAI’s most detailed dates currently apply to affected Enterprise workspaces. The company labels some dates as planned or targeted, which means rollout can still vary by workspace.
| Date | What is planned |
|---|---|
| September 11, 2026 | Admin notice to help organizations prepare. |
| September 17, 2026 | Target for the migration experience and user banner. OpenAI says this is a target, not a guarantee that every workspace sees it that day. |
| September 25, 2026 | Planned end of new custom GPT creation in affected Enterprise workspaces. Drafts that need migration should be published before this cutoff. |
| December 11, 2026 | Scheduled retirement. Custom GPTs stop running. |
OpenAI says the transition affects all ChatGPT plans, but the dates above are specifically the Enterprise timeline. Other plans are expected to follow the same general transition, with in-product notices coordinated around the change. Account-specific timing and exceptions may vary.
Timeline source: OpenAI’s Custom GPT retirement and migration FAQ.
What Free, Go, Plus and Pro users should know
There is an important plan-specific difference as of September 15, 2026. OpenAI’s current GPT documentation says new GPT creation and publishing are already unavailable on personal ChatGPT accounts, including Free, Go, Plus and Pro. Existing GPTs can still be used, subject to their normal access rules.
That means the September 25 creation cutoff in the migration FAQ should not be treated as a universal personal-account deadline. It is described as an Enterprise milestone. Personal accounts should follow the migration and retirement notice displayed in their own ChatGPT account.
OpenAI also says public GPTs created inside an affected Enterprise workspace can disappear under that workspace’s retirement timeline even when the person using the GPT is on a personal account. What matters is where the GPT was created, not only the plan of the person opening it.
Practical consequence: if you rely on someone else’s public GPT, you may not control its migration. Check whether the creator announces a replacement plugin rather than assuming the GPT link will continue working permanently.
What is a ChatGPT Plugin in the new system?
OpenAI’s current plugin system is broader than a simple external-service connector. A plugin can package several kinds of capability into one reusable workflow.
- Skills: reusable instructions and workflow guidance that tell ChatGPT or Codex how to perform a task.
- Connected apps: integrations that let the workflow search information, retrieve content or perform supported actions in external services.
- App templates: components administrators can use to configure workspace-specific app integrations.
- Instruction-only plugins: some plugins can contain skills without requiring any external app connection.
This distinction matters because an app and a plugin are not the same thing. An app connects ChatGPT to an external service. A plugin packages a workflow and can contain one or more skills, one or more apps, or both.
Installing a plugin does not bypass the permissions of its apps. Users still need the appropriate account authorization, workspace access and action approvals for any connected service.
Official plugin architecture: Plugins in ChatGPT and Codex.
Custom GPT vs ChatGPT Plugin: what actually changes?
| Area | Custom GPT | Plugin |
|---|---|---|
| Core instructions | Stored as the GPT’s instructions. | Can become a reusable skill. |
| External services | Could use apps or custom actions. | Can include connected apps and supported integrations. |
| Knowledge/reference material | Uploaded knowledge files could be attached to the GPT. | Reference material can be part of the migrated workflow, but OpenAI says it should be reviewed after migration. |
| Model selection | Creator could select a model supported by the GPT editor. | The GPT’s selected model does not carry over; Enterprise defaults apply in the migration workflow. |
| Conversation starters | Built into the GPT experience. | May not copy during migration. |
| Previous chats | Users may have existing GPT conversations. | Previous chats may not copy to the plugin. |
| Custom actions | Could call creator-defined APIs through OpenAPI schemas. | Do not migrate automatically. Required integrations must be rebuilt separately. |
| Sharing | Controlled through GPT sharing and workspace settings. | Replacement starts private and has separate plugin sharing/install permissions. |
The migration therefore preserves the workflow idea more than it guarantees a pixel-for-pixel or behavior-for-behavior clone. OpenAI specifically warns that a migrated plugin may respond differently and should be tested with familiar prompts before users are moved over.
What to save before you migrate a Custom GPT
OpenAI recommends preparing before the migration button appears. The goal is to make sure you can verify that the replacement still performs the job the GPT was created to do.
- Record the full GPT instructions. These are the core behavior, tone, boundaries and workflow guidance that should become the plugin skill.
- Inventory reference files. Note the knowledge documents, templates and examples the GPT depends on.
- List every app or integration. Separate ordinary connected apps from custom API actions because their migration behavior differs.
- Save several representative prompts. Include easy prompts, typical prompts and at least one difficult case for regression testing.
- Record expected outputs. If the GPT creates files, formatted reports or structured answers, save examples of what “correct” looks like.
- Identify the owner. Migration requires the GPT creator or, in the planned Enterprise workflow, a workspace admin.
- Identify everyone who needs the replacement. Access to the old GPT does not automatically become access to the plugin.
For Enterprise workspaces, draft GPTs need special attention. OpenAI says the GPT must be published before it can be migrated. Publishing it for migration does not mean it has to be publicly shared.
How to migrate a Custom GPT to a Plugin
As of September 15, the planned Enterprise migration experience is targeted for September 17, so the button may not be available yet. Once it reaches an eligible workspace, OpenAI describes the process as follows:
- Confirm Plugins are enabled. The Enterprise workspace must permit plugin use.
- Publish the GPT if it is still a draft. Drafts cannot be migrated directly.
- Open the GPT you own. A creator or workspace admin can start migration when the feature is available.
- Select the migration option. OpenAI plans to expose a migration button inside the published GPT.
- Review the generated plugin. Confirm the migrated skill, apps, reference material, examples and tools.
- Rebuild any custom actions separately. They are not part of the automatic migration.
- Test before sharing. Compare the replacement with known GPT behavior using familiar and difficult prompts.
- Review sharing and installation access. The replacement begins private.
- Have an intended user install and test it. This catches permission and app-authorization problems the creator may not see.
For personal accounts, OpenAI says users should follow the migration instructions shown in their own in-product notice rather than assuming the Enterprise controls and admin workflow apply exactly.
What transfers automatically during migration?
OpenAI currently names two core mappings clearly. The GPT’s instructions become a skill inside the new plugin, and connected apps are added to the plugin as apps.
OpenAI also tells users to review migrated reference files, templates, examples and tools before relying on the replacement. That wording is important: even when material appears in the migrated workflow, do not assume every reference or behavior is automatically equivalent to the old GPT.
The safest migration test is functional rather than cosmetic. Ask the replacement the same questions the old GPT handles well, verify that it uses the correct source material, and confirm that any required file or structured output still matches the workflow’s needs.
What does not automatically transfer?
Several parts of a custom GPT should not be assumed to survive migration unchanged.
| Item | Migration behavior |
|---|---|
| Custom actions | Do not transfer automatically. Rebuild the integration with a supported connector or custom MCP server. |
| Conversation starters | May not copy. |
| Previous GPT chats | May not copy to the plugin. |
| Selected GPT model | Does not carry over. In Enterprise, workspace defaults apply. |
| Sharing audience | Does not automatically become plugin access. The replacement starts private. |
| Third-party authorization | Still required. Installing a plugin does not grant new permissions inside connected services. |
This is why a migration should not be treated as “click once and delete the old GPT.” OpenAI deliberately leaves the migrated GPT usable until retirement so creators have a transition period for testing.
Custom actions are the part most likely to require rebuilding
Custom GPT actions allowed creators to define external API calls with authentication and an OpenAPI schema. Those actions are not carried over by the migration workflow.
OpenAI says the maintainer should assess each integration and rebuild the required capability using a supported connector or custom MCP server. This is not merely a copy-and-paste conversion: authentication, scopes, action approvals, server behavior and security review may all need to be reconsidered.
A rebuilt integration also should not be assumed to reproduce every capability of the old action. Test the exact operations the GPT used to perform, especially anything that writes data, changes an external record, triggers a transaction, or relies on user-specific OAuth access.
BeeVaults recommendation: migrate simple instruction-only GPTs first. Leave action-heavy GPTs more time because they have the greatest chance of needing engineering, admin permissions or security review before the replacement is ready.
OpenAI’s current custom-action model is described in Configuring actions in GPTs; the retirement FAQ explains that those actions do not migrate automatically.
Plugin access does not automatically match GPT access
OpenAI says a replacement plugin starts private. The creator or workspace administrator needs to review it, test it, and then share or publish it under the workspace’s plugin policy.
In Enterprise workspaces, OpenAI separates several permissions:
- Use plugins: permission to use plugins made available in the workspace.
- Share plugins: permission required to share a plugin with people or groups.
- Publish plugins to workspace: permission required to place the plugin in the workspace directory.
Even after the plugin itself is available, any connected app still has its own authorization model. A Google Drive, Slack or other connected app cannot suddenly expose data that the user’s provider account or workspace configuration does not permit.
That means a person who could open the old public or workspace GPT may still be unable to use the replacement until the plugin is shared, installed, and any required apps are authorized.
Plugin access and permission behavior: Plugins in ChatGPT and Codex.
What happens to the original GPT after you migrate it?
Migration does not immediately destroy the original. OpenAI says the GPT remains usable until retirement, but it becomes read-only after migration. The creator can no longer continue editing it and, under the planned migration flow, cannot delete it during the transition.
Future changes should be made to the plugin. This gives creators a period where the original GPT can still serve users while the replacement is being tested and distributed.
At retirement, custom GPTs are scheduled to stop running and leave the GPT directory. OpenAI says links to migrated GPTs are planned to redirect to the replacement plugin for people who already have access. The redirect itself does not grant access to the plugin.
This distinction matters for public GPT creators. A popular GPT link can potentially continue pointing users toward the replacement, but only users who satisfy the plugin’s access requirements will be able to use it.
Custom GPT retirement checklist
| Priority | Action |
|---|---|
| Now | List the GPTs you depend on and identify who owns each one. |
| Now | Save instructions, reference material, integrations and test prompts. |
| Before Enterprise creation cutoff | Publish any draft GPT that needs migration. Public sharing is not required. |
| When migration appears | Migrate instruction-based GPTs and inspect the resulting skill and apps. |
| For GPTs with actions | Plan a separate connector or custom MCP rebuild. |
| Before switching users | Test easy, normal and difficult prompts against the replacement. |
| Before broad sharing | Confirm plugin sharing, install permissions and app authorization. |
| Before retirement | Move active users to the plugin and confirm the replacement works for a non-creator account. |
BeeVaults takeaway: the safest way to think about this transition is not “GPTs become Plugins automatically.” The instructions can migrate into a skill and connected apps can move into the plugin, but permissions, previous chats, conversation starters, selected models and especially custom actions require separate attention. Treat the period before December 11 as a testing and migration window, not as a reason to wait until the final week.