OpenAI Plans to Retire Custom GPTs. The Prompt Is the Easy Part

OpenAI announced the planned retirement of custom GPTs on September 11. September 17 is the target for the migration experience to begin reaching affected Enterprise workspaces—not the retirement date, and not proof of a universal rollout. The published Enterprise schedule then points to September 25 for the end of new GPT creation and December 11 for retirement in affected Enterprise workspaces.

The obvious reading is that GPT builders need to move a prompt into a new container. That is the smallest part of the job. A custom GPT bundled an instruction set with a dedicated entry point, knowledge, model behavior, tools, sharing rules, and an audience. Plugins separate those concerns into skills, apps or MCP tools, installation policy, and host-specific execution.

That means a technically successful conversion can still break the workflow. The package may exist while the right user cannot install it. The skill may load while the wrong conversation context changes the answer. The tool may authenticate while a write happens twice. The replacement may be private while the old GPT served people outside its originating workspace.

My thesis is simple: the unit of migration is not the GPT; it is the user–workflow pair. Treat this as a product release with acceptance evidence, not a prompt-copying exercise. The useful denominator is how many critical people can still complete their critical tasks—not how many plugin records an admin created.

Migration is complete only when the intended user can select the right workflow, with the right context and permissions, and produce an independently accepted result.

Two clocks are already being confused

The announcement clock and the rollout clock are different. OpenAI published the plan on September 11. September 17 is a target for migration availability. Any article or project plan that calls September 17 “the day custom GPTs were retired” is starting from the wrong event.

The personal-account status comes from OpenAI’s current GPT creation and editing documentation. OpenAI says the broader transition reaches all ChatGPT plans, but timing and exceptions are account-specific. Enterprise dates are therefore a planning anchor, not a universal promise.

What crosses the boundary—and what does not

OpenAI’s migration FAQ describes a built-in path for eligible Enterprise assets. The GPT must be published—even privately—and migration must be initiated by its creator or a workspace admin while plugins are enabled. Built-in migration does not require separate upload permission for plugins or custom MCP.

Notice what the table does not say: it does not promise behavioral parity. File presence is not retrieval quality. An app listed in a package is not an authorized user session. A redirected URL is not a permission grant. A skill created from instructions is not evidence that the host will select it for the same requests.

The dates and destination mappings above come from OpenAI’s product guidance; the acceptance questions do not. The next four sections are RohitAI’s analysis of what those rules mean in production. The tests and metrics are proposed practices, not OpenAI guarantees.

Context isolation was part of the product

Instructions-only GPTs are easy to dismiss as disposable prompt wrappers. That misses a quiet capability: a dedicated GPT could provide a predictable context boundary. OpenAI’s current GPT behavior documentation says a new GPT conversation does not use saved memory, account-level custom instructions, or earlier conversations. Invoking a GPT with @ inside an existing web conversation is different because that thread’s current context remains.

A reusable skill operating inside a broader host conversation can therefore fail by knowing more, not less. A blind writing critique may become gentler because the thread reveals the author’s preferences. A standardized assessment may adapt to irrelevant prior context. A compliance checklist may inherit an account instruction that changes formatting or tone. The words in the migrated instruction file can be identical while the product behavior changes.

Treat allowed context sources as an interface contract. Run at least these cases:

• Fresh thread: only the intended task and supplied artifacts are present.

• Continued thread: relevant and irrelevant earlier messages compete for attention.

• Conflicting preference: an account or thread instruction contradicts the workflow rule.

• Different user: a recipient without the creator’s history, memory, or settings runs the same case.

• Explicit versus natural invocation: compare a direct selection with an ordinary request that should activate the skill.

The last test matters because skill metadata becomes a routing interface. The Agent Skills specification loads a skill’s name and description before its full instructions. A description is therefore not merely store copy; it helps determine whether the procedure enters context at all.

Audience continuity is a database join

Artifact continuity asks whether the replacement exists. Audience continuity asks whether every dependent user can actually run it. Those are different projects.

OpenAI’s GPT sharing guidance makes the originating workspace consequential: a publicly shared GPT created in Enterprise can be used by people on other plans. A personal user can therefore inherit a retirement boundary from an organization they do not control. An inventory limited to “GPTs our workspace owns” misses the external tools employees or customers depend on.

Plugin and app controls add more joins. OpenAI’s plugin administration guide distinguishes making a plugin available from installing it for eligible members. Neither state grants access to a provider’s data. App enablement, OAuth scopes, allowed actions, and future-action policy remain separate controls.

restored_user_workflow =
  replacement_package_exists
  AND intended_user_is_eligible
  AND plugin_is_available_or_installed
  AND required_app_is_authorized
  AND routing_selects_the_skill
  AND tool_effect_matches_policy
  AND business_output_is_accepted

This is why “97 of 100 GPTs migrated” is a weak progress metric. If the three missing workflows serve the finance close, legal intake, and customer escalation teams, the project is not 97% complete. Track accepted critical user–workflow pairs divided by required critical user–workflow pairs. Weight the inventory by business impact, audience size, and rebuild lead time.

A short action can hide the largest migration

Prompt length is a poor estimator of effort. A long editorial GPT with static references may be straightforward to preserve. A two-sentence GPT that calls a production action can conceal identity mapping, authorization, input validation, approval, partial failure, idempotency, and audit requirements.

Legacy GPT actions use an OpenAPI schema plus authentication configured as none, API key, or OAuth, according to OpenAI’s actions documentation. Moving that behavior to MCP is not a file-extension change. Transport compatibility does not prove business equivalence.

OpenAI’s plugin security guidance puts input validation, authorization, and scope enforcement on the server and recommends human confirmation for irreversible operations. Instructions can explain policy; they cannot enforce provider permissions. For a deeper version of that distinction, see RohitAI’s analysis of authorized effects versus fluent task completion.

One plugin can have four release clocks

A plugin looks like one artifact in a directory. Operationally, it can be four versions moving independently: the instruction bundle, the approved tool schema, the live backend, and the workspace policy. Add the client surface and there may be a fifth.

package_version:       2.3.0
skill_snapshot:        sha256:...
approved_tool_schema:  2026-09-17.1
backend_release:       2026.09.17-4
workspace_policy:      policy-28
tested_surfaces:       [ChatGPT-web, Codex-desktop]

Current plugin packaging guidance prefers a root plugin.json, a skills directory, and optional MCP configuration. ChatGPT and Codex can share discovery while execution differs by surface; OpenAI’s plugin concepts guide notes, for example, that web installation does not deploy hook scripts.

Repository distribution adds another clock. GitHub-synced workspace marketplaces can update on a schedule, but removing a source entry does not necessarily remove the workspace copy; OpenAI documents a “No longer in source” state in its marketplace import guidance. Source control becomes a deployment authority without automatically becoming an emergency kill switch.

The practical response is a compatibility record and an owner for every plane. Test a backend roll-forward against the approved schema. Verify that a refreshed tool does not silently add a write action. Define how to disable the installed copy if a repository entry is withdrawn. “The manifest merged” is not a release receipt.

A migration plan built around evidence

Do not combine conversion, redesign, model changes, and distribution expansion in one move. Freeze a baseline, prove continuity, then optimize. Otherwise every regression has four plausible causes.

1. Inventory the workflow, not just the asset. Record the business owner, creator, source workspace, recipients, required context boundary, reference versions, apps or actions, model assumptions, expected artifact, last successful run, and acceptance owner. Include public GPTs your team uses but did not create.

2. Classify the hard part. Mark each workflow as instructions/reference-only, connected-app, custom-action, external-audience, intentionally isolated-context, or a combination. Prioritize consequential actions and broad audiences before long prompts.

3. Capture a frozen baseline. Save accessible instructions, knowledge filenames and versions, schemas, representative inputs, accepted outputs, effective model, known limitations, and external receipts. Keep credentials out of the record.

4. Build the replacement without redesigning the job. Preserve the current acceptance rubric first. Consolidate duplicate skills or rewrite the workflow only after the canary passes.

5. Test selection, execution, and denial. Include natural activation, explicit invocation, near-misses, requests that must not activate, authorized and unauthorized users, missing app access, malformed tool input, repeated writes, and partial failures.

6. Canary with a non-admin recipient. The creator’s successful run proves little about installation, entitlement, and provider authorization for everyone else. Have a real recipient execute a real case on every intended surface.

7. Cut over with an independent fallback. Do not make the read-only original your rollback plan. Define a manual procedure, alternate tool, or controlled legacy path that survives the retirement boundary.

The smallest useful acceptance matrix

For public-directory publication, OpenAI’s submission documentation requires at least five positive and three negative test cases. Treat that as an admission minimum, not a production regression suite. Your suite should reflect workflow risk, user diversity, tool consequences, and the ways a plausible request can select the wrong skill.

What each group should do now

• Affected Enterprise owners: verify whether the migration control is actually present; identify eligible published GPTs; freeze baselines; and use September 25 and December 11 as planned checkpoints, not excuses to postpone action.

• Personal-account builders: do not plan around the Enterprise September 25 cutoff. New creation and publishing are already unavailable in current personal-account documentation. Preserve accessible configurations, map dependencies, and follow the notices shown for the account.

• Business and Edu teams: use workspace-specific admin communication. Do not import the Enterprise calendar or assume identical authoring, integration, and rollout controls.

• Users of somebody else’s public GPT: record the owner and source workspace when knowable, request a replacement destination, and test your own eligibility. Your subscription alone does not define the asset’s lifecycle.

• Public GPT businesses: separate portable domain logic from audience continuity. A reusable skill can reduce rewriting while doing nothing to recreate discovery, installs, monetization, or customer contact.

The strategic read: OpenAI is making workflows administrable

OpenAI introduced GPTs in 2023 as a no-code way to combine instructions, knowledge, and capabilities. By the January 2024 GPT Store launch, the company said users had created more than three million GPTs. Its 2025 enterprise report later described strong combined GPT-and-Project use.

Those numbers show that customized workflows mattered. They do not tell us how many active workflows face this migration, how many were valuable, or why OpenAI chose retirement. Large historical totals support an inventory effort; they do not support a “millions of businesses will break” headline.

The reused word “plugin” can also mislead. OpenAI’s 2023 ChatGPT plugins beta was an earlier generation built around external-service tools. Today’s plugin package can combine reusable skill instructions with apps or MCP tools and workspace distribution. This is not simply the old beta returning under the same name.

The direction is nevertheless visible. A GPT was a destination: choose this named assistant, enter its context, and use its bundled behavior. A plugin is closer to an installable capability package that a host can discover, govern, and invoke. That can improve reuse and administration, but it moves product value away from the storefront object and toward routing, entitlements, tools, and maintenance.

This is the forced-migration version of the portability argument RohitAI made in its earlier analysis of agent plugins: files can travel while trust, permissions, and execution remain local. It also complements the GPT-5.5 retirement playbook. A model retirement asks whether every execution path has a supported model. This retirement asks whether every workflow still has its context, audience, and effects.

Three predictions worth testing

1. Enterprises will consolidate packages but preserve more context boundaries than expected. Shared skills and tools make duplicate maintenance visible. Yet blind review, regulated assessment, and role-specific permissions will keep some apparently similar workflows separate.

2. Migration services will sell entitlement reconciliation, not prompt conversion. The hard evidence lives in user access, provider scopes, routing behavior, action semantics, and external receipts. Those cannot be proven by converting text alone.

3. Workflow owners will maintain compatibility ledgers. Skill snapshots, approved schemas, backend releases, policies, and clients already move on different clocks. Early drift will make a version record as normal for agent workflows as a dependency lockfile is for software.

These are RohitAI’s interpretations, not announced OpenAI roadmap commitments. They are useful because each can be tested: count consolidation, measure access failures, and track how often schema or backend drift causes regressions.

The deadline is not the migration

September 25 and December 11 are easy dates to put on a project plan. They are not acceptance criteria.

A team can meet the calendar, convert every eligible object, and still strand users behind installation rules; contaminate a blind workflow with extra context; lose a custom action; or ship a tool whose prose claims success before the system of record changes. Conversely, a small team with a careful inventory, a frozen baseline, a recipient canary, and external receipts can finish with fewer packages and more continuity.

Custom GPTs made workflow packaging feel lightweight. Their retirement exposes what the valuable ones really were: small products with context contracts, integration contracts, distribution, permissions, and owners. Plugins give those products a more governable container. Builders still have to prove that the work survives the move.