Moving from WordPress to EmDash CMS

Start with the reason to move

WordPress can be a good fit. If your team can publish easily, the site works well, and maintenance is manageable, changing the CMS needs a clear business reason.

A move becomes worth exploring when a marketing site or publication has accumulated plugins, fragile templates, and a deployment process that makes small changes expensive. Compare the cost of the rebuild with the time your editors and developers spend maintaining WordPress.

EmDash is an open-source CMS built on Astro. Developers build the site while editors manage content through its admin interface. Cloudflare has released EmDash 1.0. See the official EmDash 1.0 announcement.

Content import is one part of the move

EmDash provides two WordPress import paths: a WordPress XML export (WXR), or a connection through the EmDash Exporter plugin. Pasting a public site URL without that exporter only detects the site and reports public counts; it does not import the content.

The XML path can bring across posts, pages, custom post types, taxonomy terms, and authors represented in the export. The exporter can also retrieve supported comments, menus, settings, and SEO values. Check your actual data against the content import documentation.

A WXR file contains attachment references, not the image files themselves. Keep the WordPress origin available while media is copied and its new URLs are verified. Review imported statuses too: private, pending, and scheduled content do not retain their original publishing behavior automatically.

The design and plugin behavior need their own plan

A WordPress theme does not become an EmDash theme through a content import. Its layouts and interactions need to be recreated in Astro. You can preserve the visual design while changing how it is built. EmDash documents that process in its WordPress theme porting guide.

Make an inventory of what each plugin does. A plugin that defines content fields is a different migration task from one that handles subscriptions, checkout, search, or a CRM integration. WordPress plugins require replacements or porting; importing their content does not reproduce their behavior. See the plugin porting guide.

For a content-led site, this may be a manageable rebuild. For a store, membership service, or application deeply tied to WordPress, prove the hardest workflow first. Keeping WordPress may be the better decision.

A practical migration sequence

1. Record what works today

Back up the database and uploaded files. List the pages, templates, plugins, integrations, and publishing tasks the team relies on. Crawl the current URLs and record which pages bring search traffic or leads.

2. Build a representative preview

Start with a small set: a landing page, a long article, an image-heavy page, and a page with custom fields or embedded content. Have an editor create and update content in the preview.

3. Import and reconcile

Map content to the new collections, then compare counts and inspect individual entries. Check headings, images, captions, links, bylines, dates, and publication status. Follow the official migration procedure and resolve import errors before launch.

4. Preserve the paths people use

Keep existing URLs wherever possible. Where a path changes, give it a permanent redirect to the equivalent page. Check canonical tags, titles, descriptions, structured data, the sitemap, and internal links. An imported slug alone does not preserve the old permalink structure.

5. Agree on the switch and recovery plan

Choose a content freeze or a final synchronization process so edits made during the rebuild are accounted for. Test forms, search, analytics, and key journeys. Keep a recoverable WordPress copy, define when to roll back, and monitor errors and search traffic after switching.

Where Cloudflare fits

EmDash documents a Cloudflare deployment using Workers for the application, D1 for the database, and R2 for media. That is one supported setup; review the Cloudflare deployment guide for configuration and operational requirements.

Compare the whole cost: hosting, storage, requests, backups, maintenance, and the initial rebuild. A CMS change alone does not guarantee a faster site or a lower bill. Measure the preview against your current site before deciding.

What a product manager should ask for

• A list of content and workflows that will move, be rebuilt, or stay elsewhere.
• A preview that editors can test using real publishing tasks.
• A URL and redirect map, plus a record of import issues and their resolution.
• A cost estimate that includes migration work and ongoing operations.
• A launch owner, a rollback plan, and clear responsibility for maintenance.

Use those deliverables to decide whether to proceed with the migration.