If you run a WordPress site, you have probably lived through a plugin update that broke the homepage, or a security scare that sent you hunting for patches. That is not bad luck; it is how classic WordPress plugins are built. They share the same runtime and database as your site, so one sloppy extension can touch everything.
Cloudflare recently announced EmDash as an open-source, MIT-licensed CMS they describe as the “spiritual successor” to WordPress. It is early software (v0.1.0 preview), but the direction matters: keep the publishing model people understand, fix the security and hosting model underneath, and make content work easier to automate—not only through wp-admin.
What EmDash actually is
EmDash is a new content system written in TypeScript, powered by the Astro framework for the public site, and designed to run serverlessly (including on Cloudflare’s network) or on ordinary Node.js servers you control.
The important distinction is architectural:
- Themes shape how pages look—similar to WordPress themes, but without giving theme code open access to your database.
- Plugins add behaviour (emails on publish, integrations, custom blocks)—but each plugin runs in an isolated sandbox and must declare upfront what it is allowed to do (read content, send email, call a specific web address, and so on). In practice: you approve what each add-on can do before it runs.
- Content still lives in familiar shapes—posts, pages, media—but custom content types can be defined without bolting on heavyweight field plugins.
EmDash also ships with agent-friendly tooling: a CLI, a built-in Model Context Protocol (MCP) server on each instance, and “skills” that help coding agents understand how to extend the site safely. That sits in the same lane as the MCP integration work we already do for line-of-business systems—here, aimed at the CMS itself.
Why the plugin model needed rethinking
WordPress’s plugin marketplace solved trust at scale, but the underlying model is brittle. In its launch post, Cloudflare cites Patchstack figures: most serious WordPress incidents trace back to plugins, not core WordPress itself.
EmDash’s answer is capability-based permissions declared in a manifest before you install anything—closer to approving scopes in a modern app than to “install and hope.” For organisations tired of vetting plugins, staging breakages, and emergency patches, that is a real change in how you approve extensions—even if you never read a line of code.
Migration: what moves and what needs a plan
Cloudflare documents two import paths:
- Export a standard WordPress WXR file from wp-admin and import it into EmDash.
- Install the EmDash Exporter plugin on the WordPress site for a secured export endpoint (protected with an application password you control).
Cloudflare says migrating posts, pages, and attached media often takes minutes for typical blogs. Harder work shows up where WordPress was stretched:
- Custom post types from Advanced Custom Fields or similar need mapping into EmDash collections (schemas you define in the admin).
- Bespoke page builders and shortcodes do not translate literally—you rebuild layout in Astro components or EmDash blocks, often with agent assistance.
- WooCommerce-scale commerce is not a like-for-like swap in a v0.1 preview; treat commerce migrations as a separate discovery.
Migration is still sensible; scope it honestly: content first, design second, integrations third.
When EmDash is a sensible bet
EmDash is worth a serious look if you want faster global delivery without running PHP servers and cache plugins, if security and compliance stakeholders are nervous about plugin supply chains, if your team (or agency) is already comfortable with modern frontends, or if you are planning a rebrand or rebuild anyway—migration cost is already on the books.
Stay on WordPress a while longer if deeply customised membership, marketplace, or ERP-linked workflows only exist as fragile plugin stacks—and those integrations are still earning their keep. We argued the same trade-off in WordPress is dead: the question is not loyalty to a logo, but whether the stack still matches your risk and roadmap.
What a migration actually involves
The work that stalls projects is rarely the export button—it is schema mapping, theme rebuild, redirects, SEO parity, and cutover testing. A typical migration with us looks like this:
- Inventory what must survive (URLs, forms, memberships, analytics, editorial workflows).
- Migrate content via WXR or the exporter plugin, then validate media and metadata.
- Rebuild the theme in Astro/EmDash so performance and accessibility are intentional, not accidental via plugins.
- Replicate must-have behaviour with sandboxed plugins or small integrations—not a trolley of legacy PHP.
- Cut over with monitoring, redirects, and a rollback plan.
EmDash is young. We will tell you plainly if preview limitations block your timeline, and we will not pretend a migration erases every WordPress customisation on day one.
For background, read Cloudflare’s Introducing EmDash post and browse EmDash on GitHub.
If you want a straight read on whether your site suits EmDash—or help scoping a migration—talk to us.