Blog

EmDash CMS Review: We Migrated a Real WordPress Site

Build By Brian Morrison | April 7, 2026 | Updated September 11, 2026 | 8 min read

Cloudflare just launched a CMS built to replace WordPress. It’s called EmDash, it runs serverless on Cloudflare Workers, and it claims to fix the plugin security model, the layer where Patchstack found 96% of new WordPress vulnerabilities in 2024 and 91% in 2025. That’s a bold pitch for a platform that powers over 42% of the web.

We wanted to know if it holds up. So we migrated a real WordPress site to EmDash v0.1.0: 147 posts, 30 pages, three custom plugins, a custom Tailwind theme, and 2.3GB of media. Not a test blog. A production site with real content and real complexity. Here’s what we found.

The problems EmDash is solving

EmDash exists because WordPress has structural problems that plugins and patches can’t fix.

The security model is the biggest one. WordPress plugins run with full access to the database and filesystem. A vulnerability in one plugin compromises the entire site. EmDash takes a different approach: plugins declare what they need access to upfront (similar to OAuth permissions) and run in isolated sandboxes. A broken plugin can’t touch anything it didn’t ask for. That’s an architectural fix, not another security plugin bolted on top.

The infrastructure model is the other. WordPress requires a PHP server and a MySQL database, provisioned and maintained whether your site gets ten visitors or ten thousand. EmDash’s best-supported path is Cloudflare Workers with D1 and R2, where it scales to zero when idle and there are no servers to patch. It also runs on any Node.js server with SQLite or PostgreSQL, where you manage the server as you would for WordPress.

The technical foundation is built on Astro, TypeScript, and Tailwind. If those names don’t mean anything to you, the practical difference is this: modern component-based development instead of PHP templates, with better tooling for the team maintaining your site long-term.

The problems are real. The question is whether EmDash’s answers are ready.

What worked well

Content transferred cleanly. The import wizard brought over all 147 posts and 30 pages without data loss. WordPress’s block content converted to EmDash’s format automatically, and custom post types became EmDash collections on import. For sites with large content libraries, the content migration is usually the part that kills a project. Here, it worked.

Styling carried over directly. Because our WordPress theme was already built on Tailwind and we used Tailwind again in the new Astro theme, the utility classes transferred 1:1 without a build tooling change. Only the template language changed (PHP to Astro components), not the look and feel. Custom CSS and custom classes work fine either way. The Tailwind overlap just meant one less thing to reconfigure during the migration. A site on a standard PHP theme will not get this: its CSS is rebuilt along with the templates.

The developer experience is a genuine upgrade. Composable components with typed props instead of PHP template files. Parallel data fetching instead of sequential WordPress queries. For a team maintaining a site over years, this is where modern architecture pays off. Not in the initial build, but in every change after it.

The plugin security model works as advertised. Plugins declare capabilities, run in isolation, and can’t access the database directly. This addresses WordPress’s core security problem at the architecture level. For site owners who’ve dealt with plugin vulnerabilities (or the anxiety of not knowing which plugin will be next), this is the feature that matters most.

Where it falls short

The content model is more structured, for better and worse. EmDash pages are composed from typed content blocks rather than the ad-hoc field groups and drag-and-drop builders WordPress editors are used to. The upside: the content model is explicit, consistent, and easier to maintain over time. The downside: every custom content type needs block development upfront. WordPress gives editors maximum flexibility by default at the cost of developer control. EmDash inverts that, giving developers full control at the cost of requiring more setup before editors can work independently.

In v0.1.0, content types already had image, file, reference and multi-select fields, but the Block Kit that plugins use for their admin screens was limited to text, number, select, toggle, checkbox, radio, date and secret inputs: no media picker, no repeating lists, and no custom element types. (Update: Block Kit gained repeater and media picker elements in 0.8 and 0.9, and content types gained a repeater field.)

No plugin ecosystem. WordPress has 60,000+ plugins. EmDash has effectively zero third-party plugins. SEO tools, contact forms, analytics integrations, caching, security scanning: all of these need custom implementation, or you wait for a third-party plugin ecosystem to develop. For most WordPress sites, the plugins are the product. They’re the reason the site does what it does without custom development. Losing them is a restart rather than a tradeoff.

v0.1.0 rough edges. Sparse documentation (we relied on reading source code more than once) and a bug in the visual editing toolbar that required patching. Expected for a first release, but it means your team is spending real time on workarounds that shouldn’t be necessary in a production tool.

“Migration” means rebuild

Every PHP template needs to be rewritten as an Astro component. WordPress hooks, shortcodes, and the template hierarchy have no equivalent in EmDash. Custom plugins need full rewrites. The content transfers, but everything around it (templates, functionality, integrations) gets rebuilt from scratch.

In terms of scope and budget, a WordPress-to-EmDash migration is closer to commissioning a new site that reuses your existing content. The timeline and cost should reflect a full build, not an upgrade or a platform switch. If you’re getting estimates, make sure they account for template rewrites, plugin replacements, and integration work. A quote that treats this as a platform switch is missing most of the project.

A platform migration is the extreme version of a more common problem: the architecture a site was built with determines whether updates are a refresh or a rebuild. The same patterns that make a WordPress site expensive to leave (content embedded in HTML, no reusable components, plugin glue holding the templates together) are what make any site expensive to redesign on the platform it’s already on.

If you’re weighing that rebuild cost against staying on WordPress or moving to something else entirely, the decision is less about the platform and more about whether your needs have outgrown it. We cover that calculation in when to build a custom web app vs. use off-the-shelf tools.

Who should care right now

Starting a new project from scratch? EmDash is worth serious consideration, especially if you’re already in the Cloudflare ecosystem. The Astro foundation, serverless deployment, and security model are genuinely strong. The tradeoff: thin documentation, no plugin ecosystem, and v0.1.0 rough edges. If your team can handle that, the technical foundation is sound.

Running an existing WordPress site? Wait. The migration effort is a full rebuild, the plugin ecosystem doesn’t exist, and the content block system needs more input types before editors can work as independently as they do in WordPress. Revisit when EmDash ships a plugin marketplace, richer block development tools, and a more mature editing experience. If your WordPress site has become slow or fragile, the fix is usually building WordPress properly: a custom theme and custom blocks instead of plugin sprawl, not a new platform.

Evaluating CMS options in general? Put EmDash on your watch list. The architecture is the most thoughtful WordPress alternative we’ve seen. If Cloudflare builds out the plugin ecosystem (marketplace, community adoption, content tooling), this could become the default recommendation for content-heavy sites within a year or two. It’s not there today.

The gap between foundation and ecosystem

The architecture is right. The security model solves a real problem. The developer experience is a genuine improvement over WordPress’s PHP foundation. None of that is in question.

What’s missing is everything that grows around a CMS over 20 years: the plugins, the themes, the community answers on forums, the agencies that know it inside out, the documentation that covers every edge case. WordPress has all of that. EmDash has a strong v0.1.0 and Cloudflare’s resources behind it.

That gap will close. How fast depends on whether Cloudflare can attract plugin developers, ship content tooling improvements, and build the kind of ecosystem that makes site owners confident enough to switch. We’ll be testing each major release as it ships. If that support catches up to the architecture, this changes the CMS conversation entirely.

Have a project like this?

Tell us what you're building. We respond within one business day with scoping questions and a rough plan.