Short answer: OpenAI is planning to retire Custom GPTs and is steering reusable workflows toward Plugins. For affected Enterprise workspaces, OpenAI currently lists a September 17, 2026 target for the migration experience, a planned September 25 end to creating new Custom GPTs, and a scheduled December 11 retirement. Those are planned dates, not a universal guarantee for every plan or workspace. The practical task for a marketing team is to inventory each GPT, preserve its working inputs, identify custom actions that will not transfer, and test the replacement before sharing it widely.
OpenAI’s Custom GPT retirement and migration FAQ says the transition affects all ChatGPT plans, while the detailed timetable and admin guidance currently describe Enterprise workspaces. If your team uses personal accounts, Business, Enterprise or Edu, follow the notice shown for the account or workspace that created the GPT. A public GPT created in an affected Enterprise workspace can be in scope even when another person opens it from a different account.
The dates to put on your migration board
| Date | What OpenAI currently says | What a marketer should do |
|---|---|---|
| September 11, 2026 | Administrator notice for affected Enterprise workspaces. | Find the workspace owner, creator and operational users for each GPT. |
| September 17, 2026 | Target for the migration experience and user banner. OpenAI says this is a target, not a guarantee that the option is available in every workspace. | Check the product surface and workspace notice; do not treat a missing button as proof that the GPT is broken. |
| September 25, 2026 (planned) | Creation of new Custom GPTs ends for the affected Enterprise flow. Existing GPTs remain usable until retirement. | Publish any draft GPT you need to migrate, if your workspace policy allows it. Publishing does not require public sharing. |
| December 11, 2026 | Scheduled retirement for the documented Enterprise transition. Custom GPTs are scheduled to stop running. | Finish validation, sharing and ownership handoff before this date; keep a human fallback for important work. |
OpenAI says the dates may change and that other plans may follow the same transition timeline without a promise that they will. Keep the notice, workspace and plan beside every date in your internal tracker. A date copied into a generic calendar without its scope is not enough evidence for a production cutover.
What will transfer, what needs review, and what will not transfer
The word “migration” can make this sound like a rename. The documentation describes a change in the unit of reuse: instructions become a Skill inside a Plugin, while connected apps become app components subject to their own authorization and workspace rules. The result may be useful, but it is not automatically behavior-equivalent to the old GPT.
| Custom GPT component | OpenAI’s documented direction | Marketer’s control point |
|---|---|---|
| Instructions | Become a Skill in the replacement Plugin under the planned workflow. | Save the current instructions and compare the migrated Skill against the original acceptance criteria. |
| Connected apps | Are added to the Plugin as apps. | Recheck provider account, role access, workspace availability, actions and approvals. Installation does not bypass those permissions. |
| Reference files, templates, examples and tools | Need review after migration. | Record file names, versions, owners and the output each file is meant to support. |
| Conversation starters and previous chats | May not copy. | Turn the important prompts and examples into a small test set before migrating. |
| Selected model | Does not carry over; Enterprise defaults apply in the planned flow. | Record model-sensitive quality requirements and retest tone, reasoning and format. |
| Custom actions | Do not transfer through the built-in migration workflow. | Map each action to a supported connector or custom MCP rebuild, then review scopes and failure handling. |
| Sharing | The replacement Plugin starts private. | Test first, then choose invited users, workspace link or directory publication according to policy. |
That last row matters for a marketing operation. A user who could run the old GPT may not have the role needed to migrate it, share the replacement or authorize an app. OpenAI says the creator or a workspace administrator can migrate a published GPT in the planned Enterprise flow; permission to use someone else’s GPT is not permission to migrate it.
A seven-step inventory and migration checklist
1. List the GPTs that do real work
Start with the workflows people rely on, not the GPT names people remember. For each one, record its creator, workspace, users, purpose, source files, connected apps, custom actions, expected output and the date of the last human review. Add a simple risk label: disposable experiment, useful individual shortcut, shared team workflow or business-critical process.
For a content team, “campaign brief writer” is not enough. Record whether the GPT reads a brand guide, creates a table, cites a source, uses a spreadsheet app or sends anything to another system. The inventory is your recovery document if the replacement behaves differently.
2. Preserve the inputs before you change the GPT
Save the instruction text, reference-file names, examples, templates, connected-app list, action definitions and a few familiar prompts in an access-controlled location. Do not paste customer data or secret credentials into a public migration document. Record the intended output format, not only the input prompt: a JSON object, a campaign table, a WordPress-ready draft and a plain-language answer have different acceptance checks.
3. Resolve ownership and publish status
OpenAI says the planned Enterprise migration requires a published GPT; a draft cannot be migrated directly. Publishing does not require public sharing, but your workspace may still restrict who can publish or use Plugins. If the creator has left the team, resolve the owner or workspace-admin path now. A user who only has run permission cannot silently take over migration.
4. Separate app access from Plugin access
The companion Plugins in ChatGPT and Codex documentation distinguishes the Plugin from the apps it contains. A Plugin can package Skills, connected apps and app templates, but the provider account, workspace role, supported actions, approval rules and sync settings remain separate checks. The admin controls and compliance guide also distinguishes an installation policy of Available from Installed.
Make a small permission map before migration:
- Who may install or use the Plugin? Check the workspace and role.
- Which app can it access? Check the provider account, domain and source permissions.
- Which actions are allowed? Separate read actions, write actions and future-action policy.
- Who approves a consequential action? Keep human approval where a workflow changes a campaign, customer record or publication.
5. Treat every custom action as a rebuild project
OpenAI explicitly says custom GPT actions do not transfer through the built-in migration workflow. The replacement may need a supported connector or a custom MCP server, and OpenAI cautions that a rebuilt integration should not be assumed to offer every capability of the original action.
For each action, choose one of four outcomes: retire it because nobody uses it, replace it with a supported app, rebuild it with a scoped integration, or keep the old workflow only until a human-owned fallback exists. Record what data it reads, what it writes, whose account authorizes it and how a failed call is detected. “The button still appears” is not an integration test.
6. Test the replacement with a small, repeatable set
OpenAI recommends comparing familiar prompts and at least one harder case. A marketer can make that concrete with four proposed tests:
| Test | Example | Pass condition |
|---|---|---|
| Familiar task | Turn a supplied campaign brief into the team’s normal channel plan. | The required sections, tone and decision fields are present. |
| Hard case | Give an incomplete brief with a conflicting audience or budget instruction. | The Plugin asks for the missing decision or flags the conflict instead of inventing a choice. |
| Reference check | Ask for a fact that exists in the approved brand or product file. | The replacement uses the intended reference material and makes uncertainty visible. |
| Tool and format check | Request the usual spreadsheet, JSON or document output and invoke the required app if authorized. | The expected file/format is produced, the correct app is used, and no unapproved write occurs. |
This is a proposed test plan, not a measured migration result. Save the before-and-after outputs, reviewer notes, date, workspace and Plugin version so a later change can be distinguished from a migration defect.
7. Roll out in stages and keep a fallback
Keep the replacement private while the creator and one representative user test it. Then share it with a small group, ask an intended user to install and test it, and only then publish it to a workspace directory if the team needs discovery. For a business-critical workflow, keep the preserved instruction set, source files and manual procedure available until the replacement has passed its checks.
A worked example for a marketing team
Suppose a team uses a Custom GPT to turn a product brief into a launch-page outline. It reads a brand guide, checks a connected drive folder and returns a fixed table with audience, promise, proof, risks and next actions. The inventory should say that the instructions are reusable, the brand guide is a reference dependency, the drive connection needs authorization, and the table is an output contract.
The migration decision is then clearer:
- Preserve the instruction and the exact table example.
- Confirm the brand-guide source and whether the replacement app can read it under the team’s role.
- Check that the original creator or workspace admin can migrate the published GPT.
- Run one normal brief, one incomplete brief, one outdated-source brief and one requested table export.
- Keep human review before a page is published or a campaign is changed.
Nothing in that example proves a migrated Plugin will produce the same answer. It is a practical acceptance plan built from OpenAI’s documented transfer limits and testing guidance.
Common mistakes to avoid
- Using the Enterprise dates as a universal promise. The FAQ gives the detailed timetable for affected Enterprise workspaces and says other plans may differ.
- Assuming a public GPT is owned by every user who can open it. Migration rights depend on the creator/admin path and the workspace.
- Calling a migrated Plugin equivalent before testing it. Model selection, chats, custom actions and some supporting material may not carry over.
- Treating a connected app as automatically authorized. Plugin installation, app access, provider consent and action approvals are separate controls.
- Publishing the replacement before a private test. OpenAI says the replacement starts private; use that boundary to review it.
Frequently asked questions
Are Custom GPTs already gone?
No. OpenAI says existing GPTs remain usable until the retirement date, subject to their current access and workspace permissions. A migrated GPT becomes read-only after migration but remains usable until retirement.
Do I need to make my GPT public before migrating it?
Not according to the planned Enterprise guidance. The GPT must be published, but OpenAI says public sharing is not required. Your workspace’s own policy may still control who can publish or migrate it.
Will custom actions move to the Plugin?
No. OpenAI says custom actions do not transfer through the migration workflow. Plan a supported connector or custom MCP rebuild, then review permissions and test the new integration separately.
Will everyone who used the GPT get the replacement?
Not automatically. The replacement starts private, and access depends on Plugin sharing, workspace role, app availability, provider authorization and any required approvals. A redirect, where planned, does not grant access to someone who lacks access to the replacement.
What should I do if the migration option is missing?
Do not infer a failure from a missing option before the target date. OpenAI says availability may roll out unevenly. Check the account or workspace notice, confirm the GPT is published, and ask the creator or administrator to verify Plugin availability and permissions.
Official sources and related DMT guides
- OpenAI Help Center: Custom GPT retirement and migration FAQ
- OpenAI Help Center: Plugins in ChatGPT and Codex
- OpenAI Help Center: Admin controls, security, and compliance for Plugins and apps
- DMT: How to Build an OpenAI Agent Plugin with Skills and MCP
- DMT: ChatGPT Sites workflow boundaries for marketers
- DMT: ChatGPT app-permission approval checklist
