dashcommerce
Get started
WordPress · PHP · 2011

Migrate from WooCommerce to DashCommerce

Difficulty
High risk · phased project
Timeline
4-8 weeks for a mid-size store
Data loss risk
Medium — orders and subscriptions need careful planning

Who this migration is actually for

This guide is for teams who have already decided to leave WordPress. If WordPress is staying, you should not be reading this — the right answer is SureCart (for modern commerce on WP) or FluentCart (for Woo-compatible commerce on WP) or, yes, WooCommerce itself if what you have works. DashCommerce only makes sense as part of a larger decision to adopt EmDash CMS, Astro, and an edge-rendering deployment model.

If you use WooCommerce Bookings, Memberships, Points & Rewards, LMS integrations like LearnDash, multi-lingual content via WPML, or a multi-vendor marketplace plugin like Dokan at depth, stop here. DashCommerce does not have equivalents for those. Evaluate whether you’d be effectively rebuilding half your business on top of a newer commerce core. Sometimes that’s the right call. Often it isn’t.

If you’re running WooCommerce with a manageable extension surface — Subscriptions, maybe Shipping, maybe Product Add-Ons — and your team writes TypeScript and wants to own the full stack in a modern Astro project, keep reading. That’s the profile this guide was written for.

The two migrations

A WooCommerce-to-DashCommerce move is not one migration. It is two, happening in parallel.

Migration one: WordPress content to EmDash. Pages, posts, authors, media, SEO metadata, URL structure. This is a CMS migration and has nothing to do with commerce. It is its own project, with its own risks — link integrity, asset transfer, schema shape, redirect planning.

Migration two: WooCommerce data to DashCommerce data. Products, variants, customers, orders, subscriptions, coupons, shipping zones, tax rates, reviews. This is a commerce data migration and has nothing to do with the CMS layer.

You can sequence them — do content first, then commerce — but you cannot skip either one. Treating them as a single project is the most common reason these migrations slip. Plan them as two tracks with a single shared cutover date.

What you gain by moving

Zero platform fees. WooCommerce itself is free, but WooPayments skims on top of Stripe processing, and the paid extension ecosystem is a subscription trap (Subscriptions is $249/year, Memberships is $199/year, Shipping Method add-ons are $79-$149 each). DashCommerce is MIT, free, one npm package with every major category in core.

A modern stack. TypeScript end-to-end. Typed schemas that your IDE understands. Astro for the storefront — zero JS shipped to the client by default, fast static renders, edge-ready. A 12-page React admin for operations.

Edge deployment. DashCommerce runs on Cloudflare Workers, Vercel, Netlify, or anywhere that can host an Astro app. No more “WordPress host with PHP 8.2 and enough RAM to survive a traffic spike.”

Source code ownership. Every line is MIT on GitHub. Fork it. Audit it. Fix a bug without waiting for a plugin author’s next release cycle.

Subscription logic that doesn’t require three extensions. Stripe Subscriptions, trials, proration, dunning emails, cancellation flows, and marketplace payouts all ship in @dashcommerce/core.

What you lose

The plugin ecosystem. WooCommerce has thousands of paid and free extensions for every niche — bookings, LMS, points, memberships, B2B wholesale pricing, quote requests, real-time shipping carrier APIs. DashCommerce is one package. If you need a niche feature DashCommerce hasn’t built yet, you’re building it.

The WordPress developer pool. Every freelance WordPress developer knows WooCommerce. The pool that knows Astro + TypeScript + Stripe at the depth needed for a DashCommerce store is smaller. If you’re non-technical and rely on “find a WordPress dev on Upwork” as your support model, this is a real cost.

The mature admin. WooCommerce’s admin has 14 years of iteration. DashCommerce ships a 12-page React admin that covers day-to-day operations but does not have WooCommerce’s depth of merchant tools (advanced reporting, complex bulk edits, report scheduling, etc). It will get there; it’s not there yet.

Some niche features entirely. WooCommerce Bookings. WPML-grade translation. Points & Rewards ledgers. LearnDash integration. These do not exist in DashCommerce and are not on the near-term roadmap.

The honest subscription problem

This is the hardest part of a WooCommerce migration and deserves its own section.

If you use WooPayments as your processor, here’s what’s really happening. WooPayments is a Stripe Connect platform account operated by Automattic. When a customer signs up for a subscription, the cus_*, pm_*, and sub_* IDs are created on WooPayments’ Stripe platform account, not your own direct Stripe account. The tokens are associated with WooPayments; you see them via the WooPayments dashboard.

When you move to DashCommerce, you’ll use your own direct Stripe keys (sk_live_* and pk_live_* issued to your own Stripe account). Those keys cannot see WooPayments’ tokens. There is no cryptographic way to “transfer” a saved payment method from one Stripe account to another — Stripe’s API does not permit this by design.

Your three options:

Option A: Stripe portability export. Request a migration of customer data from WooPayments/Automattic under Stripe’s portability program. Stripe does support moving Connect platform customer data to a direct account, but it requires both merchant consent and cooperation from the platform (WooPayments). Success is inconsistent and timelines are measured in weeks. Start this request the moment you decide to migrate; don’t wait until cutover week.

Option B: Re-auth on first renewal. Accept that customers will need to re-enter their payment method the first time they renew after cutover. DashCommerce ships a customer self-service portal where they can update payment; send a clear email 7 days before their renewal date explaining the change. Expect a 5-15% retention dip around the cutover window — some customers will take the re-auth prompt as a reason to cancel. Factor this loss into your business case.

Option C: Dual-run through one billing cycle. Keep WooCommerce running for existing subscriptions through the next full billing cycle. New subscribers sign up on DashCommerce. Existing subscribers renew on WooCommerce one more time, then migrate at their next renewal via re-auth. This is the lowest-risk path for merchants with monthly subscriptions and a retention-sensitive base, but it doubles operational overhead for a month.

Most stores combine B and C. Almost none successfully complete A. Be realistic.

If you’re on a non-WooPayments Stripe integration (e.g., the Stripe plugin for WooCommerce talking to your own direct account), your tokens are already yours and re-tokenization is not required — you can migrate subscriptions by moving the subscription records into DashCommerce’s database and pointing the webhook endpoint at the new system. That path is dramatically easier. Check which Stripe integration you’re using before scoping.

SEO and URLs

WooCommerce’s default permalink structure is /product/{slug}/ and /product-category/{slug}/. If you’ve customized this (some stores use /shop/{slug}/), check your actual live URLs in Google Search Console’s Pages report.

DashCommerce does not impose a URL structure. Your Astro routes determine it. You have two paths:

Preserve the WooCommerce structure. Configure your Astro routes to match WooCommerce exactly — /product/{slug} maps to your DashCommerce product page at the same path. This is the safest SEO path and the one most migrations should take.

Redesign the URL structure. If you want /shop/{slug} instead of /product/{slug}, build a comprehensive 301 redirect map. Every indexed URL on your WooCommerce site needs a 301 to its equivalent on DashCommerce. Export the full URL list from Google Search Console Coverage, not just your sitemap — Google has indexed pages you forgot about.

Encode redirects at the edge, not in Astro middleware. Cloudflare Workers has a routes field, Vercel has vercel.json rewrites, Netlify has _redirects. Edge redirects fire before the Astro renderer boots, which is faster and cheaper. Keep redirects in place for at least 12 months; Google reconsolidates authority slowly.

Resubmit your sitemap in Search Console after cutover. Monitor the Pages report weekly for the first month for 404 spikes.

Tools you’ll use

  • WooCommerce CSV export (Products → All Products → Export, and similar for Customers and Orders). Fine for small catalogs.
  • WooCommerce REST API (/wp-json/wc/v3/products, /customers, /orders, /subscriptions). Better for structured, paginated exports. Authenticate with a key pair from WooCommerce → Settings → Advanced → REST API.
  • Direct MySQL against the WordPress database if you control the host. Fastest for large catalogs; requires understanding WooCommerce’s postmeta schema.
  • @dashcommerce/core v0.1.3 — the DashCommerce plugin itself, on npm, MIT.
  • @dashcommerce/starter — a reference storefront template you can fork into your EmDash project.
  • dashcommerce-merge-seed — the CLI that merges transformed JSON into DashCommerce’s data store idempotently.
  • EmDash’s seed mechanism — for content (pages, posts, authors) migration from WordPress exports (WXR/XML).
  • Stripe CLI (stripe listen, stripe trigger) for webhook testing in dev and staging.
  • Google Search Console for the before/after URL inventory, sitemap resubmission, and Coverage monitoring.

None of these is a magic button. Together, they get you from WooCommerce to DashCommerce in 4-8 weeks for a mid-size store.

The parallel-run strategy

The single highest-leverage decision in a WooCommerce migration is this: do not cut over all at once.

Keep WordPress/WooCommerce running on your production domain. Stand up EmDash + DashCommerce on a staging subdomain (new.example.com or staging.example.com). For 2-4 weeks, run both in parallel:

  • Migrate your content (pages, posts, media) to EmDash on the staging subdomain.
  • Migrate your product catalog to DashCommerce using dashcommerce-merge-seed.
  • Import customers (emails only, no passwords).
  • Configure Stripe in test mode on the new system, then switch to live mode for a small subset of products and real-charge a friendly customer.
  • Test checkout end-to-end. Receipt email. Refund. Subscription renewal. Webhook delivery.
  • Fix bugs. Find more bugs. Fix those.

When the new system has passed end-to-end testing on live traffic-representative data, flip DNS. Not before. Redirects should be pre-staged and tested against the staging subdomain via hostname override (edit /etc/hosts, curl with -H "Host: example.com") so you know they work before flipping.

Budget 30 days of post-cutover parallel maintenance so you have a rollback path. Keep the old WooCommerce instance up in read-only mode for at least 90 days for support lookups.

Testing in Stripe sandbox before cutover

Do not skip this. Stripe’s test mode accepts the same API calls as live mode with test card numbers (4242 4242 4242 4242 for success, 4000 0000 0000 9995 for insufficient funds, 4000 0025 0000 3155 for 3DS).

The minimum pre-cutover test matrix:

  1. Guest checkout, card success, receipt email delivered.
  2. Guest checkout, 3DS challenge required, succeeds on second factor.
  3. Guest checkout, card declined — graceful error, no ghost order.
  4. Logged-in customer, saved card, one-click purchase.
  5. Subscription signup with trial, trial-end renewal charges correctly, dunning email fires on decline.
  6. Coupon applied, discount correct, tax recalculated.
  7. Refund issued from DashCommerce admin, Stripe refund created, receipt email sent.
  8. Webhook delivery for each event type (checkout.session.completed, invoice.paid, customer.subscription.created, customer.subscription.deleted).

Run this matrix on staging. Run it again one business day before cutover. Anything that fails becomes a cutover blocker.

When to do this migration

Off-season. If you’re a seasonal retailer, do this in Q1 or Q3, not the week before Black Friday. The cutover itself is low-risk with a parallel-run strategy, but the first 30 days post-cutover will surface edge cases you didn’t anticipate, and you want operational bandwidth to fix them.

Low subscription renewal density windows. If most of your subscribers renew mid-month, plan cutover for the first week of the month so you have maximum time before renewal-related issues start hitting your inbox.

When you have a full sprint of engineering time dedicated. This is not a side project. A mid-size store migration consumes one senior engineer full-time for 4-8 weeks, plus design/frontend time to port the theme.

When NOT to do this migration

  • The week before, during, or immediately after Black Friday / Cyber Monday. Do not touch production.
  • If WooCommerce Bookings, LearnDash, WPML, or multi-vendor Dokan is load-bearing. DashCommerce does not have equivalents.
  • If your team cannot commit to running Astro + TypeScript + Stripe + Cloudflare Workers at production scale. Shopify exists for a reason; so does SureCart.
  • If your business is on WooPayments with hundreds of active subscriptions and low customer tolerance for re-auth emails. The subscription re-tokenization problem will hurt you.
  • If you haven’t already decided to leave WordPress. DashCommerce doesn’t make sense as a WordPress replacement if you’re keeping WordPress.

If any of those describe you, stop. The best migration is the one you don’t have to do.

Migration plan

Order of operations

  1. 01

    Audit your WooCommerce extensions

    Before you write a single line of migration code, list every active WooCommerce plugin and paid extension you rely on. Subscriptions, Bookings, Memberships, Points & Rewards, Product Add-Ons, Table Rate Shipping, Advanced Taxes, WPML, multi-vendor plugins like Dokan or WC Vendors — all of them. For each, note whether it holds data you need to migrate, integrates with a third-party service, or exposes customer-facing features you can't break. This audit decides whether the migration is feasible at all. If you're running eight extensions deeply, a move to DashCommerce is effectively a rebuild. Write the list down; share it with stakeholders before scoping a timeline.

  2. 02

    Decide what you actually need

    Map your WooCommerce audit against DashCommerce's feature set. DashCommerce ships six product types (simple, variable, grouped, external, subscription, digital), Stripe Payment Intents, Stripe Subscriptions with dunning, Stripe Connect for marketplace payouts, multi-currency, multi-zone shipping, coupons, inventory, reviews, abandoned-cart, and transactional email. It does not ship WooCommerce Bookings equivalents, LMS integrations, points-and-rewards gamification, or a multi-lingual CMS layer as rich as WPML. If you depend on any of those, either plan custom work on top of DashCommerce or stop here. This is the single biggest go/no-go gate in the project.

  3. 03

    Set up EmDash parallel to WordPress

    Do not cut over anything yet. Stand up EmDash CMS on a staging subdomain like `staging.example.com` or `new.example.com` while your WooCommerce store keeps serving production traffic on `example.com`. EmDash is Astro-native and edge-first, so pick a deploy target early — Cloudflare Workers, Vercel, or Netlify. Model your content collections in EmDash terms: pages, posts, authors, media. Do not try to migrate commerce yet — content first. Running two systems in parallel for several weeks is normal and expected during this kind of move. Budget for the overlap cost (hosting, domains, SSL, CDN) in your project plan.

  4. 04

    Scaffold DashCommerce

    With EmDash installed, bring up DashCommerce by running `npm create @dashcommerce@latest` in the EmDash project root. The scaffolder installs `@dashcommerce/core` (v0.1.3 at time of writing, MIT-licensed), the `@dashcommerce/starter` template, and `dashcommerce-merge-seed` — the CLI you'll use for data imports. Confirm the default storefront renders and the 12-page React admin is reachable. Configure Stripe in test mode with your own direct Stripe keys; do not reuse WooPayments keys, because WooPayments is a Stripe Connect platform account, not your own. You'll set up webhooks (checkout.session.completed, invoice.*, customer.subscription.*) later during Stripe configuration.

  5. 05

    Migrate your product catalog

    WooCommerce has two clean export paths: the built-in CSV export (Products → All Products → Export) and the REST API (`/wp-json/wc/v3/products`). Use whichever matches your attribute structure. Transform the export into the JSON shape DashCommerce expects — product type, variants, price per currency, SKU, inventory, images, SEO slug — then feed it through `dashcommerce-merge-seed`. The merge-seed CLI is idempotent: re-run it as often as you need during development without duplicating rows. Start with 20 products as a dry-run before trying the full catalog. Variable products with complex attribute matrices are the most common source of transform bugs — give them extra attention.

  6. 06

    Migrate customer list carefully

    Export customers from WooCommerce (Users → All Users → Export or via REST API). Import email addresses, names, billing and shipping addresses, and order history references. Do not attempt to migrate hashed passwords — WordPress uses phpass, not bcrypt, and forcing a cross-system password rehash is a security liability. Instead, on first login after cutover, trigger a mandatory password-reset email. Customers will grumble for a week, then forget. Communicate the reason clearly in the transactional email: "We've upgraded our store; for security, please set a new password." This is a one-time cost.

  7. 07

    Import historical orders read-only

    Historical WooCommerce orders are valuable for support lookup ("where's my order from 2023?") and tax reporting, but they do not need to be re-processable in DashCommerce. Export them (CSV or REST `/wp-json/wc/v3/orders`) and import into a read-only table or a dedicated collection in DashCommerce for archival. Do not try to replay these orders through the Stripe integration — they're already settled in Stripe's ledger and re-charging them would be a nightmare. The goal is lookup, not reprocessing. Include order line items, shipping address, total, currency, date, and the original WooCommerce order number for cross-reference with receipts and support emails.

  8. 08

    Configure Stripe with direct keys

    This is the step most WooCommerce migrations get wrong. WooPayments routes through Stripe Connect on Woo's platform account, so the `cus_`, `pm_`, and `sub_` IDs on your customers point to Woo's Stripe account, not yours. When you move to DashCommerce, use your own direct Stripe keys — `sk_live_*` and `pk_live_*` issued to your account, not WooPayments-managed keys. Test the full purchase flow in Stripe test mode: cart → checkout → Payment Element → 3DS challenge → webhook → order record → receipt email. Do this end-to-end at least once before cutover day. Verify webhook delivery with `stripe listen` locally and in a staging environment.

  9. 09

    Plan subscription migration carefully

    If you run WooCommerce Subscriptions on WooPayments, the payment methods attached to active subscriptions are tokenized against WooPayments' Stripe platform account. These tokens cannot be transferred verbatim to your own Stripe account. The three real options: (a) request an export from Stripe via the WooPayments team under Stripe's portability rules — this usually requires merchant consent and is not always granted; (b) accept that customers will re-enter payment methods on first renewal after cutover, and communicate that change via email and an in-checkout banner; (c) run both systems in parallel through the next billing cycle, letting active subscriptions expire naturally on WooCommerce while new ones sign up on DashCommerce. Most stores end up with some combination of (b) and (c). Expect a retention dip of 5-15% around cutover. Budget for it.

  10. 10

    Cut DNS and add 301 redirects

    Only flip DNS once EmDash + DashCommerce has passed end-to-end testing on staging. Before you cut, build a redirect map from old WooCommerce URLs to new DashCommerce URLs. WooCommerce's default permalink structure is `/product/{slug}/` and `/product-category/{slug}/`; DashCommerce uses the slugs you configure in your EmDash content collection. A mismatch means 404s, lost SEO equity, and angry bookmarked customers. Encode redirects at the edge (Cloudflare Workers, Vercel, Netlify `_redirects`), not in Astro middleware, so they fire before rendering. Keep the redirects in place for at least 12 months — Google reconsolidates authority slowly. Monitor Search Console's Coverage report weekly for the first month after cutover.

FAQ

Migrating from WooCommerce — FAQ

Is there a one-click WooCommerce → DashCommerce migrator?
No. And anyone who builds one is lying about what they built. The two systems have different data models (PHP serialized postmeta vs typed TypeScript collections), different URL structures, different payment token ownership (WooPayments Connect platform vs your direct Stripe account), and different CMSes underneath. A migration is a real project — budget 4-8 weeks for a mid-size store, longer if you use niche WooCommerce extensions. The tools DashCommerce does ship (`dashcommerce-merge-seed`, the EmDash seed mechanism, a typed Zod schema for imports) make the data transformation tractable, but there is no drop-in button.
What about my WordPress users and login?
WordPress stores passwords using phpass, a bcrypt-adjacent hash scheme different from what modern Node.js commerce systems use. You cannot reliably re-hash WordPress passwords into a new system — forcing a cross-platform rehash is a security liability. The correct pattern is to import email addresses, names, and addresses, and trigger a mandatory password-reset email on first login. Communicate this in advance: "We're upgrading; please set a new password." Customers accept this once; they won't accept a stolen session.
How do I handle active WooCommerce subscriptions?
This is the hardest part of a WooCommerce migration. If you use WooPayments, the `pm_` and `cus_` tokens on active subscriptions live on WooPayments' Stripe Connect platform account, not your direct Stripe account. You have three options: (1) request a Stripe portability export via WooPayments support (not always granted); (2) let customers re-auth on first renewal after cutover and accept a retention dip; (3) dual-run both stores through the next billing cycle, letting existing subscriptions renew on Woo and new ones sign up on DashCommerce. Most merchants end up with a combination of (2) and (3).
Can I run WordPress and EmDash in parallel during migration?
Yes, and it's the recommended approach. Keep `example.com` pointed at WordPress/WooCommerce while you build out `staging.example.com` (or `new.example.com`) on EmDash + DashCommerce. This lets you migrate content and commerce data without a hard cutover, test the full purchase flow under real conditions, and fix issues before flipping DNS. The cost is paying for two sets of hosting for a few weeks, which is usually small compared to the cost of a botched cutover. Plan to maintain the parallel environment for at least 30 days post-cutover for rollback safety.
What URL structure does DashCommerce use vs WooCommerce?
WooCommerce defaults to `/product/{slug}/` and `/product-category/{slug}/`. DashCommerce follows whatever routing you set up in your Astro project — there is no fixed convention. Most DashCommerce stores use `/shop/{slug}` or `/products/{slug}`. The important thing is the redirect map: whatever your WooCommerce URLs are today, every one of them must either match the new URL exactly or redirect with a 301 to the new URL. Do not skip this step. Losing a year of Google's trust on your product pages because of 404s is a real, measurable hit to revenue.
What if I use WooCommerce Bookings / Memberships / Points & Rewards?
DashCommerce does not have drop-in equivalents for any of these. WooCommerce Bookings handles appointment-based commerce (hotel rooms, consultation slots, equipment rental) — DashCommerce has no calendar/availability system. WooCommerce Memberships gates content behind subscription tiers — DashCommerce Subscriptions handle the billing side but not the WordPress-style content gating. Points & Rewards is a loyalty system; DashCommerce has coupons but no points ledger. If any of these are core to your business, do not migrate. Either stay on WooCommerce, or scope a custom build on top of DashCommerce's open-source core.
What about my SEO? Will I lose rankings?
Only if you skip the redirects. Google reconsolidates page authority across 301 redirects over weeks to months — a well-executed migration with clean 301s loses a small amount of traffic for 2-4 weeks and recovers fully. A botched migration with 404s on ranking pages can cost 20-40% of organic traffic permanently. The work that matters: build a redirect map from every indexed WooCommerce URL (check Google Search Console's Pages report) to the new DashCommerce URL, configure redirects at the edge so they're fast, resubmit your sitemap, and monitor Coverage in Search Console weekly for the first month.
How do I export WooCommerce data cleanly?
Three approaches, from simplest to most reliable. (1) WooCommerce's built-in CSV export (Products → All Products → Export, Customers → All Users → Export, Orders → All Orders → Export). Works for small catalogs. (2) The WooCommerce REST API at `/wp-json/wc/v3/products`, `/customers`, `/orders`, and `/subscriptions` — use an authenticated key pair from WooCommerce → Settings → Advanced → REST API. Better for structured, paginated exports. (3) Direct SQL against the WordPress MySQL database if you control the host — the fastest for large catalogs but requires understanding WooCommerce's postmeta-heavy schema. Whichever path you choose, dump everything to versioned JSON before transforming; never transform during export.
What about my custom WooCommerce theme?
It does not come with you. WooCommerce themes are PHP + Liquid-style template tags + WordPress hooks; DashCommerce runs inside an Astro project with `.astro` components and typed props. The storefront is a rebuild. This is a feature, not a bug — most WooCommerce stores accumulate years of theme cruft and this is the moment to throw it out. Plan for 1-2 weeks of design/frontend work to port your visual identity into the DashCommerce starter. `@dashcommerce/starter` gives you a working storefront with cart, product pages, checkout, and account flows out of the box; you're restyling, not rebuilding from zero.
Try it

Start the migration today.

Scaffold a DashCommerce project, test the checkout in Stripe sandbox, then cut over woocommerce when you're confident.

Get started → Live demo ↗
on npm · npm create @dashcommerce@latest