Cloudflare recently released EmDash 1.0, an open-source CMS built around Astro and TypeScript.
It comes with an admin interface, structured content, media management, localization, APIs, a CLI, a plugin system, and even an integrated MCP server.
That sounds promising.
But the interesting question is not whether EmDash is a new “WordPress killer”.
The real question is:
For which projects does an Astro-based CMS like EmDash actually make more sense than WordPress?
And if you already have a WordPress website, what does migrating to EmDash really involve?
TL;DR
EmDash 1.0 looks particularly interesting for:
- custom Astro websites
- TypeScript-heavy projects
- structured-content platforms
- multilingual sites
- projects where developers want full control over the frontend
WordPress still has a major advantage when a project depends on:
- a large plugin ecosystem
- WooCommerce
- page builders
- LMS or membership plugins
- mature third-party integrations
The biggest mistake would be to treat a WordPress → EmDash migration as a simple content import.
In many cases, it is closer to a technical rebuild.
What is EmDash?
EmDash adds CMS capabilities to an Astro project.
Instead of starting with a traditional CMS and building the frontend inside it, the architecture is closer to:
Astro
↓
Your frontend
↓
EmDash CMS
↓
Structured content / database / media
Astro remains the foundation of the application.
EmDash provides the editorial layer.
That distinction matters.
With WordPress, the CMS is usually both the runtime and the content platform.
With EmDash, your Astro project stays at the center of the architecture.
For teams already working with TypeScript, this can result in a much more consistent stack.
A TypeScript-first CMS architecture
One of the most attractive aspects of EmDash is that developers can stay inside a modern JavaScript/TypeScript ecosystem.
A project can combine:
- Astro for routing and rendering
- TypeScript for application logic
- EmDash for content management
- SQL-based storage
- local or S3-compatible media storage
- APIs and CLI tools for automation
That is very different from maintaining a WordPress installation containing PHP templates, JavaScript, multiple plugins and several layers of custom code.
But “different” does not automatically mean “better”.
It depends heavily on the project.
EmDash vs WordPress by use case
1. A custom marketing website
This is probably one of the most interesting use cases for EmDash.
Imagine a company website with:
- a custom design
- 20–50 pages
- a blog
- case studies
- team profiles
- a few forms
- multilingual content
With WordPress, this could involve:
- a custom theme
- Advanced Custom Fields or similar tooling
- SEO plugins
- form plugins
- multilingual plugins
- performance plugins
With Astro + EmDash, much of the frontend can simply be implemented as components while EmDash manages editable content.
For a development team already comfortable with Astro, this can be a very clean architecture.
2. A multilingual blog
EmDash also has an interesting approach to localization.
Translations can be managed as separate content variants with their own slugs and publication states.
This is useful when, for example, the English version of an article is published while the French translation is still a draft.
For a new multilingual project, that model is attractive.
Migrating an existing WordPress multilingual site, however, is more complicated.
A WordPress export does not automatically reproduce every relationship created by tools such as WPML or Polylang.
That means multilingual migrations need to be tested carefully.
3. A highly customized application
This is where EmDash becomes especially interesting.
Consider a website containing:
- custom content types
- business APIs
- application-specific forms
- structured relationships
- automation
- custom dashboards
- third-party services
At some point, a heavily customized WordPress project starts behaving more like a web application than a traditional CMS.
In that situation, using Astro and TypeScript directly can be attractive.
Instead of forcing application logic into WordPress hooks and plugin conventions, developers can build the application using the same tools they would use for any other TypeScript project.
4. A WordPress site with 20+ plugins
This is almost the opposite scenario.
Suppose a WordPress site relies on:
- WooCommerce
- Elementor
- an SEO suite
- advanced forms
- memberships
- analytics plugins
- newsletter integrations
- custom payment gateways
- several business-specific plugins
Moving that site to EmDash is not simply:
Export WordPress
→
Import EmDash
→
Done
Every important dependency needs to be reviewed.
For each plugin, you have to decide whether the feature will be:
- replaced by an EmDash feature
- replaced by another service
- implemented through an EmDash plugin
- rebuilt in TypeScript
- removed completely
This is why plugin inventory is one of the most important parts of migration planning.
What actually migrates from WordPress?
EmDash includes tooling for WordPress migration.
Content can be imported using WordPress export data, and EmDash also provides tooling designed to extract additional data from an existing WordPress installation.
Typical migration candidates include:
- posts
- pages
- custom post types
- taxonomies
- authors
- media references
- some metadata
But importing content is only one part of the project.
Your WordPress theme does not migrate
A PHP WordPress theme cannot simply be installed inside EmDash.
The frontend must be rebuilt with Astro.
For example, a WordPress template such as:
single.php
might become an Astro route similar to:
src/pages/posts/[slug].astro
The visual design can obviously be recreated.
The implementation is what changes.
In many projects, this is actually an opportunity.
A migration can be used to remove years of accumulated technical debt instead of reproducing an old WordPress architecture exactly.
WordPress plugins do not magically become EmDash plugins
This is another critical point.
Existing WordPress plugins are not directly compatible with EmDash.
Their functionality needs to be analyzed and, where necessary, ported or rebuilt.
For a custom WordPress plugin, developers may need to review things such as:
- hooks
- REST endpoints
- custom database tables
- cron jobs
- admin screens
- shortcodes
- blocks
- external integrations
Some plugins may no longer be required at all.
A caching plugin designed around a traditional PHP WordPress runtime, for example, might have no equivalent purpose in a completely different architecture.
The useful question is therefore not:
How do we migrate every plugin?
It is:
What functionality does each plugin provide, and do we still need it?
What about plugins in EmDash?
EmDash 1.0 also introduces its own plugin architecture.
One interesting part of the model is the ability to run some plugins inside isolated environments with explicit permissions.
That creates a different security model from the traditional WordPress approach where plugins frequently execute inside the same PHP runtime as the application.
EmDash also supports native plugins for features that require deeper integration.
The architecture is promising.
The ecosystem, however, is still extremely young compared with WordPress.
And that matters.
Ecosystem maturity is still WordPress' biggest advantage
WordPress has been around for more than two decades.
Its ecosystem includes:
- tens of thousands of plugins
- thousands of themes
- hosting providers
- agencies
- freelancers
- integrations
- documentation
- tutorials
- existing solutions for almost every common website requirement
EmDash 1.0 cannot reproduce that overnight.
So if your project depends heavily on ready-made functionality, WordPress still offers something extremely valuable:
maturity.
On the other hand, if you were going to build most of the functionality yourself anyway, the difference becomes much smaller.
A WordPress → EmDash migration is often a rebuild
For a professional project, I would approach the migration in roughly this order.
1. Audit the existing WordPress site
Identify:
- content types
- taxonomies
- plugins
- custom fields
- shortcodes
- theme customizations
- forms
- APIs
- redirects
- SEO metadata
- multilingual content
- scheduled jobs
- business integrations
2. Classify every dependency
Decide whether each feature should be:
- imported
- replaced
- rebuilt
- connected to an external service
- removed
3. Import a small content sample
Don't migrate thousands of posts immediately.
Start with representative examples.
