OpenAI is not simply replacing custom GPTs
OpenAI is retiring custom GPTs and steering users toward Projects, Skills, Plugins and MCP-based integrations. At first glance, that sounds like a standard product migration. In practice, it’s a much bigger change because custom GPTs brought several useful capabilities together in one place.
They could carry persistent instructions, use curated knowledge, call built-in tools, connect to outside systems and maintain their own identity. Just as important, every new conversation started fresh. A builder could configure the system once, keep the underlying setup private and distribute what felt like a finished tool. The replacement model breaks those functions across several different parts of the platform.
Projects solve a different problem
Projects are probably the clearest example. They’re designed around continuity, which is useful when someone is working on a long-running research project, transaction or strategy process. Even with project-only memory, conversations inside the Project can affect later conversations in that same Project.
That same continuity can become a liability when the goal is a reusable tool that should approach the same task independently each time. Imagine a system that reviews contracts, policies or proposals against a defined set of requirements. With a custom GPT, each new conversation begins without the history of the previous review. Move that function into a Project and yesterday’s analysis may now become part of today’s context. That changes more than where the tool lives. It changes how the tool behaves.
Shared Projects create another mismatch. They’re collaborative workspaces where members can see chats, files and instructions, and where context accumulates as people work. A custom GPT can operate very differently. It can be configured privately, distributed broadly and used by many people without those users sharing conversational history or seeing how the tool was built.
Skills help, but they don’t recreate the same environment
Skills solve part of the problem because they can package instructions, reference materials, code and repeatable workflows. That makes them useful for work that needs to behave consistently across different settings, but a Skill still runs inside a surrounding environment. The chat or Project in which it’s invoked can still influence the result.
For some uses, that’s an advantage. For others, it undermines the reason a custom GPT was chosen in the first place. Plugins come closer because they can combine Skills with tools and connected systems, and they may ultimately become more capable than custom GPTs. Even so, OpenAI warns that migrated workflows may behave differently and need testing. Custom GPT Actions also don’t simply transfer unchanged, so some integrations will have to be rebuilt using supported connectors or MCP servers.
The technical threshold is increasing
One of the strongest features of custom GPTs was that they gave sophisticated nontechnical users a way to build something surprisingly close to an application without having to become software developers first. GPT Actions were a good example. A non-technical custom GPT builder could connect an outside API using an OpenAPI schema and authentication, all from within the GPT builder. Replacing that with “build an MCP server” isn’t an equivalent experience. It may be better architecture and may ultimately be more flexible, but it raises the technical threshold substantially.
The broader replacement model has the same issue. Projects handle continuity, Skills package reusable behavior, Plugins bundle functionality, and connectors and MCPs handle external systems. Taken together, that can be a powerful architecture. But instead of configuring one tool, builders now have to decide which pieces they need, assemble them correctly and test whether the result still behaves the way the old system did.
For experienced technical teams, that may be manageable. For sophisticated nontechnical builders, it’s a meaningful change in what the platform asks of them.
For some organizations, this is reengineering
If a custom GPT is little more than a prompt and a few files, the transition may be fairly straightforward. Many organizations, however, have gone much further than that. Their custom GPTs have become internal research tools, onboarding systems, policy assistants, document reviewers and other lightweight applications.
In those cases, moving away from custom GPTs isn’t simply a matter of copying instructions into a new place. Organizations may need to inventory what each GPT actually does, decide where those functions belong in the new architecture, rebuild anything that doesn’t transfer, test for behavioral differences and retrain users.
Some will come out of that process with better systems. Others may find that what replaces their GPT is more fragmented, more technical or simply less well suited to the job they were already doing.
That’s why calling this a migration understates what’s happening. For many of the most sophisticated custom GPTs, OpenAI is effectively asking builders to take apart a working system and build it again.
For many, this is going to create real disruption. For us too, but of course, this is what we do. So, if you could use help, HIA is here for you. Just reach out at consultations@hiaadvisors.com.