Migrate from Shopify to DashCommerce

Who this migration is for

This guide is for teams who have already decided to leave Shopify. If Shopify is working for you, you should probably stay. Shopify’s operational lift — managed infrastructure, mature admin UI, App Store ecosystem, polished merchant experience — is the correct answer for a large category of merchants, and an open-source zealot will try to talk you out of that for bad reasons. Do not listen.

This guide is not for you if any of the following apply. You depend on Shopify POS for brick-and-mortar retail. You run a subscription-heavy business where most revenue flows through Shop Pay Subscriptions or ReCharge and you cannot absorb a retention dip. You rely on ten or more Shopify apps for day-to-day operations, most of them Shopify-only. Your team is non-technical and the idea of deploying an Astro project to Cloudflare or Vercel sounds foreign. In any of those cases, the migration cost exceeds what you would recover in platform fees and control, and Shopify is still the right answer.

This guide is for you if you run a mostly-online store, your team writes TypeScript, you are already on or moving toward an EmDash CMS or Astro site, and the 0.5-2.0% Shopify platform fee on top of Stripe processing is starting to feel like rent. If that describes you, keep reading.

What you’re actually leaving behind

A Shopify migration is not a config change. You are leaving five distinct things, and it is worth being honest about each.

Managed infrastructure. Shopify runs the servers, the CDN, the database, the checkout, the backups, the uptime, the DDoS protection, the PCI compliance, the fraud detection. When you move to DashCommerce, you run all of that — on Cloudflare Workers or Vercel or Fly or a box, but you run it. This is a feature if you want control and a liability if you have no team to carry the pager.

The app ecosystem. Shopify has tens of thousands of apps. Any niche integration you might need — a specific 3PL, a vertical-specific loyalty program, a local payment method, a tax service for an unusual jurisdiction — probably already exists in the App Store. DashCommerce has no app store. You reconnect the tools that still work (Klaviyo, Gorgias, ShipStation) via their native APIs, and for anything Shopify-only, you rebuild on open tools or walk away from the feature.

The polished admin. Shopify’s admin is 18 years of iteration. Every inventory edit, every bulk update, every customer lookup is fast and obvious. DashCommerce ships a 12-page React admin that covers products, orders, customers, subscriptions, coupons, shipping, tax, reviews, vendors, and settings — feature-complete for operations, but not yet pixel-polished in the way Shopify’s is. Be honest with your operations team about this going in.

POS, if you use it. See above. DashCommerce has no POS, and there is no near-term roadmap for one. If you run physical retail on Shopify POS, this migration is not for you.

Shop Pay. Shop Pay is Shopify-proprietary — the one-click checkout, the network-wide card vault, the Shop Pay Subscriptions product. You cannot keep any of it. Stripe’s Payment Element covers most of what Shop Pay did for conversion (Apple Pay, Google Pay, Link, saved payment methods), but it is not identical and you will measure a conversion difference for the first month. Plan for it.

What you gain

Source code. Every line of DashCommerce is MIT-licensed on GitHub. Fork it. Audit it. Fix a bug without waiting for a platform team’s next release. Add a feature specific to your business without contorting it through a Liquid section or an app proxy.

Zero platform fee. Shopify Basic charges 2.0% on every transaction above Stripe processing unless you use Shopify Payments. Shopify Plus starts at ~$2,500/month plus fees. DashCommerce charges $0 and takes $0 per transaction. On a $2M/year store, that is $40,000/year back into the business. On a $200K/year store, it is $4,000/year — smaller, but the math only goes one direction as you grow.

Edge performance. DashCommerce is designed for edge deployment on Cloudflare Workers or Vercel. The storefront is Astro — zero JS shipped by default, fast static renders, assets on a CDN — not a Liquid template rendered server-side in Shopify’s stack. For content-heavy stores, the performance difference is visible in Lighthouse and in real-user metrics.

CMS-integrated commerce. If you are already on EmDash, commerce becomes part of the same content graph, not a separate Shopify surface talked to via a Storefront API shim. Product pages, collections, marketing pages, and blog posts share the same rendering pipeline, the same typed schemas, and the same deployment target.

Direct Stripe. You own the Stripe account. You control the fraud rules, the chargeback process, the payout schedule, the tax automation, the 1099 reporting. No intermediate platform sits between your business and the payment processor.

The app-replacement matrix

This is the most useful section of this guide. For each major Shopify app category, here is what DashCommerce provides in core and what you replace it with externally.

Email marketing (Klaviyo, Mailchimp, Omnisend). Keep them. Connect via DashCommerce webhooks and Stripe webhooks. DashCommerce does not ship a campaign builder — transactional email (receipts, renewals, dunning, abandoned-cart) is in core, but broadcast and segmentation are not. Klaviyo’s value is segmentation and drip campaigns; that value persists after you migrate.

Customer support (Gorgias, Zendesk, Intercom). Keep them. These are email-first and chat-first tools; they connect to your support channels, not to Shopify specifically. Reconnect with the new admin email and any custom data webhooks you want them to receive.

Subscriptions (ReCharge, Bold, Appstle, Shop Pay Subscriptions). Replace with DashCommerce core. Stripe Subscriptions with trials, proration, upgrades, cancellation flows, and dunning emails ship in @dashcommerce/core — no app, no monthly fee, no Stripe Connect intermediate. The migration cost is real (see subscription section below), but once done, you are off the subscription-app treadmill.

Reviews (Yotpo, Stamped, Judge.me, Loox). Replace with DashCommerce core, or keep external. DashCommerce ships a review system with moderation and display. If you already have thousands of reviews on Yotpo and the social-proof value matters, keep Yotpo and use their JS embed. If you are starting fresh or moving small volume, use DashCommerce core.

Tax (Shopify Tax, TaxJar, Avalara). Replace with Stripe Tax. Shopify Tax is Shopify-only. Stripe Tax is the lowest-effort direct replacement — US sales tax, VAT/GST in major jurisdictions, registration help, and it integrates cleanly with DashCommerce’s Stripe checkout. TaxJar and Avalara still work via webhook if you need specific reporting.

Shipping (ShipStation, Shippo, EasyPost). Keep them. These services have direct APIs and connect to DashCommerce via webhook for order events. Multi-carrier rate shopping, label printing, and fulfillment stay exactly as they were.

Loyalty and rewards (Smile.io, LoyaltyLion). Keep them, or rebuild on your own. DashCommerce ships coupons in core but no points ledger. If loyalty is important, Smile.io and LoyaltyLion have APIs; reconnect via webhook.

SMS (Postscript, Attentive). Keep them. Direct API, reconnect with your customer list.

Page builders (Shogun, PageFly). Replace. If you are on EmDash, content pages are already authored in EmDash’s CMS. Shogun and PageFly are Shopify-specific and do not migrate.

Shopify Flow automations. Rebuild on Make, n8n, or Zapier — general-purpose automation tools that connect to DashCommerce and Stripe via webhooks. Flow is Shopify-only and does not migrate.

Exporting Shopify data

Shopify gives you two clean export paths.

Built-in CSV. Admin → Products → Export, Customers → Export, Orders → Export. Works for small catalogs (under a few hundred products, a few thousand customers). Flattens variant structure, loses metafields, and does not include app-specific data. Adequate as a starting point; not adequate for a production migration.

Admin GraphQL API. Create a custom app in Shopify admin, assign it read permissions, use the generated access token to query products, productVariants, collections, customers, orders, metafields, and redirects. Paginate with cursors. Write every response to versioned JSON before transforming. This is the serious path for any store with variant complexity or metafield usage.

Also export the Online Store URL Redirects table (Navigation → URL Redirects), Shopify Flow workflows (manual export, rebuild on external tools), app-specific data (each app has its own export path in its own dashboard), and the current sitemap at /sitemap.xml for building the 301 redirect map.

Never transform during export. Dump raw Shopify JSON first, versioned in git or blob storage, and transform from those frozen snapshots. This lets you re-run the transform as many times as needed without re-hitting Shopify’s rate limits.

The subscription migration reality

If you do not sell subscriptions, skip this section.

If you do, this is the hardest part of your migration and the single most common reason Shopify migrations slip. Read it carefully.

Active subscriptions on Shopify are tokenized payment methods attached to customers, stored on someone’s Stripe account — either Shopify’s (for Shop Pay Subscriptions) or the subscription app vendor’s Stripe Connect account (for ReCharge, Bold, etc.). These tokens (cus_, pm_, sub_ IDs) exist on a Stripe account that is not yours. You cannot just copy them to your direct Stripe account. Stripe’s tokens are account-scoped by design.

Your options, from least to most painful for customers:

Option A: Stripe portability export. Stripe supports account-to-account tokenization transfers under its portability program, but it requires consent from both account holders (you, and whoever holds the existing tokens — Shopify or ReCharge) and is not always granted. If you have a large subscription base and executive relationships, this is worth pursuing. Budget 4-8 weeks just for the Stripe coordination, and do not count on approval.

Option B: Customer re-authorization. Accept that on first renewal after cutover, customers must re-enter their payment method. Communicate this via email 7-14 days before the first renewal cycle, show an in-checkout banner, and make the re-auth flow one click. Expect a 5-15% retention dip in that first cycle — some customers will forget, some will decide not to bother, some will take the prompt as an opportunity to cancel. Budget the revenue hit into your migration financial model.

Option C: Dual-run through one full billing cycle. Keep Shopify running for existing subscriptions while new subscriptions sign up on DashCommerce. At the end of one full billing cycle (30 days for monthly, 365 for annual), all active Shopify subs have renewed once and you can either let them run to next cycle on Shopify while migrating them via Option B, or run Option A in parallel. This is the most complex operationally but least painful for customers.

Most stores end up with a combination of B and C. If subscriptions are a majority of your revenue, do not migrate unless the long-term savings justify the short-term retention dip.

Rebuilding the theme

Shopify themes do not migrate. Liquid is a Shopify-specific template language with Shopify-specific helpers, hooks, and objects. None of it ports to Astro.

What you are doing instead: starting with @dashcommerce/starter, which gives you a working storefront with cart, product pages, product listings, checkout, account pages, order history, and abandoned-cart flows out of the box. You are restyling, not rebuilding from zero. The work is design-focused: apply your brand colors, typography, and imagery to the existing component structure, adjust layouts, and add any custom sections your brand requires (lookbook, brand story, ambassador program).

Budget 2-4 weeks for a mid-size store. Treat the rebuild as an opportunity to drop accumulated Shopify-era theme cruft — unused sections, dead app blocks, legacy Liquid snippets. Most Shopify themes carry years of this. Shed it deliberately.

SEO and URL preservation

Shopify uses predictable URL patterns, which makes redirect mapping straightforward:

• /products/{slug} → /shop/{slug} (or whatever you configure in your Astro project)
• /collections/{slug} → /category/{slug}
• /collections/{collection}/products/{product} → /shop/{product} (drop the collection prefix)
• /pages/{slug} → /{slug} (EmDash handles these as regular pages)
• /blogs/{blog}/{post} → /blog/{post} (or match your EmDash blog routing)

Export every indexed URL from Google Search Console’s Pages report and Shopify’s sitemap. Build the redirect map in a CSV or JSON file, validate with a script that checks every redirect resolves to a 200 response, and encode redirects at the edge — Cloudflare Workers, Vercel Edge Middleware, or Netlify’s _redirects file. Do not put redirects in Astro middleware; they run too late and cost a render on every redirect.

Keep redirects in place for at least 12 months. Google reconsolidates page authority slowly — weeks to months — and a URL that 404s during that window can lose most of its ranking equity permanently. After 12 months you can start pruning low-value redirects; do not prune anything still receiving organic traffic.

Resubmit your sitemap to Google Search Console the day of cutover. Monitor the Coverage report weekly for the first month, watching for 404 spikes and un-indexed pages.

The parallel-run strategy

Do not attempt a hard cutover. Run DashCommerce in parallel with Shopify for at least 30 days before flipping DNS, and keep Shopify running in read-only mode for 30 days after.

Before cutover: stand up DashCommerce on new.example.com or staging.example.com, run full purchase flows through Stripe test mode, then through a small slice of real traffic. Have at least two non-engineering teammates shop the staging site and report anything that feels different from Shopify. Walk through every critical path: product search, cart, coupon codes, checkout with Apple Pay, checkout with Link, subscription signup, subscription cancellation, password reset, abandoned cart, refund, return flow.

After cutover: keep Shopify in read-only mode as a rollback insurance policy. If a critical issue emerges on DashCommerce in the first week, you can temporarily point DNS back to Shopify while you fix the issue. This is expensive (two sets of infrastructure, two payment stacks, support staff trained on both) but cheap compared to a botched cutover that loses a weekend of revenue.

When to cut DNS

Cut DNS only when all of the following are true:

• Staging has passed end-to-end testing, including real-traffic smoke tests
• Redirects are encoded at the edge and validated against a list of indexed URLs
• Stripe is live on your direct account with webhooks verified
• The subscription migration plan is communicated to affected customers, with in-checkout banners and email sequences in place
• Your operations team is trained on the DashCommerce admin and has written runbooks for the first week’s likely support cases
• An on-call rotation is set for the first week after cutover

The cut itself is fast: update A/CNAME records, wait for propagation (TTL permitting — lower TTLs 24-48 hours before cutover), switch traffic. The first 24 hours are busiest for support — staff up. The first week is busiest for engineering — staff up. After 30 days, retire the parallel Shopify environment.

When NOT to do this migration

Do not migrate if:

• You run Shopify POS and physical retail is a meaningful revenue source. DashCommerce has no POS.
• Your subscription base is large, you cannot communicate a re-auth cleanly, and a 5-15% retention dip would be existential.
• You depend on ten or more Shopify apps daily and more than three are Shopify-exclusive with no external equivalent.
• Your team is non-technical and no one is comfortable running an Astro project on Cloudflare or Vercel. Hire first, migrate later.
• You are launching this week. Migration is a 6-12 week project for a mid-size store; compressing it is how cutovers fail.
• You are on Shopify Plus and the Plus-specific features (B2B wholesale, Launchpad, custom checkout) are core to your operation. DashCommerce does not have equivalents for most Plus-tier features, and the Plus platform fee — while real — is often worth it for large merchants.
• You are chasing “zero platform fees” without a clear handle on what the migration will cost in engineering time and customer-facing risk. The math on a $500K/year store rarely justifies the migration cost. The math on a $5M/year store usually does. Do the math first.

If none of those apply and you have done your app audit, subscription plan, and redirect map — welcome. The migration is real work, but the result is a commerce stack you own, on infrastructure you control, paying Stripe and nobody else.