Custom GPT Migration to Plugins: Move the Workflow, Not Just the Instructions

Custom GPT migration to plugins is a workflow handoff

To migrate a custom GPT to a plugin, preserve the workflow contract before copying anything. Record what the GPT is for, which evidence it relies on, which behavior matters, which integrations it uses, and who should have access. Then separate what OpenAI migrates from what the owner must rebuild, test, and authorize.

OpenAI announced the custom GPT transition in its September 11 ChatGPT release notes. OpenAI says the transition affects all ChatGPT plans, but timing and availability may differ by account or workspace, so follow the notices shown there. A general announcement is not proof that a particular migration control is already available in every account.

OpenAI schedules custom GPT retirement for December 11, 2026, subject to the applicable notice. Treat that date as a planning boundary, not a reason to rush an untested replacement into use. The useful work is to make the old workflow legible enough that the new one can be evaluated before the handoff becomes irreversible.

Start from the latest published GPT, not the editor

OpenAI’s migration FAQ defines the source that moves. Migration uses the latest published GPT; drafts and unpublished edits do not transfer. Permission to use someone else’s GPT does not grant permission to migrate it; migration is performed by the GPT creator or an eligible Enterprise admin with the required access. Before migrating, compare the published version with the editor and either publish an intentional update through the normal review path or record the excluded draft separately. Do not assume work visible to one editor is part of the migration snapshot.

Create a short workflow contract from the published GPT: purpose, intended users, allowed tasks, required evidence, output structure, refusal or escalation boundaries, connected resources, and a small prompt set that represents normal use. This is editorial documentation, not an export format or compatibility proof. Its purpose is to make later differences observable.

The original GPT remains usable until retirement, but becomes read-only after migration. Capture ownership, the last published state, excluded drafts, open issues, and the migration date before relying on the original as a reference. Read-only availability can support comparison; it does not preserve an editable fallback.

Separate what carries from what must be rebuilt

OpenAI describes a specific mapping for migrated content. Instructions become a skill, knowledge files become reference files, and connected apps are added as apps. Those mappings carry important inputs forward, but a new container can change how the complete workflow behaves. Preserve the purpose and evidence around each input instead of checking only that a file or instruction block exists.

The selected model, existing conversations, custom actions, and sharing or access settings do not transfer automatically. Put each exclusion on a Rebuild list with an owner and decision. A selected model needs a new choice. Existing conversations remain historical context rather than migrated plugin state. Custom actions need a separately supported integration path. Sharing and access need a new handoff.

Use the matrix literally. Carry records the latest published purpose, instructions, knowledge, connected apps, and evidence boundaries. Rebuild holds every excluded setting or dependency. Recheck covers behavior, app calls, source use, and permissions. Retire covers the private replacement, owner communication, original read-only state, and final switch decision.

Test behavior and integrations as separate claims

OpenAI’s plugin guidance explains how plugins use skills, reference files, and apps. A mapped instruction set and file collection do not establish behavioral equivalence. Rebuilt integrations need separate testing, and the plugin may respond differently, so compare familiar prompts plus one harder case.

Choose two or three familiar prompts that exercise the central workflow and one harder case that tests ambiguity, missing evidence, conflicting instructions, or a permission boundary. Compare the response structure, use of reference material, uncertainty language, refusal behavior, and whether the workflow asks for the same missing information. Record material differences rather than polishing only the most visible answer.

Test each rebuilt integration on its own before using it inside the full workflow. Confirm what data is requested, which account or workspace authorizes it, what happens when authorization is missing, and how failure is communicated. A successful text response does not prove that an app call, custom-action replacement, or provider permission works safely end to end.

Treat installation, sharing, and authorization as a new access handoff

The migrated replacement starts private, and installation, sharing, access, and authorization remain separate decisions. Private is the correct starting point for comparison: it gives the owner space to verify the workflow before choosing who should install or use it. It does not reproduce the original GPT’s audience.

Installing a plugin never bypasses provider or workspace permissions. An installed plugin can still require app authorization, account access, or workspace approval, and different users may encounter different permission states. Test with the intended access model rather than using the owner’s successful authorization as proof for everyone else.

OpenAI’s GPT guidance distinguishes building, editing, and sharing GPTs. Use the old sharing record as an input, not as an instruction to recreate every grant. Confirm the current owner, intended users, minimum required access, sensitive reference files, connected providers, and removal path before opening the replacement beyond the migration reviewer.

Switch after the replacement passes a bounded release gate

Migration is ready for a switch when the published workflow contract is present, exclusions have owners, representative prompts have been compared, integrations have been tested separately, and the intended users can complete the required authorization. Record unresolved differences and decide whether each one is acceptable, blocking, or intentionally removed.

The reusable AI workflows guide asks whether a repeated workflow is stable enough to package as a skill. This migration starts later: an existing custom GPT already carries instructions, files, integrations, and user expectations, so the job is to preserve its purpose while rebuilding the parts the new format does not inherit.

Keep migration approval separate from external release authority. The AI agent creator publishing release gate governs whether an automated workflow may take a public action; this migration record governs whether the replacement faithfully and safely carries the internal workflow. A plugin that passes migration testing still does not gain authority to publish, share, or act externally.

Close the handoff with one record: source GPT and latest published date, excluded drafts, Carry / Rebuild / Recheck / Retire decisions, test prompts and observed differences, integration and permission owners, private replacement state, intended access, applicable retirement notice, and final approver. The goal is not a perfect copy. It is a replacement whose differences, dependencies, and access are understood before the original is retired.