Custom GPTs are closing down. What you need to know.

Short answer: OpenAI is winding down Custom GPTs: personal plans already cannot create or publish new ones, and existing bots are only temporary grace. When a GPT still earns its keep, export instructions and knowledge files now, then rebuild in Projects, plugins, or Workspace Agents.

Key takeaways:

No new builds: Stop creating Custom GPTs on personal plans; treat existing ones as temporary.

Inventory first: List each GPT’s purpose, owner, dependents, files, and priority before migrating.

Export the brain: Copy full instructions and download every knowledge file while you still can.

Rebuild critically: Move top workhorses into ChatGPT Projects; retire toys without ceremony.

Warn sharers: Tell teams and shared-link users before links go dark and workflows break.

What is ending vs what still works right now 

Creation and publishing of new Custom GPTs on personal plans is already locked. You cannot spin up a fresh GPT Store listing or publish a brand-new personal Custom GPT the way you used to. Existing ones may still be usable - and in some cases editable - for a while. Treat "still works" as temporary grace, not a promise.

Workspace and enterprise setups follow a published wind-down path. That usually means admin notices, migration tooling, and a push toward newer building blocks: ChatGPT Projects for focused workspaces with files and instructions, plugins where available, and Workspace Agents for team-scale automation. The names shift a bit by plan; the idea does not. Custom GPTs as a product surface are on the way out.

What still works in practice, while you still can:

• Opening and chatting with many existing Custom GPTs you already own or were shared with
• Editing instructions or knowledge files on some plans before edit access disappears
• Copying out system instructions, conversation starters, and uploaded knowledge files
• Documenting who relies on which GPT before everyone finds out the hard way

What does not work anymore for many personal accounts: creating new Custom GPTs, publishing to the GPT Store, and treating Custom GPTs as a long-term home for critical workflows. If Custom GPTs are closing down. What you need to know starts here - stop building new ones and start salvaging the good ones.

Personal vs workspace: why your plan changes the playbook

Personal Free / Go / Plus / Pro users are already in the "no new builds" lane. Your job is personal backup: grab instructions, grab files, rebuild inside Projects or another tool, and tell anyone you shared a GPT with that the link may go dark.

Enterprise and workspace admins face a different tangle - and, somewhat ironically, a clearer map. Shared GPTs often sit in the middle of team process: onboarding bots, policy Q&A, sales talk tracks, support macros dressed up as chat. When those break, people do not shrug; tickets appear. So inventory at the org level, assign owners, and pick successors (Projects, plugins, Workspace Agents) before the shared ones stop running.

I guess the rule of thumb is: if only you use it, back it up this week. If a team uses it, treat it like a product deprecation with a tiny migration plan. Not a 40-page PRD. A checklist and a named owner. That is enough.

Inventory checklist: find every Custom GPT that matters

You cannot migrate what you cannot name. Open your GPT list and make a simple inventory before anything else. Spreadsheet, notes app, sticky notes - whatever. Perfection is the enemy here.

For each Custom GPT, capture:

• Name and purpose - one sentence on what it does
• Owner - you, a teammate, or "orphaned somehow"
• Who depends on it - just you, a team, clients, or a shared link floating around Slack
• Instructions length - short prompt vs a novel of rules
• Knowledge files - PDFs, docs, CSVs uploaded into it
• Actions / tools - any API hooks, browsing, or custom actions
• Priority - critical daily, nice weekly, or digital dust
• Successor guess - Project, plugin, Workspace Agent, or "retire quietly"

Sort by priority first, not by how cute the GPT avatar was. The avatar will not miss you. Your Monday morning workflow might.

A lot of people discover, almost by accident, that they have three GPTs doing the same job with slightly different instructions. Consolidate while you migrate. Future-you will send a thank-you note.

What to save, why, how, and how urgent it is

Use this as a packing list. Mild quirks included - yes, "conversation starters" are worth keeping even if you never show them to users again.

Do the critical rows first. Knowledge files especially - once edit or download access softens, hunting for the original PDF on someone's laptop is a special kind of pain.

Export instructions and knowledge files before they stop running

This is the unglamorous part that saves you later. Open each high-priority Custom GPT while you still can. Copy the full instructions into a plain text or markdown file - wait, plain text is safer for version control; markdown is fine too. Name files clearly: support-triage-instructions.txt, not final-final-v3.txt.

Then download every knowledge file. Put them in a folder per GPT. If a file was updated inside the GPT and you are not sure which version is current, grab what is in the GPT now and also hunt for the source of truth in Drive or SharePoint. Dual backup beats a single mystery PDF.

A few practical tips that sound obvious until you skip them:

• Export on a calm day, not five minutes before a demo
• Strip secrets from instruction text if you paste it into a shared team drive
• Note model quirks you relied on - tone rules, formatting rules, "never invent SKUs," that kind of thing
• If the GPT used custom actions, write down what each action did in human language, not just the schema

I started this section meaning to say "just copy the prompt," then realized half the value is usually buried in the files. The prompt is the recipe card; the knowledge files are the pantry. You need both or dinner is toast. Metaphorically. Please do not eat your PDFs.

Rebuild critical bots in ChatGPT Projects 🛠️

For many personal and team workflows, ChatGPT Projects are the natural next home. A Project gives you a dedicated space with its own instructions and files - close enough to a Custom GPT that the migration feels familiar, without pretending it is a one-click clone.

A sensible rebuild path:

• Create a Project named after the old GPT's job, not the old GPT's joke name
• Paste the exported instructions; trim anything that only made sense in the GPT Store
• Upload the knowledge files you truly need - do not dump every dusty draft sitting in the folder
• Test with the same prompts you used before and compare outputs side by side
• Invite the people who used the old GPT and retire the old link when they are comfortable

Projects excel at ongoing work: research folders, content pipelines, client briefs, internal Q&A with a fixed corpus. They are less of a "public app in the GPT Store" and more of a serious workspace. That is fine. Most Custom GPTs that earned their keep were workhorses, not storefronts.

If Custom GPTs are closing down. What you need to know for rebuilds is this: start with your top three critical bots, not the whole zoo. Ship those. Then decide which of the rest deserve a Project and which deserve a quiet goodbye.

Plugins, Workspace Agents, and other successor paths 🔌

Not everything belongs in a Project. Some Custom GPTs were thin wrappers around tools, APIs, or multi-step team processes. Those map better to plugins where your plan supports them, or to Workspace Agents on enterprise-style setups.

Rough mapping that has worked in practice:

• Instruction-heavy + files - ChatGPT Projects
• Tool / API automation - plugins or action-style successors; re-auth carefully
• Team processes with ownership - Workspace Agents, with an admin in the loop
• Public / discovery bots - rethink distribution; the GPT Store era for Custom GPTs is ending
• One-off toys - do not migrate; archive the prompt and move on

Expect some friction. Capabilities will not match one-for-one. A Custom GPT that mixed browsing, files, and a quirky persona might become a Project plus a separate tool, or an agent with clearer permissions. That split is annoying and also healthier - fewer mystery black boxes.

Outside ChatGPT entirely, some teams rebuild the same workflows in other assistants or internal apps. That is valid. Just keep your exported instructions and files so you are not rewriting from memory like a folk tale.

Team and shared GPT risks you should not ignore

Shared Custom GPTs are where quiet outages become loud. Someone bookmarks a GPT in a Notion page called "How we do support." Another person drops the link in onboarding. Nobody owns the instructions. Then creation locks, edits freeze, and suddenly the bot that "everyone uses" starts acting like a haunted attic.

Mitigate early:

• Assign an owner per shared GPT - a human with a name, not "the team"
• Post a short note in the channels that use it: what is changing, what the successor is, when to switch
• Replace hardcoded links in wikis and onboarding docs while the old GPT still answers
• Keep a read-only archive of instructions so new hires are not learning from a dead URL
• For client-facing GPTs, plan a message that sounds calm, not apocalyptic

Light sarcasm time: if your process only lives inside a Custom GPT with no backup, that was never a process. That was a hope with a chat interface. Fix the hope while the interface still opens.

Common mistakes while migrating (please skip these)

People make the same mistakes under mild pressure. I have made a few of them. Learning is available; repeating is optional.

• Waiting for a perfect announcement - act while you still can edit and download
• Migrating everything - migrate critical and high-use only; archive the rest
• Forgetting knowledge files - instructions without files are half a brain
• Pasting secrets into shared docs - API keys do not belong in the team wiki
• Changing tone and rules during migration - rebuild first, redesign second
• Not telling the team - silent cutovers create support tickets and distrust
• Assuming Projects are identical - test outputs; adjust; then announce "done"
• Leaving GPT Store listings as the source of truth - copy the copy now

Also: do not invent elaborate migration theater. You do not need a steering committee for a content-repurposing GPT used twice a month. You need a folder and twenty minutes.

A practical week-shaped plan without calendar panic

Speak in relative terms and keep moving. Here is a simple sequence that works whether you have one GPT or twenty.

1. Today-ish: Inventory. Flag critical vs retire.
2. Next stretch of free time: Export instructions and knowledge files for anything critical or high.
3. Soon after: Rebuild the top two or three in Projects (or agents/plugins if that fits).
4. Before they stop running: Switch your personal defaults; update team links; tell stakeholders.
5. Ongoing: Retire low-value GPTs; keep the archive; stop creating new Custom GPTs that cannot be published anyway.

The emotional part is harder than the technical part, more often than people admit. You spent evenings tuning a GPT that finally "got" your voice. Saying goodbye feels silly until you remember you still have the instructions. The soul of the bot is text. Text travels.

Key takeaways

Custom GPTs are closing down. What you need to know, boiled down:

• New Custom GPT creation and publishing on personal plans is already constrained; existing ones are on borrowed time
• Inventory everything; prioritize by lived usage, not nostalgia
• Export instructions, knowledge files, starters, and action notes while you still can
• Rebuild critical workflows in ChatGPT Projects; use plugins or Workspace Agents where they fit better
• Warn teams, update docs, assign owners for shared bots
• Skip panic, skip migrating junk, skip waiting for a perfect moment

Act early, pack carefully, rebuild what earns its keep. The platform is shifting under the GPT Store and Custom GPT layer - that is inconvenient, not career-ending. Your workflows were always bigger than one product button. Keep the recipes. Change the kitchen. You will be fine.

Practical example: Migrating a shared support Custom GPT into a ChatGPT Project

Deprecations feel abstract until Monday's onboarding link goes dark. Here is how a UK customer-support lead used the inventory → export → rebuild path from this guide when Custom GPTs are closing down - and what you need to know to pack the bot that earns its keep.

Scenario

Jordan's team has a Custom GPT called "Support Triage Helper." It holds the tone rules, "never invent SKUs," a knowledge pack of help articles, and four conversation starters that new hires click without thinking. The link sits in Notion under "How we do support." Creation of new Custom GPTs on their personal-style plans is already locked. The shared bot still opens - for now - which is grace, not a lease.

Jordan is not migrating the whole zoo of half-finished GPTs. Priority one is this workhorse: copy instructions, download knowledge files, rebuild inside a ChatGPT Project, update the wiki link, tell the channel, then retire the old URL when people are comfortable.

The goal is continuity without migration theatre - a checklist and a named owner, not a 40-page PRD.

What the migration needs

• An inventory row: name, purpose, owner (Jordan), who depends on it, knowledge files, actions, priority, successor guess (Project)
• Full custom instructions pasted into a clearly named file (e.g. support-triage-instructions.txt)
• Every uploaded knowledge file downloaded into a folder named after the GPT
• Conversation starters and 3-5 sample chats that show what "good" looked like
• Notes on any actions/API hooks in human language (no secrets in Slack)
• A ChatGPT Project with trimmed instructions, only the files still needed, and side-by-side test prompts
• Updated Notion/onboarding links and a short channel note before the old GPT stops running

Example instruction

Use this as the rebuild brief inside the new Project (after you paste the exported system instructions and upload the verified knowledge files):

You are Support Triage Helper for our scheduling SaaS. Follow the exported tone and "never invent SKUs" rules exactly. Answer only from the uploaded help articles; if the answer is missing, say you do not know and suggest the human escalation path. Output: likely cause, evidence from the docs, next check, and a draft reply in UK English. No preamble. If a question needs an API or live system action we have not connected here, say so instead of pretending.

First tests to run (same prompts as the old GPT): (1) "Customer says billing toggle greyed out after upgrade - triage," (2) "Draft a calm reply when we cannot find their invoice," (3) each old conversation starter once. Compare outputs to the saved sample chats before you announce the switch.

How to test it

• Inventory first: list every Custom GPT; mark critical / high / retire. Do not start with the cute avatars.
• Export while edit/download still works: instructions + knowledge files + starters. Dual-backup mystery PDFs from Drive if versions differ.
• Rebuild only the top two or three. Test the same prompts side by side with the old GPT while it still runs.
• Edge case: a GPT with custom actions - document what each action did; re-auth carefully in plugins or agents if that fits better than a Project.
• Acceptance checks before cutting over: (1) instructions file complete, (2) all critical knowledge files present, (3) three test prompts match sample quality, (4) Notion link updated, (5) channel notified with owner name, (6) no API keys pasted into the team wiki.

Result

Illustrative result (example estimate for one support team's migration sprint, not a published OpenAI study): Across 8 Custom GPTs inventoried, 3 were critical/high and rebuilt as Projects; 5 were archived with instructions only. Export and rebuild for the support triage bot took about 90 minutes wall-clock (inventory 15, export 25, Project setup and file upload 20, side-by-side testing 30). After cutover, "where did the GPT go?" pings in the support channel fell from a burst of 6 in the first week of rumours (no owner, no note) to 1 clarifying question once the Notion link and channel post existed. On a migration checklist (export complete, Project tested, docs updated, owner named, secrets stripped), 3 of 3 rebuilt bots passed before announce versus 0 of 3 under a "we'll deal with it when it breaks" habit. Limitations: small team, one product area; bots without knowledge files migrate faster; action-heavy GPTs take longer; timing excluded waiting on admin approvals for Workspace Agents.

To measure your own version: inventory all Custom GPTs with priority labels; time export+rebuild for each critical bot; track checklist pass rate and post-cutover help requests for two weeks; report counts with denominators.

What can go wrong

• Waiting for a perfect announcement: Act while you can still edit and download.
• Migrating everything: Archive toys; rebuild workhorses.
• Instructions without files: Half a brain. Grab the pantry, not only the recipe card.
• Silent cutover: Shared links in onboarding become a haunted attic.
• Secrets in the wiki: Strip API keys when you paste exports into shared drives.
• Assuming Projects are identical: Test outputs, then announce done - not the other way round.
• No named owner: "The team" cannot rotate a dead URL.

Practical takeaway

When Custom GPTs are closing down, what you need to know is operational: inventory, export instructions and knowledge files, rebuild the few that earn their keep in ChatGPT Projects (or plugins / Workspace Agents where tools and team process fit better), warn anyone who shared the old link, and skip the junk. The soul of the bot is text. Text travels. Keep the recipes; change the kitchen.

FAQ

What does Custom GPTs are closing down mean for ChatGPT users?

OpenAI is winding down Custom GPTs across ChatGPT plans. Personal Free, Go, Plus, and Pro accounts already cannot create or publish new ones, while existing GPTs may still run or edit for a while - treat that as temporary grace, not a promise. Workspace and enterprise setups follow a published wind-down path toward successors like plugins, ChatGPT Projects, and Workspace Agents. Stop building new Custom GPTs and start salvaging the ones that earn their keep.

Can I still create or publish new Custom GPTs?

For many personal accounts, no - creation and publishing are already locked, including new GPT Store listings. Existing Custom GPTs you own or were shared may still open, and on some plans you can still edit instructions or knowledge files before that access disappears. Critical workflows should not treat Custom GPTs as a long-term home. Copy instructions, starters, and files while you still can.

How does the wind-down differ for personal vs workspace plans?

Personal users mainly need personal backup: export instructions and files, rebuild in Projects or another tool, and warn anyone who had a shared link. Enterprise and workspace admins face shared bots inside onboarding, policy Q&A, sales tracks, and support macros - so inventory at org level, assign owners, and pick successors before those bots stop running. If only you use it, back it up this week; if a team uses it, treat it like a small product deprecation.

What should I inventory before Custom GPTs stop working?

For each GPT capture name and purpose, owner, who depends on it, instruction length, knowledge files, actions or tools, priority, and a successor guess. Sort by lived usage - critical daily versus digital dust - not by avatar nostalgia. Many people find three GPTs doing the same job; consolidate while you migrate. You cannot migrate what you cannot name.

Which Custom GPT assets are most important to export?

System instructions and knowledge files are critical - the brain and the pantry. Also copy conversation starters, action or API notes in human language without pasting secrets into Slack, a few sample chats that show good output, sharing lists for people to warn, and GPT Store listing copy if you published. Download files into a clearly named folder per GPT and dual-backup mystery PDFs from Drive when versions differ.

How do I rebuild a Custom GPT in ChatGPT Projects?

Create a Project named after the job, paste exported instructions, upload only the knowledge files you still need, then test the same prompts side by side with the old GPT. Invite prior users and retire the old link when they are comfortable. Projects fit ongoing work - research, content pipelines, client briefs, internal Q&A - more than public GPT Store apps. Start with your top two or three critical bots, not the whole zoo.

When should I use plugins or Workspace Agents instead of Projects?

Instruction-heavy bots with files usually map to Projects. Tool or API automation fits plugins or action-style successors - re-authenticate carefully. Team processes with clear ownership fit Workspace Agents with an admin in the loop. Public discovery bots need a rethink because the Custom GPT Store era is ending, and one-off toys can be archived without migrating. Expect some friction; one-for-one clones are unlikely.

What risks do shared team Custom GPTs create during the shutdown?

Shared GPTs often live in Notion, onboarding docs, and Slack with no named owner - then edits freeze and the bot everyone uses becomes a haunted attic. Assign a human owner, post what is changing and when to switch, replace hardcoded links while the old GPT still answers, and keep a read-only archive of instructions. For client-facing bots, plan a calm message. A process with no backup was a hope with a chat interface.

What migration mistakes should I avoid?

Do not wait for a perfect announcement - act while you can still edit and download. Migrate critical and high-use only; archive the rest. Do not forget knowledge files, paste API keys into shared wikis, redesign tone mid-migration, or cut over silently. Projects are not identical - test outputs before announcing done, and copy Store listing text now if it matters. Skip steering committees for a bot used twice a month.

How do I migrate a shared support Custom GPT into a Project?

Inventory the bot, export full instructions and every knowledge file, save starters and sample chats, then rebuild in a Project with trimmed rules and verified files. Test the same triage prompts side by side, update Notion or onboarding links, and notify the channel with the owner name before the old URL dies. Acceptance means complete exports, matching sample quality, updated docs, and no secrets in the team wiki.

References

1. OpenAI — Winding down Custom GPTs — help.openai.com