Custom GPTs Stop Running on December 11. OpenAI Wrote the Checklist. Your Inventory Is Missing.

“Custom GPTs stop running.” That is how OpenAI’s help center describes December 11, 2026, the scheduled retirement date for the custom GPTs the FAQ covers. The same FAQ dates the rest of the sequence: an admin notice on September 11, a migration target on September 17 (“a target, not a guarantee”), and a planned end to the creation of new custom GPTs on September 25. Every date carries the same qualifier: “the dates are subject to change.”

I read the page the way I read Microsoft’s agent code of conduct: clause by clause, asking what each one forces an enterprise to do. The answer is that this is the first scheduled retirement of a class of user-built agent artifact that I have seen documented, and the retirement document is also the clearest lifecycle-governance text for agents I have read from a vendor. Dated cutoffs. Migration restricted to the creator or an admin. Two separate grants for sharing and publishing. Integrations that do not transfer and have to be assessed and rebuilt. A behaviour test before rollout. A redirect that grants no access.

If your organisation let staff build GPTs, you now have an inventory problem, a permissions problem and an integration problem, on a clock of roughly twelve weeks from today.

What migrates, and what silently does not

The FAQ describes the migration result in two sentences: “the GPT’s instructions become a skill within the new plugin. Connected apps are added to the plugin as apps.” Reference files carry over but must be reviewed.

Then the list of what does not travel. The GPT’s selected model does not carry over; in Enterprise workspaces, Enterprise defaults apply. Conversation starters and previous chats “may not copy.” And the line that turns a migration into a rebuild project:

“GPT custom actions do not transfer through the migration workflow. The person maintaining the workflow will need to assess and rebuild required integrations using a supported connector or custom MCP server.”

Custom actions are where a GPT touched a system outside the chat: an internal API or a ticketing tool. Those calls were configured by whoever built the GPT, and in the deployments I have seen that happened without an engineering review, and the FAQ assigns the rebuild to “the person maintaining the workflow.” In most companies I work with, nobody holds that title. The GPT has a creator, who may have changed teams, and users, who have no idea which actions it calls.

The FAQ then sets the expectation for the rebuilt version: “A rebuilt integration should not be assumed to provide every capability of the original action.” The vendor is telling you, in writing, that parity is not promised. That is honest and it is also the reason the integration list has to exist before December.

Who is allowed to migrate

Only a GPT’s creator or a workspace admin can migrate it, and only when two conditions hold: plugins are enabled in the workspace, and the GPT is published. Drafts cannot migrate. Publishing requires no public sharing, so an unshared draft that a team quietly depends on has to be published before it can be moved.

The clause I would pin to the wall is this one: “Permission to use someone else’s GPT does not give you permission to migrate it.”

Usage and ownership are separated. A department that runs its daily work through a GPT built by a contractor who left has no path to migrate it themselves; an admin has to do it. Multiply that by every GPT in a large workspace and the admin queue is the bottleneck of the whole programme.

Scope follows creation, not consumption: “Public GPTs created in affected Enterprise workspaces are included in the Enterprise transition, even if you access them from a personal account or another workspace. What matters is where the GPT was created.” An inventory built from what people use will miss GPTs created elsewhere, and an inventory built from what the workspace created will include GPTs nobody inside it still uses.

Two grants, and a policy on top

The permission model after migration is more granular than the one the customers I work with ran for GPTs. Two separate admin permissions govern distribution: “Share plugins,” which covers people and groups, and “Publish plugins to workspace,” which covers the directory. Using a migrated plugin requires a third thing, the “Use plugins” permission, plus a workspace policy that permits it. The built-in migration does not require “Upload plugins” or the custom-MCP permission.

This matters for the rollout plan because a migration that succeeds technically can still leave the plugin invisible to its former users until someone grants the right combination. The admin who migrates and the admin who publishes may be different people, and the policy that permits plugin use may not exist yet.

We covered the review gate that a skill should pass in the piece on agent skills in eight languages. The migrated GPT’s instructions arrive as something the vendor also calls a skill, inside a plugin, so whatever review your organisation applies to skills now applies to every migrated GPT. Zero review for skills means zero review for the migration.

Test before rollout, because behaviour changes

The FAQ says the migrated plugin “may respond differently,” and prescribes the minimum test: run “a familiar prompt” and “at least one harder case” before wider rollout.

Two facts on the page are, in my reading, enough to explain why the behaviour changes. The selected model stays behind, so a GPT tuned against one model now runs on the workspace default. And the custom actions are gone until rebuilt, so any answer that depended on a live call now comes from the instructions alone. The prescribed test is small. The point is that the vendor is asking for one, and that a “migrated” status without a recorded test result is an unverified claim.

The redirect that grants no access

After migration, the original GPT becomes read-only but “remains usable until retirement.” At retirement, links are “planned to redirect to the replacement for people who have access.” Then the sentence that matters for support tickets in December: “A redirect does not grant access to the plugin.”

Every bookmark and every internal wiki link that points at a GPT will resolve to the plugin only for people who were granted access under the new model. Everyone else lands on a redirect that goes nowhere useful. The access grant has to be done by someone holding “Share plugins” or “Publish plugins to workspace”, and the users still need “Use plugins”.

What this is, beyond one vendor

We wrote about the risk of a vendor kill switch a government can hold in the model availability piece. This is a different risk. It is scheduled, and it comes with a checklist. Nothing here is a surprise; the surprise is only that most of the customers I see cannot execute the checklist because the three prerequisites were never built:

1. An inventory of every GPT created in the workspace, including the ones used from personal accounts and other workspaces.
2. A named owner per artifact, someone who can run the migration or is authorised to ask an admin to.
3. A record of which custom actions each GPT calls, and which system on the other end of each call.

Those three deficits are not specific to GPTs. I expect skills, plugins and agents from every vendor to get the same treatment: a creation cutoff, a migration window, a retirement date, and a migration path that carries the instructions and drops the integrations. The FAQ is a template for the lifecycle of any agent artifact class, and the enterprise controls it assumes are the same in each case.

Do this now: build the inventory the FAQ assumes you have

Start this week, with the December 11 date in the calendar and the reminder that OpenAI says it can move.

1. Pull the list of every published and draft GPT created in your Enterprise workspace. Creation location is the scope rule, so filter on the workspace that created it rather than on the people who use it.
2. For each one, name the creator and check whether the creator is still in the organisation. Where the creator is gone, assign an admin now, because “permission to use” is not permission to migrate.
3. Open each GPT’s configuration and list its custom actions, with the target system for each. That list is the security review backlog, and the FAQ says the integrations you still need have to be rebuilt through a supported connector or a custom MCP server.
4. Decide, per GPT, whether it migrates, gets rebuilt from scratch, or is allowed to stop running on December 11. Some GPTs deserve no rebuild.
5. For the ones that migrate: publish drafts first, migrate, run the familiar prompt and the harder case, record the result, and only then share the plugin with the people or groups who need it, or publish it to the workspace directory, and confirm they hold “Use plugins” under a policy that permits it.
6. Keep the inventory after December. The next artifact class will, I expect, get a retirement FAQ of its own, and the organisations that finish this one on time are the ones that already had the list.

The vendor wrote a good lifecycle document. Its every clause assumes an enterprise that already holds the inventory and the owner list. Most do not, and the twelve weeks are for finding out.

---

This analysis synthesizes Custom GPT retirement and migration FAQ (OpenAI, September 2026). All dates on the page are stated as subject to change; quotations are from the page as read on September 18, 2026.

Victorino Group helps enterprises inventory their agent artifacts, assign owners and review integrations before a vendor retirement date does it for them. Let’s talk.