How to migrate custom GPTs to plugins: a practical guide

Take stock

List every GPT your team actually uses. Record its name and link, account or workspace where it was created, business task, owner and users. Separate your own GPTs from other providers’ applications.

Describe the impact of an outage in one sentence: what work would stop, who would be affected and is there a manual alternative? Use this to set a priority, such as high for a daily workflow with no fallback.

Keep a few familiar prompts and their expected results as a test baseline. Use anonymised example data. Record unresolved questions and your intended switch date in the checklist.

Prepare your GPT for migration

Open each GPT you own in the correct account. Read its instructions, check that knowledge files are current and decide which content is still needed. Record existing sharing settings and users.

Finish essential changes and publish the version you want to migrate. Drafts do not transfer, but publishing does not require public sharing. Check your workspace notice for any creation cutoff.

Document the chosen version and any gaps. After migration, the original GPT becomes read-only. Make subsequent changes to the plugin.

Review integrations

Record each connection to an external system: which data does it read, which records does it change and which account does it use? Custom actions are individually configured calls to external interfaces. They are not transferred automatically during migration.

For each custom action, check whether an available app supports the tasks you need. Otherwise, you may need a custom MCP server, a technical service that gives an AI system access to defined tools and data. Availability, permissions and setup need a separate review.

For each replacement, record supported and missing capabilities, the owner and a test with no real business impact. A rebuilt connection may have a different scope. Even transferred apps still need their own access permissions and may require sign-in.

Run the migration

Sign in to the account or workspace where the GPT was created. Check the notice, plugin availability and your permissions. The creator can migrate it; in Enterprise, a workspace administrator can also do so when access is enabled. Simply using someone else’s GPT does not let you migrate it.

Open My GPTs. Choose Migrate to plugin for the relevant GPT once the option is available. Read the migration details and follow the steps to create the plugin. If the option is missing, use the troubleshooting checks below.

Review the transferred content: GPT instructions become a skill, a reusable set of working instructions. Knowledge files become reference files, and connected apps are added to the plugin. Custom actions and the previous model selection do not transfer. Enterprise model defaults apply in Enterprise workspaces.

The new plugin starts private. Migration does not install it automatically or copy existing sharing settings. The original GPT remains usable until its applicable retirement date but becomes read-only. Built-in Enterprise migration does not require Upload plugins or Upload plugins with custom MCP servers; building a separate integration may need additional permissions.

Test the workflow

Run the same tasks with anonymised data through the existing GPT and the replacement. Include typical cases and at least one difficult case with missing or conflicting information. Define what an acceptable result must contain before testing.

Check that the right skill is used, instructions are followed, reference files inform the output and answers or files have the required format. Different wording may be acceptable; invented facts, missing required information or incorrect data changes are not.

Test connections separately using test data and minimal permissions. For write access, verify the actual record changed and check for unwanted side effects. Record the test date, result, defect and correction; rerun failed cases after fixing them.

Help your team switch

Share the tested plugin with its intended users and ask one of them to check access. In Enterprise, Share plugins for people or groups and Publish plugins to workspace for the workspace directory are separate permissions. Making a personal plugin public requires a separate submission process.

In the intended account, open the plugin directory, select the plugin, review its included apps and choose Install plugin if shown. If prompted, select Connect and sign in to the correct provider account. Some apps need no individual sign-in or use an administrator-configured connection. A Desktop only label means the desktop app is required.

In Enterprise, check Use plugins permission and a policy that allows installation or installs the plugin automatically. Installation, plugin sharing and app permissions are separate requirements. They do not extend access to data in the connected system.

Ask a team member to complete a familiar task using suitable test data. In ChatGPT, an installed plugin can be selected through an @ mention or the available composer options. Depending on the interface, these are labelled +, More or Plugins; in a supported Codex task view, use Sources → Use plugins. Automatic skill selection will not necessarily happen for every request.

Update internal links and short working instructions. Assign an owner for maintenance and issues, agree a switch date and check actual use afterwards. If a critical test remains unresolved, use the agreed fallback and record the decision.