The migration nobody explained clearly enough
So, OpenAI is retiring custom GPTs. Not “maybe,” not “eventually.” Plugins are taking over, and every GPT you built or leaned on is getting swept into that transition whether you asked for it or not. If you’ve got a GPT quietly doing work for you right now, the clock started moving weeks ago.
Here’s the version without the corporate fog. What’s changing, when it changes, and what you actually need to do about it.
Does this touch every ChatGPT plan, or just Enterprise?
Every ChatGPT plan is affected. Enterprise workspaces have the clearest published timeline right now, but personal accounts are riding the same wave through in-product notices. If you built a public GPT inside an Enterprise workspace, it’s swept into that workspace’s migration even if you personally access it from a completely different account or plan.
That last part trips people up. The plan you’re logged into doesn’t decide your GPT’s fate. Where it was created does. If you rely on a public GPT someone else built, check for a notice on the GPT itself and follow whatever its creator says, because your access to the original never guaranteed you access to whatever replaces it.
Has your GPT already disappeared?
No. This announcement is a runway, not a cutoff. Existing GPTs keep working right up to the scheduled retirement date, as long as their current access and workspace permissions stay intact. Once a GPT gets migrated, the original sticks around in read-only mode until retirement, so finish any edits you need before you migrate it.
That read-only detail matters more than it sounds. Once you migrate, you’re not editing the GPT anymore. You’re editing the plugin. Anything you meant to fix in the original needs fixing before that switch happens.
What are the actual dates on the calendar
Four dates matter here, and three of them are either already behind us or days away as of this week. September 11 was the notice sent to Enterprise admins. September 17 was the target date for the migration experience and the user-facing banner to show up, though that was a goal rather than a guarantee for every single workspace.
September 25 is the one to circle. That’s the planned cutoff for creating new custom GPTs. Any draft you’ve been meaning to publish and migrate needs to go live before then, and publishing doesn’t mean making it public, it just means moving it out of draft status.
December 11 is the real deadline. Custom GPTs are scheduled to stop functioning entirely on that date. Other plans are expected to follow a similar arc, coordinated with the Enterprise rollout through in-product announcements, but that’s not a promise migration lands for every account on the same day.
What should you actually be doing right now
Start now, even without a migration button in front of you. List out which GPTs you actually use, who built each one, and who else on your team needs access to whatever replaces them. Write down the instructions, reference files, connected tools, and a handful of your normal prompts so you have something concrete to test the migrated version against.
If any of your GPTs run custom actions, give yourself extra runway. Those integrations don’t carry over automatically, and rebuilding one takes real time.
And if the migrate button isn’t showing up yet, that’s not automatically a problem. Enterprise migration was only targeting September 17, so its absence before that could just mean timing. It can also mean plugins aren’t enabled for your account, or you’re neither the GPT’s creator nor a workspace admin. Using someone else’s GPT never hands you the right to migrate it. In an Enterprise workspace, your admin can confirm whether plugins are switched on and whether the GPT is actually published.
Who can migrate a GPT, and how do you kick it off
A GPT’s creator or a workspace admin can migrate it, once migration is live and plugins are enabled for that workspace. The GPT has to be published first. Drafts can’t move directly, though publishing doesn’t require sharing anything publicly. Built-in migration doesn’t need the upload-plugin permissions either, since rebuilding a custom integration is treated as a separate task.
Once migration is available, open your published GPT and use its migration button, or ask your workspace admin to run it for you. Test the plugin it produces before you tell anyone else to use it, and check its sharing settings while you’re in there. Personal accounts follow whatever the in-product notice tells you, since the flow isn’t identical to Enterprise.
What carries over, and what you’ll have to rebuild
The GPT’s instructions become a skill living inside the new plugin. Any connected apps come along as apps within that plugin. Go through the migrated reference files, templates, examples, and tools before you trust the replacement, because conversation starters and prior chat history may not make the jump, and the model you’d originally chosen doesn’t transfer either.
Custom actions are the part that won’t move on their own. Whoever owns the migration has to evaluate and rebuild those integrations using a supported connector or a custom MCP server. Loop in whatever technical or security review your integration normally requires, and test the rebuilt version properly. A rebuilt integration matching every capability of the original action isn’t something to assume.
Will the plugin actually behave like your GPT did
Expect some drift. A migrated plugin can respond differently from the GPT it replaced, so run your usual prompts through it plus at least one genuinely complex case before rolling it out more broadly. Confirm it’s picking the right skill and following your instructions, pulling from the reference material you expect, producing complete output in the right format, and has every tool the workflow actually needs.
Fix whatever’s off before you point your whole team at it. A quiet mismatch in output format is the kind of thing nobody notices until a client does.
What happens to the original, and who gets the plugin
The original GPT stays usable until retirement, but it flips to read-only right after migration and its creator loses the ability to delete it. Any future changes belong on the plugin side now. At retirement, custom GPTs stop working and drop out of the GPT directory, and links to migrated GPTs are planned to redirect people to the replacement, though a redirect by itself doesn’t grant anyone access.
Access doesn’t transfer automatically either. The replacement plugin starts out private, so test and confirm it works before sharing it with anyone. Once you do share it, whoever’s using it still needs to install and test it themselves. Inside an Enterprise workspace, sharing with specific people or groups requires a separate permission from publishing into the workspace directory, so check both if you’re rolling this out to a team.
How do you actually use the migrated replacement
Once the plugin is installed and available to you, pick it (or the skill inside it) for whatever task you’re running. In ChatGPT, that means an @ mention or opening the plus menu and selecting more, wherever that’s supported for your account.
ChatGPT can also pull in an installed skill on its own, when the skill’s description matches what you asked for closely enough. That auto-selection isn’t guaranteed on every request. It depends on the task and on what’s actually available to your account, so don’t build a workflow that assumes it’ll fire every single time.
If you’ve been putting this off because it felt like one more platform update to track, this is the update actually worth tracking. December 11 arrives faster than it sounds.
