Payload CMS 4: when should you migrate from Payload 3 to Payload 4?

If your site runs on Payload 3 and someone has asked when you are moving to 4, the short answer is: not now, and nobody can tell you when. Payload 4 is in beta. No stable release date has been announced. Your site is not behind.

The longer answer is more useful, because version 4 includes one thing that actually changes the day to day of a team that publishes: an MCP rebuilt from scratch. More on that below.

Payload has given no day, month, or quarter for the stable release. The beta is for trying things. A site that publishes stays on Payload 3.

Does Payload 4 have a release date?

No. That is not a cautious line: there is no announcement.

Before the beta, the Payload team said one thing about timing: they wanted a shorter path from beta to stable than for version 3. No season, no deadline. Since the beta opened, the official message is that the full release is still in progress, and that feedback is welcome.

If you read a date somewhere, it comes from a third-party article or a discussion thread, not from Payload. The day the stable release ships, we will update this paragraph.

Should you move to Payload CMS v4 now?

No, and this is not a question of technical courage.

A beta moves. The admin is still changing, and so are some behaviors. Installing that on the site your team opens every morning to publish means taking on adjustments you do not need.

Payload 3 is the stable version. That is where fixes ship today. Staying on it is not falling behind. It is the normal choice for a site in production.

What Payload CMS 4.0 changes for your team: the MCP

The visible changes in Payload 4 (redesigned admin, media library, folders) are covered in Payload CMS 4.0: what to expect, and what's next. One topic is worth stopping for here, because it concerns the people who publish: the MCP.

The MCP is the door through which an AI assistant (Claude, Cursor, ChatGPT, or an internal agent) reads and writes in your CMS. In practice: "write three variants of this product page from the spec sheet", "find every article that mentions this client and update the name", "create the pages for the new range from this spreadsheet". The assistant works inside Payload, with your content models, your fields, and your rules.

In Payload 3, this MCP already existed, but setting it up took a developer and several steps: turning on each collection one by one, creating keys, setting permissions, configuring the client. Payload itself said it was too heavy.

In version 4, it was rebuilt with the opposite logic. Here is what changes, according to Payload's documentation:

• Available by default. Every collection and every global is open to the assistant with no setup. You remove what you do not want to expose, instead of adding what you want to open.
• No API key in development. A developer connects an assistant in a few minutes to test it.
• Instructions for the AI, per content type. You can write, directly in the admin, the rules the assistant must read before creating or editing content: tone, length, required fields, what it must never touch. The assistant receives them along with the content structure.
• Payload permissions still apply. An assistant connected with an editor account cannot do more than an editor. It cannot delete what that account is not allowed to delete.
• Files go through too. The assistant can add images and documents to the media library, with the same format and size checks you already use.

For a marketing team, that is the real case for version 4. Not a prettier admin: a CMS where an AI can work cleanly, inside your rules. If you wondered what an AI agent connected to Payload looks like day to day, that is exactly what version 4 makes simple to set up.

When should you move to Payload v4?

When two conditions are true at the same time.

The first is out of your hands: Payload publishes 4.0 as the stable version.

The second is yours: the team gains something concrete. Three situations are enough.

• You want an AI working on your content, with rules, without opening a configuration project. The MCP in version 4 is built for that.
• An important fix ships only for version 4. That day, the upgrade becomes maintenance, like a security update.
• A redesign is already decided. The version bump fits inside it. It does not justify a project on its own.

None of these? Keep publishing on version 3. That is the right call.

The day you say yes, what does it look like?

On the content side, almost nothing. Pages, articles, and media stay in place. Visitors do not see a new site.

On the team side, a new admin, and everyone signs in again. Plan half an hour with the people who publish, on the three things they actually do: publish a page, upload an image, find an article.

On the project side, a bounded window. Someone backs up, runs the upgrade on a copy, checks that publishing, forms, and the MCP if you use it all respond, then switches over. It is not a button in the admin. It is not a redesign either. The quote depends on what is specific to your site: a custom admin, several languages, automations.

Who decides, and who does the work?

You decide. The useful question fits on one line: does the team publish better afterwards?

The upgrade itself is developer work. A developer, or an AI in the code, handles the mechanical part. What nobody does for you after that: choosing the moment, warning the editors, checking that the published site behaves as before, and writing the instructions the AI should follow in your CMS.

Beease takes that part once you have decided. An inventory of what is specific to your site, an upgrade on a copy, a check with you, then the switch once the stable release is available. Until Payload 4 is that version, we will not offer to install it in production.

We handle the upgrade when the time comes

Payload CMS

Upgrade

You choose the moment. We run the Payload 4 migration once the stable release is out, and we set up the MCP with your rules.

Book a call

For a view of your site before you raise it internally, ask for an audit.

FAQ

Does Payload 4 have a release date?

No. No stable date has been announced, neither a month nor a quarter. The beta is public, and the full version is still in preparation.

Is a Payload CMS site still on version 3 out of date?

No. Version 3 is the stable release and it still receives fixes. A site can stay there while version 3 is maintained, and while version 4 does not solve a problem the team already has.

What does the Payload 4 MCP change for a marketing team?

An AI assistant can read and write in the CMS without a heavy setup, while respecting each account's permissions and the instructions written in the admin for each content type. You can give it drafting, bulk updates, or page creation, inside your rules.

Should you talk to your vendor now?

So they know the topic exists, yes. To start the work, no. One question is worth asking today: what is specific about our site on the day the stable release ships?

Book a call with Martin

Co-founder

Twenty minutes to look at your Payload site and say whether a move to version 4 is worth it, and when.

Book a slot with Martin