OpenAI has moved the retirement of custom GPTs from a future migration story into an active product restriction. Personal ChatGPT accounts—including Free, Go, Plus and Pro—can no longer create or publish new GPTs, while existing GPTs remain usable and can still be edited where the user’s plan and permissions allow.
The change is now stated directly in OpenAI’s official GPT creation documentation and sharing and publishing guidance. Business, Enterprise and Edu workspaces can still create, edit and publish GPTs when their workspace settings and role permissions permit it, but OpenAI is simultaneously telling creators to prepare existing workflows for migration to Plugins.
For the GPT Store, the practical consequence is significant. The personal creator pipeline that helped populate the store with new specialized assistants has been frozen. Existing GPTs have not disappeared yet, but OpenAI has formally put the format on a retirement path and is shifting the reusable workflow underneath those assistants into a different architecture.
Personal accounts can use old GPTs but cannot create new ones
OpenAI’s current documentation is explicit about the distinction between existing and new GPTs. Personal Free, Go, Plus and Pro accounts cannot create or publish new custom GPTs. GPTs those users created previously remain available for use, and editing can remain possible when the relevant plan and permissions support it.
This is not the same as the final retirement. A user may still open an existing GPT today even though the account is no longer allowed to create another one. OpenAI’s migration FAQ explicitly separates restrictions on creation and publication from the later date when existing GPTs stop running.
That distinction matters for creators with established GPT Store listings. Their existing distribution has not necessarily vanished, but the format is no longer open to the same flow of new personal-account launches.
The GPT Store has therefore entered a sunset phase before the GPT runtime itself reaches its retirement date.
Managed workspaces still have a creation path—for now
The freeze is not currently identical across every ChatGPT environment. OpenAI says Business, Enterprise and Edu workspaces can continue creating, editing and publishing GPTs according to workspace configuration and role permissions.
For organizations, however, that remaining capability exists alongside an announced migration program. OpenAI is asking affected workspaces to identify the GPTs they depend on, determine who owns them and test replacement Plugins before retirement.
This creates a temporary overlap period in which managed organizations may still be able to build or finish GPT workflows even though OpenAI has already designated Plugins as the replacement direction.
Creators should therefore treat workspace-specific notices as authoritative for their own deadlines rather than assuming that the personal-account restriction or one Enterprise date applies universally.
OpenAI recommends Plugins as the replacement architecture
OpenAI describes Plugins as a way to combine reusable instructions with connected apps so guidance can operate alongside the tools and information needed for a task. That preserves some of the core value custom GPTs provided while changing how the capability is packaged and invoked.
A custom GPT was fundamentally a named assistant that users could deliberately open, share by link or discover through the GPT Store. A Plugin is closer to a reusable capability layer that can participate in the broader ChatGPT experience.
That architectural change is why the retirement matters beyond branding. OpenAI is not merely renaming the GPT builder. It is moving creators from standalone assistant destinations toward modular instructions, apps and tools that can be composed around a task.
NetContentSEO previously examined the broader strategic implications in its analysis of OpenAI’s shift from custom GPT discovery toward Plugins. The newer personal-account restriction makes that transition tangible: one of the main entry points for creating fresh GPT Store inventory is already closed.
The migration dates are moving targets in OpenAI’s live documentation
One important complication is that OpenAI’s current Help Center pages do not present a perfectly uniform milestone schedule. The general GPT creation and sharing pages currently describe September 17, 2026 as the target for the migration experience and December 11 as the planned retirement date for affected Enterprise workspaces.
However, OpenAI’s live custom GPT retirement and migration FAQ currently lists September 22 as the target for the migration experience and user banner, October 26 as the planned end of new custom-GPT creation for affected Enterprise workspaces and December 11 as scheduled retirement.
The Enterprise and Edu release notes add another version of the intermediate schedule, listing September 17 for migration availability and September 25 for ending new GPT creation in affected Enterprise workspaces. OpenAI repeatedly warns that dates may change and tells users to follow the notices attached to their own account or workspace.
The durable facts are therefore more important than treating one intermediate date as universal: personal accounts are already blocked from creating or publishing new GPTs, affected Enterprise environments have a migration and retirement process underway, and December 11 remains the stated retirement milestone for the affected Enterprise workspaces in the current documentation.
Migration preserves the workflow, not necessarily the GPT exactly as it exists
OpenAI’s migration guidance is built around preserving useful workflows rather than reproducing every property of a GPT one-for-one. Instructions can become capabilities in a replacement Plugin, while connected apps can be incorporated into the Plugin environment.
Creators are advised to test familiar prompts after migration because the replacement may behave differently. Reference material, templates and tools also need review rather than an assumption that every element transferred perfectly.
Once a GPT is migrated, OpenAI says the original can remain usable until retirement but becomes read-only. That makes the migration event itself a handoff: ongoing maintenance moves to the Plugin rather than continuing in parallel on the old GPT.
Creators with important production workflows should therefore finish essential GPT edits before migration and treat the replacement as a new deployment that needs validation.
Custom Actions create the hardest migration problem
GPTs that mainly package instructions can be relatively straightforward to reinterpret as reusable capabilities. GPTs that depend on custom API Actions are more complicated.
OpenAI says custom Actions are not automatically transferred by the migration flow. Owners may need to rebuild the integration using supported connectors or a custom MCP server and then re-evaluate authentication, permissions and behavior.
This means the retirement is not simply an export operation for sophisticated GPTs. A creator may preserve the assistant’s instructions while still needing engineering work to reproduce the external functionality that made the GPT useful.
For businesses that built operational workflows around GPT Actions, integration inventory should therefore be as important as preserving prompts or knowledge files.
Public Enterprise GPTs are not protected by outside usage
The retirement boundary also follows ownership rather than only the plan of the person using a GPT. OpenAI’s migration guidance says public GPTs created inside affected Enterprise workspaces are included in the retirement even when they are used by people whose accounts belong to other plans.
That is important for GPT Store users because the apparent audience of a GPT does not determine whether it survives. A public assistant may have users across personal plans while its lifecycle remains controlled by the workspace in which it was created.
Organizations that published GPTs externally therefore need to consider both migration and user redirection. OpenAI expects links to migrated GPTs to direct eligible users toward the replacement Plugin, but a redirect does not itself grant access to that Plugin.
Distribution and permissions will have to be checked again on the replacement side.
The GPT Store loses its role as an open personal publishing channel
The GPT Store was built around a familiar creator-marketplace model. Individuals could package instructions, knowledge and tools into a named assistant, publish it and compete for discovery inside ChatGPT.
Blocking new personal GPT creation changes that dynamic immediately, even before old GPTs are switched off. There can still be existing listings and managed-workspace publishing, but the marketplace is no longer receiving new assistants from ordinary Free, Go, Plus and Pro creators.
That makes “sunset phase” a more accurate description than saying the GPT Store has already closed. The existing catalog can continue functioning during the transition, but OpenAI is no longer treating personal custom-GPT publishing as the forward-looking creator model.
The strategic destination is Plugins.
Discovery shifts from choosing a bot to matching a capability
Custom GPTs encouraged users to choose an assistant first and then begin the task. That made the GPT’s title, description, category, branding and store visibility important discovery surfaces.
Plugins create a more composable model. Reusable instructions and connected apps can operate within the broader ChatGPT workflow rather than requiring every specialized function to live behind a separate chatbot identity.
This potentially changes optimization inside ChatGPT. The question becomes less about persuading a user to open a named GPT and more about making a capability understandable, trustworthy and relevant when a task requires it.
For marketers and software companies, that is closer to semantic capability discovery than app-store merchandising.
The asset creators need to preserve is the workflow underneath the GPT
The personal publishing freeze makes the migration priority clearer. A creator should inventory what actually creates value inside each GPT: instructions, proprietary reference material, connected apps, custom Actions, specialized decision rules or access to external systems.
The named GPT is the wrapper. OpenAI is offering a path for some of the underlying workflow to survive in Plugin form, but the wrapper itself is scheduled to disappear.
This is especially important for creators who built an audience around a GPT Store identity. Branding may still matter for a Plugin, but the interaction model and distribution surface can change enough that simply preserving the old name will not preserve the old user journey.
Testing should therefore include not only whether the replacement answers correctly, but whether users can find it, access it and complete the same task.
The freeze turns a future deprecation into a current distribution change
OpenAI’s custom GPT retirement was already strategically important when it was announced. The new personal-account restriction makes the transition operationally immediate.
Free, Go, Plus and Pro users cannot create or publish new GPTs. Existing assistants remain available during the applicable transition period. Managed Business, Enterprise and Edu workspaces retain creation capabilities according to their permissions, but OpenAI is directing those workflows toward Plugins and has scheduled retirement for affected Enterprise environments.
The exact intermediate dates are still shifting across OpenAI’s live documentation, so creators should follow account and workspace notices rather than treating one Help Center milestone as immutable. The direction, however, is unambiguous.
The GPT Store is no longer the open-ended personal publishing platform it was designed to be. OpenAI is preserving the workflows it considers valuable while changing the unit of distribution from a standalone custom assistant to a reusable Plugin capability. The custom GPT era is not over on every account today, but the pipeline for its successor is already replacing it.