Use a ChatGPT Project for ongoing business work that needs related chats, files, and instructions together. For a repeatable job that other people need to run, check the plugin options in your workspace before creating another custom GPT: OpenAI documents an Enterprise transition from custom GPTs to plugins (OpenAI migration guidance). Confirm your own account notice before treating a retirement deadline as applicable to your business.
What is a ChatGPT Project?
A Project is one workspace that holds chats, uploaded files, and standing instructions, all grouped around a single subject (OpenAI guide to Projects and chats). You open it the way you would open a folder: every chat you start inside stays scoped to that subject, every file you drop in stays available to those chats, and the instructions you set apply across the whole workspace instead of just one conversation.
For a small business owner, that subject might be "Q4 hiring," "the Jones kitchen remodel," or "vendor contract renewals." You keep reopening it over weeks or months, adding new chats and new files as the work moves forward, rather than starting a fresh conversation and re-explaining the background every time.
What was a custom GPT built for?
A custom GPT was built to be one packaged job: a set of instructions plus reference files, wrapped up so that someone other than you could open it and get consistent answers without knowing how it was built. You created it once, in the GPT Builder, gave it a name and a role, uploaded the files it needed, and then shared a link or published it so other people, customers, staff, or the public, could use it on their own.
That is the real difference from a Project. A Project organizes ongoing work around shared context; the distinction is the work pattern, not simply whether you work alone. A custom GPT was meant to be handed to somebody else: a client-facing FAQ assistant, a standardized onboarding helper for new hires, a tool a whole team could open and follow a common set of instructions.
Where does each one actually fit for a small business?
Before the retirement news, the split was simple. Use a Project when the work is yours and ongoing: a subject you keep coming back to, with files and chat history that need to stay together as the subject develops. Use a custom GPT when the job is repeatable and meant for other people: common instructions and reference material for whoever opens it.
That split still holds. What changes is the "repeatable job for other people" branch. In an Enterprise workspace moving to plugins, avoid building a new dependency on a retiring custom GPT. Check whether plugin creation is enabled, then build the reusable job there. Other accounts should follow their own notices rather than assume that Enterprise timing applies.
Why is OpenAI retiring custom GPTs, and when?
OpenAI's current plugin creation guide states that custom GPTs in ChatGPT Enterprise are being retired. Its migration guide describes the transition, but does not give a universal calendar deadline for every account. Check the notice in your workspace and confirm the applicable dates with its administrator before planning a cutover.
This matters for a small business because an Enterprise notice is not proof that every personal or Business account follows the same schedule. Write your account type, the notice date, and the deadline you were actually given into your migration checklist. If there is no applicable notice, do not invent one from somebody else's announcement.
The practical reason to investigate plugins is their packaging: instructions, reference material, and apps can travel as a reusable workflow. That does not mean every tool or output will behave identically after a move. Keep your current workflow usable while you test the replacement, and make the switch only when the job still works for the people who depend on it.
What exactly carries over when a custom GPT migrates to a plugin, and what does not?
This is the part that bites people who assume a migration is a straight copy. Here is what the migration guidance says to review before relying on the replacement.
What carries over: your GPT's instructions convert into a skill inside the new plugin, your knowledge files copy over as plugin reference files, and any connected apps carry over as apps inside the plugin (OpenAI migration guidance). Migration requires a published GPT, so finish and publish needed edits before converting it (OpenAI migration guidance).
What does not carry over, in three places that will surprise a business owner who is not expecting them:
Do not assume that previous chats will copy into the replacement. If a conversation holds a decision, a draft, or a piece of context you still need, copy it out before the retirement date.
The selected model does not carry forward. Whatever model your custom GPT was set to run on, the plugin does not inherit that setting; Enterprise defaults apply, so check the resulting behavior after migration.
Custom Actions, the API calls some custom GPTs were built to make, do not migrate automatically. OpenAI describes this as requiring separate rebuild work, potentially through a custom MCP server, rather than a one-click carryover (OpenAI migration guidance). If you want to understand what an MCP server actually is and why a small business would need one for this kind of rebuild, see what is MCP for a small business.
The sharing change is the one most likely to cost you users without you noticing: a migrated plugin starts private, and people who had access to your original custom GPT do not automatically receive access to the replacement (OpenAI migration guidance). Every person who used the old GPT has to be given access to the new plugin on purpose, and you have to be the one who tells them it moved.
How do you migrate your custom GPTs without losing your users?
Run through every custom GPT you own before the retirement date reaches it, in this order:
- List every custom GPT you own and who uses it, including staff, customers, and anyone outside your business you shared a link with.
- Write down the instructions and the reference files each one holds, so you are not reconstructing a GPT's purpose from memory after it stops running.
- Decide, for each one, whether it becomes a Project, a plugin, or nothing. A one-off you built for yourself and still use alone probably becomes a Project. A packaged job other people open regularly becomes a plugin. Something nobody has opened in months becomes nothing.
- Rebuild the highest-use one first. That is the one where a gap in service costs you the most, and the one where you most need time to catch problems before the old GPT actually stops.
- Run the same three real prompts, questions your actual users ask, against the old custom GPT and the newly rebuilt version, and compare the answers side by side. OpenAI's own guidance is to retest rather than assume a migrated plugin behaves the same way, since response behavior, reference material use, and output formatting can all shift (OpenAI migration guidance).
- Tell the people who used it where it moved, and confirm they actually have access, since access does not transfer on its own.
Keep a short result sheet beside those three prompts. For each test, write the input, the expected facts, the source document, the required output format, and what would make you reject the answer. Do this before reading either output so a polished response cannot quietly change your standard.
For example, use a fictional onboarding question whose answer is present in your handbook, one whose answer is missing, and one that asks for an exception only a manager can approve. The first should use the right policy. The second should acknowledge the missing information. The third should leave the decision with the manager. These are suggested test cases, not measured results or a guarantee about either tool.
Ask a teammate with ordinary access to repeat the checks. A successful run from the creator's account does not tell you whether a new hire can open the replacement, access its reference material, or get the required result. Record any failure and its owner before announcing that the move is finished.
If you train the new plugin or Project on the same business documents your old custom GPT relied on, the groundwork in how to train an AI assistant on your business information covers how to keep that reference library current and checkable once the migration is done.
How do a Project, a custom GPT, and a plugin compare?
| Decision point | ChatGPT Project | Custom GPT (retiring) | Plugin (the replacement) |
|---|---|---|---|
| What it holds | Chats, uploaded files, and standing instructions grouped around one subject | Instructions plus reference files, packaged as one repeatable assistant | A skill built from your instructions, plugin reference files, and connected apps |
| Who can use it | People with the appropriate Project access; confirm sharing settings for your workspace | Whoever the creator shared a link with, or anyone who found it publicly | Whoever the creator grants access to after migration; it starts private, so old users are not carried over automatically |
| Does it survive the retirement | A separate workspace for ongoing work; not the custom GPT migration target | Retiring in affected Enterprise workspaces; confirm the deadline in your account notice | Yes, it is the container OpenAI built to replace custom GPTs going forward |
| What a small business should put in it | Ongoing work you keep reopening: a subject's running chats and files that need to stay together | Avoid new dependencies in a workspace scheduled for retirement | The highest-use packaged job you still need other people to open, rebuilt and retested before you tell anyone it moved |
Should you start something new in a custom GPT right now?
For an affected Enterprise workspace, my recommendation is to start with the replacement path. If the work is ongoing, start a Project. If the job is meant to be packaged for other people, check whether Plugin Creator is available and your permissions allow it. OpenAI already documents building a plugin from scratch, so a blanket instruction to wait for future tools would be misleading. If your workspace lacks that option, prepare the instructions and test examples while your administrator checks access.
While you are deciding what belongs in a Project versus what should become a plugin, it is worth writing down the rule for your team at the same time. A short policy keeps everyone from building a new custom GPT out of habit during an applicable retirement transition; see a one-page AI use policy for a small team for a template you can adapt in an afternoon. And if your business is still deciding which AI tools belong in its stack at all, AI tools for small business is the place to start that comparison before you commit to rebuilding anything.
If the packaged job you are rebuilding needs to connect to other business systems, not just hold files and instructions, that is a larger infrastructure decision than either container answers on its own; MetaTechAi's AI infrastructure guidance covers what to plan for when an AI tool needs to talk to the rest of your business software.
What are the FAQs about ChatGPT Projects vs custom GPTs?
Can I still use my existing custom GPTs right now?
In the documented Enterprise transition, the original GPT remains usable until retirement. After migration it becomes read-only. Confirm the deadline that applies to your workspace, and test its replacement before switching the people who rely on it.
Will my custom GPT conversations move to the new plugin automatically?
Do not count on it. OpenAI says previous chats may not copy. If a conversation holds information you still need, copy it out before the retirement date.
Do the people who used my custom GPT automatically get access to the plugin?
No. A migrated plugin starts private, and people who used your original custom GPT do not automatically receive access to the replacement. You have to grant access again and tell them where it moved.
What should I do with a custom GPT nobody uses anymore?
Let it retire with no action. Spend your migration time on the custom GPTs people actually open, not on rebuilding something nobody will miss.
Is a ChatGPT Project the same thing as a custom GPT?
No. A Project is a workspace that holds chats, files, and standing instructions around one ongoing subject. A custom GPT was a packaged assistant built so other people could open and use it the same way you did.
What should you do next?
If you want a second opinion on which of your custom GPTs is worth rebuilding and which one should just retire, contact James Hill to walk through the list together.