What happens to your association’s custom GPT on 11 December 2026
If your organization built a member assistant as a custom GPT, OpenAI retires it on 11 December 2026. Three things do not carry over automatically: who the assistant is shared with, anything that reached into your other systems, and the model behind the answers.
This is a custom GPT migration checklist: what carries over, what does not, and what to do about each. It is not a sales page. The last section says where we fit and where we don’t.
What OpenAI has said
OpenAI is replacing custom GPTs with plugins: reusable instructions (called skills), reference files, and connected apps. From 11 December, custom GPTs and their GPT pages become inaccessible. In affected Enterprise workspaces, creating new custom GPTs ended on 26 October. FedRAMP workspaces and workspaces with an approved deferral have until 11 February 2027.
After you migrate, the original GPT stays usable until retirement but becomes read-only. In an Enterprise workspace, the GPT’s creator or a workspace admin can migrate it, and admins can migrate in bulk. Permission to use someone else’s GPT does not give you permission to migrate it. OpenAI’s guidance tells creators to retest, because a migrated plugin may respond differently.
Source: OpenAI’s migration FAQ. Trade-press coverage: THE Journal, TechRepublic, EdTech Innovation Hub.
Custom GPT migration: what carries over and what does not
| Carries over | Does not |
| Instructions → a skill | The model the GPT used |
| Knowledge files → reference files | Custom actions (rebuild as an app or custom MCP server) |
| Connected apps → apps in the plugin | Sharing: a migrated plugin starts private |
Migration uses the latest published version of the GPT. Drafts and unpublished edits do not transfer. Publishing does not require sharing the GPT publicly. Existing conversations with the GPT stay accessible after retirement, and you do not need to do anything to keep them.
The three that hurt an association most
Sharing resets. A migrated plugin starts private, and people who could use the GPT do not automatically get access. If your assistant sits behind your member login or is linked from your portal, check that link on migration day. In a managed workspace, OpenAI’s Share Plugin option can prefill the original GPT’s users, groups or workspace audience, but you still have to review the audience and save it, and people may still need to install the plugin.
Custom actions break. If your assistant looked anything up in your AMS, events system or CE records, that was probably a custom action. It stops working until you rebuild it. OpenAI says that may need a custom MCP server and technical setup, and a rebuilt integration should not be assumed to do everything the original did.
Answers can change. The model the GPT used does not carry over, and OpenAI says a migrated plugin may respond differently. An assistant members trusted last month may phrase things differently, or use your reference files differently, after the move.
Your instructions are the asset
We published these figures in our press release on the custom GPT retirement.
Instructions do migrate. That is the good news, and it is also why they are worth protecting.
Across 82 associations and nonprofits running AI assistants on their own content, teams made 1,086 revisions to their assistants’ instructions. In seven in ten assistants, the organization wrote those instructions itself. Months of judgement about how your organization answers, what it covers, and what it does when it is unsure sit in that text.
Whichever platform you use, keep a copy you control.
Your checklist before 11 December
- Export the instruction text. Copy it out of the GPT editor into a document your organization owns. It is the hardest piece to rebuild from memory, and it is yours whatever you decide next.
- List every custom action. For each one, write down what it did (for example, “looks up a member’s renewal date in the AMS”) and which system it called. Each needs rebuilding as an app or a custom MCP server, or retiring on purpose. Allow extra time for these.
- Write down who the assistant is shared with. List the audience (all members, a committee, staff only) and every place that links to it: the portal, member emails, the website. After migrating, share the plugin again and update the links.
- Finish any edits first. Only the latest published version migrates, so publish anything you still need before you migrate. After migration the original is read-only, so make future changes in the plugin.
- Check what migrated. Review the instructions and the reference files in the new plugin, and the apps it connects to.
- Retest. Run the questions members ask most, plus at least one hard one, and compare the answers with the old GPT. Test any connected apps or rebuilt integrations separately.
- Confirm people can use it before you tell them to switch. Ask someone who used the GPT to install the plugin and try it.
If you migrate within OpenAI, this list still applies in full.
Where we fit, and where we don’t
We make CustomGPT.ai, one of several tools an organization can use to run an assistant on its own content. We are not affiliated with OpenAI, and we are not a migration path provided or endorsed by OpenAI.
Migrating within OpenAI is the shortest path, and for many organizations the right one. If your assistant is lightly used and shared with a handful of people, it is almost certainly the right one.
The question worth asking over the next few weeks is which parts of what you built are yours: the instructions, the content, the integrations and the audience. Write those down somewhere you control, then choose a platform. If you are weighing a platform you control, our comparison of ChatGPT and member AI for associations covers where each fits.
