Upgrading production on day one isn't staying current. It's volunteering your clients for QA.

WordPress 7 can wait.

Upgrading production on day one isn’t staying current. It’s volunteering your clients for QA.

Minor and security releases are one thing. A major platform release is different.

This month I sent a client a slightly different maintenance note than usual. Their site is current, stable, and up to date from a security standpoint, but we’re not moving them to the newest major WordPress release immediately.

We’re gonna defer until next month.

WordPress 6.9.4 is stable. It’s patched. It’s fine.

This isn’t about avoiding updates. It’s about when.

A WordPress release doesn’t arrive alone

A major WordPress release lands in the middle of a much larger system: themes, plugins, custom code, hosting layers, build processes, caching, integrations, and editorial workflows.

Some of that ecosystem will be ready on day one. Some of it won’t.

There will be patches. There will be plugin updates. There will be theme fixes. And there will be edge cases nobody caught until real production sites started breaking in interesting ways.

That doesn’t make WordPress uniquely bad. It makes WordPress a platform with an enormous number of possible configurations, maintained by people and organizations that don’t all ship on the same schedule.

A successful core release tells you WordPress is ready to ship WordPress. It doesn’t tell you every combination of code running on your client’s website has been tested against it.

And if you’re responsible for that website, the second question is the one that matters.

Thirty days isn’t thirty days of doing nothing

The idea isn’t to ignore a major release for a month and then blindly click Update.

It’s to use that window deliberately.

• Read what changed. Review the release notes and field guide, especially anything affecting functionality the site actually uses.
• Review dependencies. Look at plugin and theme changelogs, compatibility notices, and known issues. A compatibility badge alone isn’t a test plan.
• Test the site locally and in staging. Check the critical paths: forms, authentication, custom functionality, integrations, search, editorial workflows, and whatever else would be expensive to break.
• Watch the early fixes. Let the first wave of real-world deployments surface the problems that don’t appear in release candidates.
• Know how to recover. Have a backup and a credible rollback plan before touching production. A major upgrade may involve database changes, so rolling back isn’t always just restoring the previous code.

This is maintenance work. It is what the client is paying us to think about, even when the best outcome is that nothing exciting happens.

You don’t have to wait exactly thirty days every time. Some upgrades will be ready sooner; others will need more work. The point is to make timing a conscious decision based on the system you’re responsible for.

Security updates are not part of the waiting game

This is where people tend to conflate two different responsibilities.

Delaying a feature release is not the same as delaying a security patch.

When a relevant security update becomes available, it needs prompt attention. The risks of leaving a known vulnerability unpatched are very different from the risks of waiting a few weeks before adopting a new major version.

WordPress 6.9.4, for example, shipped in March as a security release. That’s the kind of update that belongs in the immediate maintenance conversation, not at the end of an arbitrary thirty-day timer.

This isn’t a philosophy of staying old. It’s a philosophy of staying responsible.

Managed hosting can shorten your runway

Some teams don’t have complete control over when a major version lands. Managed WordPress hosts have their own rollout schedules, testing processes, and deferral limits.

I’m looking at you, WP Engine.

To be fair, WP Engine documents a thirty-day deferral option for major core updates. That’s useful, but it also illustrates the constraint: eventually the host’s schedule becomes part of your deployment schedule.

If you have the ability to control the upgrade, use it. If you don’t, understand the host’s policy early, put the deferral in place when appropriate, and make the time available count.

And if your production environment is still somewhere people install plugins or make ad hoc code changes, that makes the entire process harder. I’ve written about why production WordPress should be read-only. A major upgrade ought to be a tested deployment decision, not a surprise event in an environment nobody can reproduce.

Your client’s website is not a relevance test

WordPress is in a weird cultural moment. Half the internet is trying to prove it’s still relevant; the other half seems eager to declare it obsolete.

It’s tempting to treat every major release as a relevance test. Look at the new features. Look how quickly we upgraded. Look how current we are.

But production websites are not relevance tests. They’re operating systems for businesses.

If a site needs a new WordPress 7 capability immediately, fine. Make the case, test the dependencies, and ship it with your eyes open.

Most sites don’t need that. They need their forms to keep working. Their editors to keep publishing. Their integrations to keep moving data. Their deployments to stay predictable.

This is also why our broader WordPress maintenance and security philosophy matters. Maintenance isn’t measured by how quickly a version number changes. It’s measured by whether the system remains secure, supportable, and dependable.

Give the ecosystem a few weeks to absorb the release. Test it locally. Test it in staging. Read the plugin changelogs. Watch the patches. Then move deliberately.

Waiting thirty days on a major release is not fear. It’s production discipline.