Migrating your project to EmDash

Who this is for

This guide is for teams asking: “We’re moving to EmDash — what do we do about the store?” It is not a promise that every WooCommerce site can be mechanically converted — EmDash and WordPress differ at the CMS core.

EmDash vs WordPress (the typographic name)

EmDash here means the EmDash CMS project (Astro-native, edge-oriented). The word “em dash” also refers to the punctuation mark “—” in typography; SEO around the name can be noisy — always disambiguate with emdash-cms or “EmDash CMS” in writing.

Separate content migration from commerce

Plan posts, pages, assets, and URLs first in EmDash terms (collections, redirects, SEO parity). Commerce data — customers, orders, subscriptions — is a second migration track with different risk: payment methods cannot always be lifted verbatim between processors; historical orders may be archived read-only in Stripe or exported for support.

Where DashCommerce fits

If you choose EmDash for the site and need native checkout aligned with that stack, DashCommerce is the plugin shaped for that world (Stripe, typed collections, EmDash admin). Evaluate against your need for subscriptions, multi-currency, marketplace splits — see the README for the live roadmap.

Suggested order of operations

1. Ship a non-commerce EmDash slice (or a static facade) if you can — learn deploy and editors first.
2. Follow Getting started (plugin, dashcommerce-merge-seed, emdash seed); run DashCommerce in Stripe test mode and exercise checkout before cutover.
3. Cut DNS / canonical URLs only when redirects and Stripe webhooks are verified end-to-end.