Payload 4.0 isn’t out yet, but the question already comes up in client conversations: should we wait for it, or move ahead now? The honest answer is that nobody can switch to something that hasn’t shipped. But the more interesting question isn’t the version number at all. It’s about the two ways teams react when a major CMS (Content Management System) release gets announced, and why both reactions quietly cost money.
Two reactions, two ways to lose money
Every time a platform we depend on announces a major version, we watch the same split happen, internally and with clients. One group wants to jump in immediately, eager to be first. The other decides to freeze and deal with it “later.” Both are mistakes, and we’ve seen the receipts. It’s part of why we bet on Payload for new builds in the first place: a platform we trust is still a platform whose major releases deserve a plan, not a reflex.
When Payload moved from version 2 to version 3, early adopters spent roughly six months finding bugs in production, on client sites, before the platform settled down. That’s emergency fixes, re-testing, and awkward client calls, paid upfront.
The freezers didn’t dodge that bill, they just deferred it. Payload had publicly committed, back in 2023, to keeping older versions patched for security issues. In practice, once version 3 landed, version 2 stopped receiving updates about six months later, including one serious, unpatched vulnerability. Standing still didn’t mean standing safe, it just swapped one risk for another.
What we actually know about Payload 4.0
Here’s the part that matters right now: 4.0 hasn’t shipped. The version every production site should run today is 3.88.0, released in August. What’s public for 4.0 is a handful of very early preview builds, meant for Payload’s own developers, not for anyone’s client project. Fewer than 2 in 100 Payload users have even opened one.
No release date has been confirmed either, not a month, not a season. Payload said they were aiming for a proper trial build “in the coming months.” That window is closing and nothing has landed yet, though it’s too early to call it missed.
One thing is already clear from the preview code: the core content engine, the part that runs every save and publish, isn’t changing. The admin interface is getting a full redesign instead, and early testing already points to a few concrete changes worth planning around:
- Custom-branded admin screens will need manual rework after the redesign.
- Some default settings are shifting, which could make existing content look like it has disappeared.
- A database change will retire certain multi-language backup snapshots, so multilingual sites should back up thoroughly before any future upgrade.
- Payload’s own migration tool will only auto-fix about one in five of the documented changes – the rest need a person.
Decide now, not later
A handful of choices shouldn’t wait for a release date:
- Budget for admin rebranding. Custom colours, logos, or layout tweaks in your admin UI will need manual rework once Payload 4.0 lands.
- Audit multilingual backups today, independent of any upgrade timeline. The snapshots at risk are tied to a database change, not to when you actually upgrade.
- Decide who owns the migration, internally or through a team that runs CMS migrations as a repeatable process, before a trial build appears rather than after.
- Set a monitoring habit, not a launch date. Someone should watch Payload’s release notes monthly, not wait for a marketing email.
What can genuinely wait
Not everything needs a decision today. Feature-by-feature evaluation of the new admin UI can wait until a real trial build exists, there’s nothing stable to test yet. Budget approval for the actual migration project can wait too, since nobody can scope work against a version that keeps changing shape. And picking an exact upgrade date is premature until Payload confirms one; forcing a date now just creates a deadline you’ll likely break.
One more thing that can wait: re-litigating your platform choice. A major version bump isn’t a reason to second-guess whether Payload is still right for you, that’s a separate, bigger decision covered in the CMS you pick first is probably the wrong one.
Also relevant: what staying too long on an outdated CMS actually costs you.
Why some Swiss teams move slower, and it’s not caution
We hear a common assumption: Swiss enterprise clients wait longer to adopt major versions because they’re inherently risk-averse. That’s not quite it.
No Swiss or EU law forbids a company from upgrading its CMS. What financial-sector rules actually require is that meaningful changes get properly documented, a paperwork requirement, not a permission one. And it’s worth being precise here: strict financial-oversight rules apply to banks, not to pension funds, which sit under different supervision, an easy but embarrassing mix-up in front of a compliance audience.
The real bottleneck usually sits somewhere else entirely: surrounding infrastructure, like server software approvals, that runs through a separate, slower internal IT process. If that approval cycle only runs once a year, delaying a decision by even twelve months can push the real go-live date out by two or three years.
A major version bump isn't a compliance problem, it's a paperwork problem. The real slowdown almost always sits in unrelated infrastructure approvals, not in the CMS decision itself.
A framework you can reuse for the next major release
Treat every major version announcement the same way, not just this one:
- Separate “decide now” from “decide later” the day the announcement drops.
- Ground every decision in what’s verifiably shipped, not roadmap promises.
- Assume the timeline will slip, and plan internal approvals accordingly.
- Keep watching after the dust settles, security support for the old version has a shelf life too.
The same logic applies beyond version bumps, too: if you’re already weighing an upgrade against a full relaunch, a major release like this is a good moment to make that call deliberately rather than by default.
This isn’t a one-time announcement to react to, it’s a live decision we’ll keep updating as Payload 4.0 actually takes shape. If you’re weighing whether your current setup is even upgrade-ready, that’s exactly where we can help as your Payload CMS agency.
What our clients ask us
FAQs
Is Payload 4.0 safe to use in production yet?
No. What’s public right now are early preview builds meant for Payload’s internal team, not production sites. Stick with the current stable release, 3.88.0, until a proper trial build appears.
