Custom GPTs vs ChatGPT Projects: what your team should use now.

Should a team use custom GPTs or ChatGPT Projects?

For anything new, use a ChatGPT Project, not a custom GPT. OpenAI announced in September 2026 that custom GPTs are being retired, with most scheduled to stop running on 11 December 2026. Projects stay, and a reusable helper that used to be a GPT now becomes a plugin.

That changes the usual advice. A year ago the answer was "GPTs for repeatable jobs, Projects for ongoing work". Now the repeatable part moves to plugins, which bundle written instructions (OpenAI calls them skills) with connections to your other apps. Projects keep doing what they were always good at: holding the chats, files and instructions for one piece of work in one place.

The dates come from OpenAI's custom GPT retirement FAQ. OpenAI says they can change, and some Enterprise workspaces with an approved deferral run to 11 February 2027. Creation of new GPTs has already ended in many workspaces, so if your team was planning to build one, build it the new way instead.

What is the difference between a Project and a custom GPT?

A custom GPT is a tool you open to do one type of job. A Project is a folder you work inside for one piece of work. The GPT carries the method; the Project carries the context. Teams usually need both: a standard way of writing a quote, and a place to keep everything about one client.

Think of a proposal. The method is the same for every client: work out the fee, write the approach, pick the right case studies, attach the team. That method used to live in a GPT and now belongs in a plugin. The material for one client, their brief, site photos, meeting notes and earlier drafts, belongs in a Project so it builds up over the weeks the job runs.

Projects have a few details worth knowing before you share one with staff, all from OpenAI's Projects help page:

• Everyone sees everything. Members can see the project's chats, files and member list, and can download any file in it. Do not put payroll in the same Project as a client brief.
• Shared Projects keep their own memory. Once shared, a Project only remembers what happened inside it. It does not draw on each person's saved memories, and that setting cannot be switched back.
• Chats branch, they are not co-edited. Two people can work from the same chat, but each continues their own copy rather than typing into one conversation together.

What happens to our custom GPTs in December?

They stop working on the retirement date and disappear from the GPT directory. Before then, the person who built each GPT, or a workspace admin, can migrate it to a plugin from the My GPTs screen. Instructions, knowledge files and connected apps come across. Custom actions, the chosen model, past chats and sharing settings do not.

Three things catch people out:

• The new plugin starts private. Your staff do not get access automatically. In managed workspaces there is a share option that fills in the old GPT's audience, but someone has to press it.
• Custom actions need rebuilding. If your GPT pushed data into another system through an action, that link has to be rebuilt as a supported connector or a custom connection, and it may not work exactly as before.
• The old GPT goes read-only. After migration you can still use the original until December, but you cannot edit it. Test the plugin on a handful of prompts you know the right answer to before you tell the team to switch.

If you used a GPT to answer customers through a public link, read the FAQ closely. When we checked, OpenAI had not documented a like-for-like replacement for sharing outside your workspace.

When should you use a ChatGPT Project?

Use a Project when the work runs over days or weeks and the context keeps growing: a tender, a client account, a fit-out, a hiring round. Upload the documents once, set short instructions for how ChatGPT should behave in that Project, and every chat inside it starts already knowing the job.

Good Projects we set up with teams:

• One per major client or job. The brief, the contract, site notes and every email summary in one place. Anyone picking it up mid-job can ask what was agreed and get an answer with the source.
• One per tender. Drop in the tender documents and ask for the compliance checklist, then work through the response in the same Project. If tenders are a big part of your week, our document processing work goes further and pulls the requirements out automatically.
• One for your own business planning. Financials, strategy notes and board papers, kept private to the owner.

Where Projects fall down is consistency. Each Project's instructions are written separately, so five Projects end up with five slightly different ideas of how your business writes a quote. That is the job for a plugin.

When should you build a plugin instead?

Build a plugin when the same job is done the same way every time, by more than one person. Quote writing, proposal drafting and new-client onboarding are the classic three. The plugin holds the method once, so every staff member gets the same structure, the same pricing logic and the same tone.

How the three examples look in practice:

• Quote writer. Your price list, your standard inclusions and exclusions, and three or four past quotes you are proud of. The skill tells it to ask for the missing details before it drafts, not guess them. Expect to correct it at first: an AI estimate is wrong until it has your own rates and past jobs to work from.
• Proposal drafter. Your fee approach, a methodology template, and short write-ups of your best case studies so it can pick the relevant ones. Pair it with a Project per client for the brief.
• Onboarding helper. The checklist for a new client or a new starter: what to collect, what to send, in what order. Connect it to your email or CRM and it can draft the welcome pack from the details instead of someone retyping them.

According to OpenAI's plugins help page, Business and Enterprise users can share plugins with the rest of their workspace. If your team is still on a mix of personal Plus accounts, that is a good reason to move everyone onto one business account. Our ChatGPT Business pricing guide covers what that costs in Australia.

How do you move a team from GPTs to Projects and plugins?

List every GPT your team actually uses, keep the two or three that earn their place, and migrate those to plugins. Move the client material that was sitting inside GPTs into Projects. Test each one on prompts with known answers, share it, then tell staff to stop using the old version.

1. Audit. Ask each person which GPTs they open in a normal week. Most teams find a long tail of experiments nobody uses. Let those retire.
2. Separate method from material. Instructions and templates go into the plugin. Client files that someone uploaded into a GPT as "knowledge" go into the right Project instead.
3. Check the actions. Anything that sends data to another system needs rebuilding. This is the step to give the most time.
4. Test, then share. Run the plugin on five jobs you have already done and compare it to what went out. Then share it with the workspace, because it will not share itself.
5. Write down who owns it. One person keeps each plugin's price list and templates current. A quote writer working off last year's rates is worse than none.

If a plugin starts running on its own, reading new enquiries and drafting replies without anyone opening ChatGPT, you have moved past a helper into an agent. That is a different build, and it is what our AI teams work covers.

Is ChatGPT the right home for this at all?

Often, yes, especially if your team already uses it daily. But the retirement is a good moment to check. If your staff live in Microsoft 365, or you are weighing Claude, the same split of method and material works there too, under different names.

Claude has its own Projects and skills, and many of the teams we train run both tools. Our guide to building an AI brain with Claude Projects shows the same idea on Claude. Whichever tool you pick, the hard part is the same: writing down how your business actually does a quote or a proposal, clearly enough that a machine can follow it.