ChatGPT Projects vs Custom GPTs: Which to Build

Build a ChatGPT project when you are the one doing the work: it keeps related chats, files, instructions and connected sources together, so every new chat starts from the same context. Build a custom GPT when you want to hand a finished assistant to other people, who use it without seeing or changing how it was set up. That was the choice until September 2026. OpenAI is now retiring custom GPTs and moving their workflows to plugins, and its retirement FAQ gives 11 December 2026 as the date custom GPTs stop running, with a later date for Enterprise workspaces granted a deferral. So the practical question today is a project or a plugin, and what to do with the GPTs you already have.

The same question on the Claude side is answered in Claude Projects vs Custom GPTs. Running a ChatGPT project well, from scoping to upkeep, is in ChatGPT Projects best practices. This post compares the two ChatGPT features with each other and covers the migration. It follows OpenAI’s documentation as it reads at the end of September 2026.

At a glance

• Purpose. Project: a workspace for ongoing work on one body of material. GPT: one repeatable job, packaged for reuse by others.
• Files. Project: uploaded files and connected sources that every chat in it can use. GPT: knowledge files the builder uploads for everyone who uses it.
• Instructions. Project: rules for the chats in that project. GPT: the job description for the assistant, written by the builder.
• Memory. Project: a setting per project, default or project-only. GPT: no project-style memory setting; each user’s conversations with it are their own, not shared with other users.
• Sharing. Project: collaborators work in the same project and see its chats. GPT: users get the configured assistant, not the builder’s chats or settings.
• Other systems. Project: installed plugins and connected sources. GPT: connected apps or custom actions that call an API, but not both in one GPT.
• Future. Project: current. GPT: being retired; the replacement is a plugin.

What a project is for

OpenAI’s page on projects and chats↗ (opens in a new tab) gives the test: create a project when work will continue over time, produce more than one output, or depend on the same files and sources. Each project has a Chats section and a Sources section, and its instructions apply across its chats. The same project can hold quick chats and ChatGPT Work chats side by side. In the desktop app a project can also be local, attached to folders on your computer that ChatGPT can read and change.

The person using a project is the person shaping it. You add the files, you rewrite the instructions when they stop fitting, and you choose the memory setting. How that setting decides what crosses between projects is in ChatGPT project memory.

What a custom GPT was for

A custom GPT separated the builder from the user. Someone wrote instructions, uploaded knowledge files, chose capabilities such as web search or data analysis, optionally picked a model, and added a way to reach other systems. Colleagues or customers then opened the GPT by name, or mentioned it with @, and got all of that without setting anything up.

OpenAI’s admin guide to GPTs and sharing↗ (opens in a new tab) adds two details that matter for migration. A GPT builder can use either connected apps or custom actions, but not both in the same GPT. And in a managed workspace, admins control who can create GPTs, whether they can be shared with specific people, groups or the whole workspace, and which outside domains custom actions may call.

Files, instructions and memory compared

• Files. A project’s files change as the work moves on, and the next chat sees the change. A GPT’s knowledge was part of its build: the builder replaced files for everyone, which suited stable material such as a policy or a product catalogue.
• Instructions. Project instructions are for the people in the project. A GPT’s instructions had to cope with requests from users who never read them, so they carried more of the load.
• Memory. A project can use your saved memories and chat history, or be sealed with project-only memory. A GPT had no such setting, and nothing one user said to it reached another user’s conversation.
• Model. A GPT could select a model for everyone. That selection does not survive migration to a plugin, as the next sections explain.

Sharing, actions and apps

Sharing a project brings people into the same workspace: they see its chats, files and instructions, so it is collaboration. Sharing a GPT handed people a tool: they used it in their own conversations and never saw its configuration. If you need colleagues to follow one procedure without joining your working space, that was a GPT’s job, and it is now a plugin’s.

Reaching other systems also differs. A project uses installed plugins and connected sources, and a chat inside it can call any plugin you have installed. A GPT used connected apps or custom actions, which described a REST API the GPT could call. Custom actions are the part of a GPT that does not carry forward, so a GPT built on them needs the most work before retirement.

Plans

Projects, file limits and sharing options vary by plan, and OpenAI’s help centre lists them. For GPTs, the plan question has been overtaken by the retirement: OpenAI is ending the creation of new GPTs ahead of it, and its migration guide notes that creators can keep editing a GPT they have not migrated even after new GPT creation stops. Building a plugin needs the Use plugins permission and Plugin Creator available in your workspace. Adding your own MCP server as an app needs developer mode, which OpenAI lists for Pro, Plus, Business, Enterprise and Education accounts on the web.

The custom GPT retirement

OpenAI’s guide to moving custom GPT workflows to plugins↗ (opens in a new tab) describes a plugin as a reusable package for a workflow that can include skills, apps, or both. A skill explains how to do a task; an app connects ChatGPT to another service. Migration maps a GPT onto that shape.

• Instructions become a skill, and knowledge files come across as reference files in it.
• Connected apps remain part of the plugin, with the same app permissions as before. Installing a plugin does not add access to the service.
• Custom actions do not transfer. OpenAI says to rebuild them with a supported app’s read or write actions, or a custom MCP server.
• The selected model does not carry over, and capability settings do not guarantee the same tools or behaviour.
• Conversation starters do not transfer one-to-one, and previous chats may not copy.
• Sharing is not copied. The new plugin starts private, and you share it again, even with people who could already use the GPT.

After migration the original GPT becomes read-only and stays usable until retirement. At retirement, custom GPTs stop running and leave the GPT directory. OpenAI also says a GPT can still be migrated after the retirement date, although it will no longer run. Its guides are written for Enterprise workspaces and note that timelines and public sharing for other plans may differ, so check the notice in your own account for the date that applies to you.

How to migrate a GPT, step by step

1. Decide what to keep. List your GPTs, who uses each and what it does. Leave behind the ones nobody opens.
2. Save evidence before you change anything: a few familiar prompts with good results, and one harder case, so you can compare the replacement.
3. Finish important edits and publish the GPT if it is still a draft. Migration uses the published version, and it must be published to migrate.
4. Open My GPTs, find the GPT under Created by me, and select Migrate to plugin. Only the GPT’s creator or a workspace owner or admin can do this, and plugins must be enabled for you.
5. Test the plugin with the saved prompts. Check it picks the right skill, uses the reference files, follows your format and handles the hard case. Try both selecting it with @ and a plain request, because automatic selection depends on the request.
6. Rebuild custom actions as an app’s actions or a custom MCP server, and test them with an account that has only the permissions your users have.
7. Share the plugin with the people who need it, ask one of them to install and test it, and update any guides that still point at the GPT.

OpenAI’s Build plugins↗ (opens in a new tab) guide covers editing the plugin afterwards with Plugin Creator: describe the workflow, attach a template or reference file, and refine the instructions in a conversation. Rerun your saved prompts after every change.

Which to build now

• You are researching, drafting or analysing the same material over weeks: a project.
• You want colleagues to run one procedure the same way, from their own chats: a plugin with a skill.
• The procedure needs live data or actions in another service: a plugin with a skill and an app.
• Your GPT called your own API through custom actions: plan the MCP server first, because that is the long pole.
• You are about to build a new GPT: do not. Build the plugin instead.

Where the work itself lives

Projects and plugins both shape how ChatGPT answers. Neither is a record of what is being worked on, who has it, or who changed what. A GPT that used custom actions to create tickets somewhere is a good example: after migration, that action has to become an MCP server anyway. fenbs is one such server, a small task board with lanes To Do, Next Up, In Progress and Completed. Where your plan offers developer mode, ChatGPT can add https://fenbs.ai/api/mcp as an app, sign in through your browser, and act under your role, with each change recorded in History under its own name. fenbs has no sprints, due dates or epics; it is a shared list of tasks, not a planning suite.