| Highlights: |
|
I have a few custom GPTs that I have built for different jobs. One follows a specific writing process so I don’t have to explain the same instructions every time, and another has reference material loaded into it so I can ask questions about a particular topic. You could easily imagine others built as an HR help desk, a proposal writer, or a reporting assistant.
If you use custom GPTs in the same way, there’s an expiration date to think about.
OpenAI announced on September 11 that it plans to retire custom GPTs across ChatGPT plans. Its current Help Center guidance says they are scheduled to stop running on December 11, 2026, although users should follow the specific notice for their account or workspace in case their timeline differs.
The good news is that OpenAI isn’t saying creators have to rebuild everything from zero. A migration process is being introduced. The slightly more complicated part is understanding what your GPT becomes afterward.
That’s because a custom GPT currently does several jobs at once. It can hold instructions, store reference files, connect to outside systems, provide a dedicated place to work, and in some cases perform actions. OpenAI is beginning to separate those jobs into different pieces.
OpenAI's planned migration moves custom GPTs into what it now calls Plugins.
A plugin is essentially a package that can bring together reusable instructions, reference material, and connections to other applications. It can contain one or more Skills, connected Apps, or both.
When migration becomes available for your account, OpenAI says creators will be able to open My GPTs, choose the GPT, and select Migrate to plugin.
When you click on “Migrate GPTS,” you will start a guided process to migrate that Custom GPT to a plugin.
The GPT's instructions become a Skill inside the plugin. Files uploaded as GPT knowledge are copied into the plugin as reference files. Connected apps can become apps within the plugin.
A couple of features won’t move. Your previous conversations with the GPT are not transferred and the model you selected for the GPT doesn’t carry over. Custom actions also don’t automatically migrate, so GPTs that call a custom system may require additional work to recreate that connection. Sharing permissions don’t automatically transfer, either.
After migration, the original GPT can still be used until retirement, but it becomes read-only. OpenAI recommends testing the replacement against prompts you already know before switching over completely.
If you don’t like the plugin migration path, there are other options.
One of my custom GPTs might have a long set of instructions that says something like:
“When I give you rough meeting notes, first identify decisions and action items. Then organize them into five specific sections. Always use the same format. Keep the executive summary under 100 words. Flag missing deadlines instead of inventing them. Run a final quality check before returning the result.”
I built the GPT because I didn’t want to paste those instructions every time, and that’s what Skills are designed for.
A Skill is a reusable set of instructions that tells ChatGPT how to perform a particular task. It can include a step-by-step process, examples, templates, scripts, formatting requirements, and supporting resources. Once installed, ChatGPT can use the Skill when the task calls for it, or the user can select it directly.
For example, instead of opening my special "Meeting Summary GPT," I could have a meeting-summary Skill.
I upload the transcript in a normal ChatGPT conversation and ask for the meeting summary. The Skill already knows the format, the rules, what to extract, and what checks to perform.
This makes Skills a good home for custom GPTs that were primarily created to enforce a process. Think of monthly reports, proposal formatting, invoice descriptions, content reviews, compliance checklists, customer call summaries, document preparation, data-analysis routines, or anything else where the value of the GPT is mostly in how it performs the task.
Consider another common use case. Suppose I built an HR Hub GPT and uploaded the employee handbook, benefits guide, leave policy, expense policy, and several HR FAQs.
Employees can ask: "How much parental leave do we receive?", "Can I expense a home office monitor?", "What happens to my PTO if I leave the company?"
The main value here isn’t a complicated workflow, but access to the right information.
For a small and relatively static knowledge base, that material can move into a plugin as reference files. OpenAI says GPT knowledge files are copied into the migrated plugin's reference file but there is another question worth asking: Where does the real source of that information live?
If HR policies actually live in SharePoint, Google Drive, Box, or another company system and change regularly, repeatedly uploading copies may not be the best design. In that case, the replacement could combine a Skill with a connected App.
The Skill might tell ChatGPT how to answer HR questions, which sources to prefer, how to handle conflicting policies, when to quote a policy date, and when to tell an employee to contact HR.
The connected App provides access to the current documents the employee is already permitted to see.
OpenAI describes apps as the connections between ChatGPT and outside services, while plugins can package those app connections together with Skills and other instructions. Existing permissions still apply, so connecting an HR source doesn’t automatically give a user access to documents they couldn’t otherwise open.
Some custom GPTs are really used as permanent workspaces. Maybe I created a "Marketing GPT," uploaded our positioning documents and brand material, and keep returning to it for campaign ideas, research, drafts, and revisions.
A Project may fit that use case better. Projects keep chats, files, instructions, and ongoing context together. Instead of creating a separate customized version of ChatGPT, you create a workspace around a continuing body of work.
A simple distinction is useful here: a Skill remembers how to perform a task, a Project keeps the context surrounding an ongoing piece of work.
You might even use both. A marketing Project could hold campaign research, past discussions, and working files, while a brand-writing Skill controls how final content gets written.
Start by opening each custom GPT and asking a simple question: What job did I actually create this GPT to do?
If the answer is "follow my process every time," it’s probably heading toward a Skill. If the answer is to know documents, consider reference files, Projects, or connected Apps depending on where that information lives. If it exists mainly to keep a long-running body of work together, look at Projects.
If it needs to work across systems and take multiple actions, try Workspace Agents or ChatGPT Work.
And if it combines several of those things, the replacement may be a Plugin containing Skills, reference material, and connected Apps rather than a single standalone assistant.
Before migrating, OpenAI recommends reviewing the instructions and files in each GPT, identifying who uses it, saving a few familiar test prompts, and making sure the latest version is published. Custom actions deserve extra attention because they do not automatically transfer.
For anyone with only a few custom GPTs, this is probably a manageable exercise. It’s also a useful opportunity to look at what each GPT has become over time.
© 2026 SVA Consulting