Custom GPT Retirement: Dates, Migration and Limits
OpenAI plans to stop new custom GPT creation in affected Enterprise workspaces on October 26. See retirement dates, what migrates, and what teams must rebuild.
OpenAI's custom GPT migration guidance now gives creators a concrete transition plan: the company lists October 26, 2026 as the planned end of new custom GPT creation in affected Enterprise workspaces, followed by a standard retirement date of December 11, 2026. The key distinction is that a planned workspace milestone is not proof that every account has already been blocked. Existing GPTs remain usable until their applicable retirement date, subject to permissions.
What changes on October 26—and what does not
The October 26 milestone concerns creation of new custom GPTs in affected Enterprise workspaces. OpenAI explicitly says the creation freeze does not stop edits to existing GPTs that have not yet been migrated. After migration, the original GPT remains usable until retirement but becomes read-only. Teams should verify the notice for the workspace where a GPT was created; using that GPT from another account does not change which workspace timeline applies.
October 26 is a planned Enterprise creation-freeze date in OpenAI's FAQ, not independent confirmation of enforcement in every workspace. Migration access, plugin permissions and approved deferrals can vary.
Retirement dates and migration availability
Dates to plan around
| Milestone | What the official guidance says |
|---|---|
| October 26, 2026 | Planned new-GPT creation cutoff in affected Enterprise workspaces; existing unmigrated GPTs remain editable. |
| December 11, 2026 | Standard scheduled retirement of custom GPTs and their pages. |
| February 11, 2027 | Later retirement only for qualifying affected Enterprise workspaces with an approved deferral. |
| Migration access | Account/workspace dependent; a target date does not guarantee a visible migration option. |
This is a transition to plugins, which can combine reusable skills with connected apps. OpenAI's documented migration route is My GPTs, then Migrate to plugin when the option is available. It uses the latest published GPT version. Drafts and unpublished edits are excluded, so publishing essential edits first matters—even if the GPT should remain private.
What transfers, and what must be rebuilt
OpenAI says a GPT's instructions become a skill inside the plugin; knowledge files become reference files; connected apps are represented as apps. However, custom actions do not migrate automatically, and the GPT's selected model does not carry over. Existing conversations remain accessible after GPT retirement, but the old GPT page and the GPT itself become inaccessible at the applicable deadline. The migrated plugin begins private and does not inherit the GPT's sharing audience.
The biggest operational risk is not losing a prompt; it is assuming a migrated workflow still has the same external actions, data access and collaborators. A GPT that summarizes internal documents may be straightforward to validate. A GPT that calls a custom CRM action requires integration redesign, permission checks and an end-to-end test. Treat migration as a workflow change, not a file conversion.
A practical migration checklist for teams
- Inventory the GPTs your team owns and uses; record each GPT's owning workspace, maintainer, users and critical tasks.
- Review instructions, knowledge files, connected apps and custom actions; save representative prompts and expected outputs.
- Finish and publish necessary edits to the GPT before migration. Publishing is not the same as public sharing.
- When Migrate to plugin appears, create the replacement and verify skills, reference files and connected-app access.
- Rebuild custom-action integrations where needed, with security and admin review; test realistic read/write workflows.
- Share or publish the replacement separately, verify collaborator access, and keep the old GPT available until the relevant retirement date.
Workspace administrators should review plugin installation, included app access and role permissions separately. A user may be able to install a plugin yet still lack authorization for an app inside it. OpenAI's administrator documentation also makes clear that plugin installation does not override provider permissions or existing data-access restrictions. Teams should verify the exact role, provider account and approved actions before enabling a migrated workflow in production.
Questions people ask
Questions people ask
Does the October 26 creation freeze stop edits to existing custom GPTs?
No. OpenAI describes October 26, 2026 as a planned cutoff for creating new custom GPTs in affected Enterprise workspaces, not a confirmed universal enforcement event. Existing unmigrated GPTs can still be edited and used under their current permissions. Once you migrate one, its original becomes read-only until the applicable retirement date. Check your workspace notice before relying on any deadline.
Can I migrate an unpublished GPT draft without making it public?
You must first publish the GPT, but you do not have to share it publicly. OpenAI says migration copies the latest published version, not drafts or unpublished edits. Finish your instructions and knowledge-file changes, publish that version, and then use My GPTs > Migrate to plugin when your account has the option. Test the resulting private plugin before sharing it.
Do custom GPT actions, knowledge files and model choices transfer to plugins?
They do not all transfer. OpenAI says instructions become a plugin skill, knowledge files are copied as reference files, and connected apps become apps. Custom actions do not transfer automatically, and the selected model is not preserved. An action-dependent workflow may need a supported app or a separately configured custom MCP integration, subject to permissions. Re-test every external action rather than assuming parity.
Will people who used my GPT automatically get access to its replacement plugin?
No. OpenAI says migration does not carry over the GPT's sharing settings or install the replacement for existing users. A migrated plugin starts private; workspace sharing or public submission requires separate steps and permissions. Existing GPT conversations remain accessible after retirement, but the GPT itself becomes inaccessible at the applicable retirement date. Plan a separate handoff and access test for collaborators.
Plan for December 11 retirement, but treat the October 26 Enterprise creation cutoff as a planned, workspace-specific milestone rather than proof of universal enforcement. Publish your latest GPT changes, migrate when the option appears, rebuild custom actions, and test access before directing users to a replacement plugin.
Explore related Make Better resources
- ChatGPT Voice plugin workflows— Related plugin capabilities and workflow context
- GPT-4o and GPT-4.1 API migration deadlines— Separate API model retirement, not custom GPT retirement
Sources & useful resources
- OpenAI: Custom GPT retirement and migration FAQ— Primary dates, migration workflow, data transfer and sharing caveats; updated October 2026
- OpenAI: Plugins in ChatGPT— Official plugin model, installation and availability
- OpenAI: Plugin and app admin controls— Official workspace roles, app permissions and access controls