You already have custom GPTs and Claude Projects.

§ 01

If you already have custom GPTs in ChatGPT

OpenAI’s Custom GPT retirement and migration FAQ is the source of record. Custom GPTs are scheduled to retire on December 11, 2026. After that date, custom GPTs and their GPT pages become inaccessible. Your existing conversations stay in your history. You can still migrate a GPT after retirement, but the GPT itself will not run in the gap. FedRAMP workspaces, and Enterprise workspaces with a qualifying, approved deferral, have until February 11, 2027. That later date does not apply to every workspace.

The transition affects all ChatGPT plans. Migration and plugin access may differ by account or workspace, so follow the notice in the product. What matters is where the GPT was created. If you created the GPT, you can migrate it when the option is available. In an Enterprise workspace, a workspace admin can also migrate it when plugins are enabled. Permission to use someone else’s GPT does not let you migrate it.

When migration is available, go to My GPTs and select Migrate to plugin. Migration uses the GPT’s latest published version. Drafts and unpublished edits do not transfer. Publishing a GPT does not require making it public.

1. Inventory every GPT you still rely on: owner, users, publish status, files, apps, and custom actions.
2. Finish essential edits and publish. Public sharing is not required.
3. Save a few familiar prompts and one harder case so you can compare the replacement.
4. Migrate to a plugin, then review the new skill and the reference files.
5. Rebuild any custom actions, and test that integration on its own.
6. Share the plugin. It starts private. Existing users do not get access automatically.
7. Ask one real user to install and test it before everyone switches.

Our honest take

A printable version of these steps is on Appearly’s custom GPT migration checklist.

§ 02

What transfers from a custom GPT, and what does not?

After you migrate, the original GPT stays usable until retirement, but it becomes read-only and its creator cannot delete it. Future changes belong on the plugin. OpenAI also warns that a migrated plugin may respond differently, so you should compare familiar prompts and at least one harder case before people switch.

If you used a GPT mainly to keep instructions and files together for your own writing, research, or planning, OpenAI says a Project can be a good fit. Existing chats cannot be moved into the project, and a project does not carry custom actions or sharing settings. See Appearly’s custom GPT vs Project vs plugin page.

§ 03

If you already have Claude Projects

Claude Projects are self-contained workspaces with their own chat histories and knowledge bases. You can upload documents, set project instructions, and have focused chats inside that project. They are available on all Claude plans, with a limit of five projects on the Free plan. On Team and Enterprise, projects can be shared with view or edit access.

A Project is the right home for background knowledge. It is not the best home for a procedure that should run the same way in many chats, for many people. Anthropic’s comparison is that projects hold static background knowledge for chats in the project, while skills are procedures that load when needed and work more broadly. Connectors, not project files, are how Claude should reach a CRM or a finance system.

If your team already has a useful Project, keep it. Then ask whether a recurring job inside it should become a Skill, and whether the assistant is still depending on someone pasting data that a connector should be reading instead. On Team and Enterprise, an owner can provision approved skills so people do not each upload their own copy. Anthropic is also rolling out a new version of projects in beta; if your projects are moved, Anthropic says nothing is deleted.

§ 04

If you have already started skills, connectors, or Copilot agents

A lot of teams are in the middle: a GPT that almost works, a Project full of files, or a connector that is unreliable. Finish that work in the current products, rather than starting over.

If the missing piece is a repeatable procedure, turn the instructions you already have into a skill and share it. If the missing piece is access to a system, add a directory connector where one exists, or a custom MCP server where it does not. That is also the path for GPT custom actions that will not survive migration. If the missing piece is reliability, save a few test prompts and fix the skill or connector until those prompts match the system of record, then share it.

If the work lives in Microsoft 365, decide whether Agent Builder is enough or whether the agent needs Copilot Studio for connectors, workflows, or approvals, and have an admin publish it only after it has been tested. Do not run two official versions of the same workflow in parallel for long. Pick the replacement, test it, share it, and tell people when to switch.

§ 05

What order should you do the work in?

1. List what people still use: GPTs, Projects, skills, connectors, and Copilot agents, including the owner, users, systems, and whether anything writes or sends.
2. Separate knowledge from procedure from access. Files and context can stay in a Project, in reference files, or in Company Knowledge on eligible ChatGPT plans. Procedures become skills. Systems become connectors or apps.
3. Migrate or rebuild the ChatGPT GPTs you rely on first if they have a deadline. Simple instruction-and-file GPTs are faster. Anything with custom actions may need a custom MCP server, so start those now, not in December.
4. Promote the Claude work that has outgrown a single Project into Skills, and add connectors for systems people are still copying from by hand.
5. Test with one real user and one awkward case. Then share the replacement and retire the old path.

§ FAQ

Questions we hear