After PressConf 2026, the most important question wasn't what these platforms could do. It was when they could be trusted.

If you’re running an enterprise WordPress site, ignore the hype: WordPress 7 and EmDash aren’t ready for your production environment.

Last week at PressConf 2026 in Tempe, Arizona, two subjects dominated nearly every conversation: AI in WordPress, particularly around the delayed WordPress 7 release, and Cloudflare’s newly announced EmDash.

I spent much of the week talking with product teams, platform folks, and other agencies about where WordPress is headed. There’s real innovation happening. There’s also a lot of confusion about how close any of it is to being ready for a site with real-world consequences.

A compelling demo isn’t a production strategy. And when you’re responsible for an enterprise site, being first is rarely a benefit.

WordPress 7: a release that isn’t ready to ship

WordPress 7 is being framed partly as a milestone in the platform’s AI direction. The planned release includes a provider-agnostic AI Client in core, giving developers a consistent interface for working with AI providers.

That’s useful foundational work. But an API in core doesn’t suddenly make AI-driven editorial workflows mature, secure, or appropriate for every enterprise deployment.

More importantly, the immediate release problem isn’t simply that AI features need polishing.

On March 19, the first release candidate was delayed over several concerns, including real-time collaboration performance. On March 31, WordPress extended the entire 7.0 release cycle. By April 2, contributors were explaining the need to revisit the architecture behind real-time collaboration, even though the project had already entered its release-candidate phase.

That’s not a minor bug fix. When a major feature needs architectural work this late in the cycle, the release isn’t ready. It’s that simple.

To the WordPress team’s credit, delaying the release is the right engineering decision. But that’s also the signal enterprise teams should pay attention to. If the people building the platform aren’t comfortable shipping it yet, I’m certainly not going to rush it onto a client’s production site the moment it becomes available.

We’ve been through this with Gutenberg

Anyone who remembers the Gutenberg rollout should recognize what’s happening.

Gutenberg was a substantial change to how WordPress worked. Many of the ideas were the right direction. But replacing the editing experience wasn’t a small change for teams with years of existing content, custom fields, bespoke integrations, editorial conventions, and plugins built around the classic editor.

The technology could move forward while the surrounding ecosystem struggled to keep up. And for most clients, the experience of using WordPress is determined by the entire ecosystem, not just core.

AI is going to follow a similar path. Core APIs arrive. Plugins begin integrating them. Editorial teams experiment. Permissions, review processes, security practices, and reliable patterns take longer to settle.

There’s nothing wrong with any of that. That’s how platforms evolve. But new capabilities aren’t the same thing as a stable operating model, and enterprise clients shouldn’t be expected to absorb that uncertainty just to stay current.

EmDash: interesting architecture, no enterprise ecosystem

Then there’s EmDash.

Cloudflare introduced EmDash on April 1 as a modern, open-source CMS built with TypeScript and Astro, with an emphasis on isolating plugins and limiting their access to the rest of the application.

Architecturally, I like some of what they’re proposing. WordPress plugins have extensive access to the application, and that creates legitimate security and maintenance problems. A capability-based plugin model is worth exploring.

But EmDash is a v0.1 developer preview, not a production replacement for an established enterprise WordPress site. There’s no mature plugin ecosystem, no proven body of integrations, no broad hosting and operational knowledge base, and no years of real-world compatibility to lean on.

EmDash does offer ways to import WordPress content through WXR files or an exporter plugin. That’s useful, but let’s be clear about what that solves: importing content is not migrating an application.

What happens to the custom theme? The page-builder components? The plugin-specific behavior? The SSO integration? The deployment pipeline? All the small decisions accumulated over years that make a particular website work for the people running it?

Those things don’t disappear because the posts and pages imported successfully. For a heavily customized WordPress site, moving to EmDash means rebuilding or replacing much of the system.

And even after that rebuild, somebody has to operate it. Hosting support, developer familiarity, editorial training, maintenance, troubleshooting, and the availability of people who can work on the platform are all part of the cost.

WordPress has spent more than two decades building that ecosystem. An elegant architecture doesn’t replace it overnight.

Enterprise readiness is an operating question

A platform doesn’t become appropriate for a business-critical site because someone gave an impressive demonstration or published a release announcement.

When I’m responsible for a production website, I need answers to the boring questions:

None of that is particularly exciting. It’s also what determines whether the site keeps working six months after the launch celebration.

Early adopters have an important role. They try new things, discover edge cases, report bugs, and help shape the tools everyone else will eventually use.

But that’s not the job my enterprise clients are hiring me to do. They’re paying me to make sound technical decisions and keep their systems reliable. I don’t need to turn a revenue-critical website into somebody else’s test environment.

My recommendation: wait

I’m advising clients not to upgrade to WordPress 7 on launch day.

That doesn’t mean ignoring core updates, deferring security patches, or refusing to evaluate new features. It means testing against actual client implementations, watching what happens in the wild, and giving the theme and plugin ecosystem time to settle before treating a major new release as routine maintenance.

EmDash is a different proposition entirely. Moving an established WordPress site to another CMS isn’t an update. It’s a migration project, potentially a full rebuild, and the upside has to justify that investment.

Could EmDash be worth experimenting with on a greenfield build or a disposable prototype? Absolutely. That’s precisely where emerging technology belongs while its capabilities and ecosystem develop.

But experimentation and production adoption aren’t the same decision.

What’s next isn’t always what’s ready

The theme running through PressConf is that WordPress is changing, and the wider CMS landscape is changing with it. AI is going to reshape parts of the workflow. New architectures will challenge old assumptions. Some of those changes will be genuinely valuable.

But new platforms deliver possibility long before they deliver predictability. And predictability matters when a site supports real customers, real employees, and real revenue.

WordPress isn’t perfect. I spend enough time in it to know exactly where it falls short. EmDash is worth watching. WordPress’s AI work is worth following. None of that gives me a reason to gamble with a client’s production environment.

The job isn’t to chase what’s new. It’s to know when something is stable enough to trust.

For WordPress 7 and EmDash, we’re not there yet.