Get concise advice on choosing the right CMS, understanding migration costs, and avoiding expensive implementation mistakes before they become roadmap problems.
Product manager, designer, or the person who signs off on the website budget?
This is the guide for you. It explains what Payload 4 means for your team, your budget, and your risk, without a line of code. If you are the developer, the technical breakdown of Payload 4 is the one you want.
The short answer
Payload 4 is the next major version of the CMS, and it is not finished. As of October 2026 it exists only as test builds. The most recent stable version is still Payload 3.
So here is what that means in practice:
Nothing needs to happen this quarter except planning. Your site is fine where it is.
The benefits are real, and they are mostly about the editing experience and safer defaults.
The cost is the upgrade itself, not the software. Payload is free to use, but moving a real site to a new major version is a project.
Waiting is a legitimate decision, not a failure to keep up.
The rest of this article explains each of those points so you can decide for yourself, and ask the right questions when your developer or agency brings it up.
What is changing, and what it means for you
Most of the Payload 4 announcement is written for engineers. Translated into business terms, the changes fall into a handful of outcomes.
Diagram
Each change on the left has a business reason behind it. The sections below explain the trade-off that comes with each one.
Safer by default
In Payload 3, code running inside your own site could read and change content while ignoring your permission rules, unless a developer remembered to switch the rules on. In Payload 4, the rules apply unless a developer deliberately says otherwise.
That is a real security improvement. It reduces the chance that a custom form, a scheduled task, or an internal tool quietly exposes data it should not.
The trade-off is that anything built on the old behavior needs to be reviewed. Imports, scheduled jobs, and internal tools that relied on the shortcut can stop working, or return empty results, until a developer fixes them.
Content history on by default
Payload 4 keeps a history of changes for your content automatically. In Payload 3 you had to switch this on collection by collection. That gives you an undo button and an audit trail: what changed, and what it looked like before.
Two things to know. First, it adds database tables, so it is a database change you should plan for. Teams with very large, high-turnover data can opt out for those areas. Second, content history follows the same viewing rules as the content itself. If a page is publicly readable, its old versions can be too, unless your developer restricts them. If you have content that was once public and later pulled back, ask about this.
Drafts and scheduled publishing are a separate setting and remain off by default.
A better admin for editors and designers
The admin panel gets its biggest redesign since Payload 3. Folders and tags are built in, so editors can organize pages and media into trees instead of paging through long flat lists. For large content libraries, that is the difference between finding something in seconds and giving up and asking a colleague.
Lists also load faster on big collections, because the admin now fetches only the columns an editor is actually looking at.
For designers, rebranding the admin gets simpler. Colors, radius, and borders are controlled by a shared set of design settings rather than hand-written stylesheets. If you want custom screens inside the admin built with modern styling tools, those no longer clash with the admin's own styles.
AI assistants that work with your content
Payload 4 has first-class support for connecting AI assistants to your CMS. The assistant acts as a specific user and is held to that user's permissions.
One caution. In Payload 4, the built-in content tools are switched on automatically unless someone turns them off. That is not a security hole, since permission checks still apply, but it is a decision. Ask your developer what is exposed to AI tools on your site, and whether that matches what you intend.
More flexibility in the technology around it
Payload 4 starts to separate the CMS from the framework it runs in. Next.js remains the main, proven path. Support for an alternative, TanStack Start, exists only as an early experiment.
If you are not already thinking about changing your website framework, ignore this one for now. It is a sign of direction, not a reason to move.
A scenario: someone published the wrong price
This is where content history stops being abstract.
An editor updates a product page and accidentally publishes the wrong price. On a site without content history, the fix is a developer digging through a database backup, or an editor trying to remember what the old number was.
Diagram
With history switched on, the fix takes minutes and does not need a developer. This only works for content types where history is enabled, so choose them deliberately.
What this means for your role
If you are a product manager
You have nothing to schedule until a stable release exists. What you can do now is ask for a trial upgrade estimate, so that when stable lands you already know the size of the project. Also list the workarounds you maintain today, such as extra plugins for folders or page trees. Some of them may become unnecessary.
If you are a designer
Expect a refreshed admin interface that your editors will need a short time to get used to. If your brand lives inside custom admin screens, plan time to check them against the new styling system. The upside is that theming becomes easier, and custom views are less fragile.
If you are a business owner
Your decisions are timing and risk. The safe default is to stay on Payload 3 in production, plan the move, and schedule it for when a stable release exists and your business calendar has room for it. If your team handles sensitive data, the safer permission defaults are a good reason to want Payload 4 eventually.
Payload is open source, so there is no licence fee. The cost is the time to move your site safely. A few things decide how large that is:
Diagram
A site with little custom code is a small project. A site with many integrations, scheduled jobs, and custom admin screens is a larger one. A trial upgrade on a copy of your site turns this into a real number.
An automatic tool handles many of the mechanical changes. It does not make the judgment calls: which jobs should bypass permissions, which content types should keep history, and whether a generated database change is safe to apply. Those still need an experienced developer.
Two further items catch people out. Payload 4 needs newer versions of the software your site runs on, so your hosting may need an upgrade. And if your content is still stored in Payload's older text editor, that content has to be converted before you can move.
I won't give you a price here. Anyone who quotes a number without looking at your site is guessing.
The path to a safe rollout
The sensible route is a gated one. Nothing touches production until a stable version exists and you have seen a trial on your own data.
Diagram
The gate is the stable release. Everything before it is planning and learning, which costs far less than a rushed migration.
Should you upgrade? A decision guide
Diagram
Today you are on the "No" branch. The only question is whether your site is complicated enough to justify starting the trial early.
Questions to ask your developer or agency
Bring these to your next conversation. Good answers are specific to your site, not general reassurance.
Which parts of our site run custom code that talks to the CMS directly, and have they been checked against the new permission defaults?
Which content types should keep a history, and who should be allowed to see old versions?
Is any of our content still in the older rich-text editor, and what would converting it involve?
Are all the plugins we depend on ready for Payload 4?
What hosting and software upgrades would we need, and who owns them?
Can you run a trial upgrade on a copy of our site and give us an estimate before we commit?
Where to go from here
Payload 4 is a good direction, and it is not yet a decision you have to make. Stay on Payload 3, keep your site healthy, and use the waiting time to find out how big your upgrade would be.
