Should your store go headless or improve its current platform?

Separate three decisions before comparing platforms

A new storefront, a new checkout and a new commerce backend are different purchases. A team can retain Shopify while replacing its theme with a separate frontend. Shopify’s Storefront API cart documentation documents a checkout URL that sends the buyer to Shopify checkout. A custom frontend therefore does not imply unrestricted control of every checkout step. Confirm the required extension points against the chosen plan and integration before approving the architecture.

Headless describes that separation. Composable commerce describes assembling capabilities from components; it is not a requirement to split every function into a different product. First write the problem as an observable constraint: a configurator cannot express the required options, two channels need the same catalog with different presentation, or a content workflow cannot publish the intended buying journey. “The shop feels old” is a design brief, not sufficient evidence for a backend replacement.

The headless CMS decision guide covers editorial workflow and content reuse. This guide concerns orders, payments and operational responsibility. Use e-commerce development when those constraints need to become an implementation scope.

Compare the full operating workload

Ask each proposal to separate discovery, storefront work, commerce configuration, data migration, integrations, testing and cutover. Then list recurring platform and app fees, frontend hosting, monitoring, upgrades, incident response and editor support. Keep payment-provider charges and internal operating effort visible. There is no defensible universal percentage saving for headless: the same frontend freedom can also create a new system to maintain.

Name who owns catalog attributes, sellable stock, prices, orders, payments and refunds. The owner may differ for each record. For stock, distinguish physical inventory from available-to-sell quantity and reservations. Define when the storefront must stop selling a variant if the authoritative feed becomes stale. A faster page does not correct a stock rule that nobody owns.

Pilot one real order journey

An illustrative pilot, not a client result: a merchant keeps its current commerce backend and builds a separate storefront for one product family. The agreed journey includes a variant selection, a discount, delivery choice, payment, warehouse export, shipment notification and a partial refund. Run the same journey on the existing store so that the comparison uses the same rules and data.

Use representative mobile devices and slower connections, not only a developer laptop. Record the tested environment, platform/API versions, product fixtures, expected result, actual result and evidence location. Include an unavailable variant, an expired discount, a rejected payment, an interrupted browser session and an address that changes delivery eligibility. Agree which failures block launch and which can enter a dated follow-up backlog. Set performance and availability targets from the current baseline and business need, not an arbitrary industry number.

Test how the team changes a price, previews content and handles a return without a developer. A successful customer journey with an unusable staff workflow is not a successful pilot. Preserve consent behavior and verify that analytics does not count the same purchase twice across the storefront and checkout.

Make duplicate and missing events safe

Shopify’s webhook verification documentation describes signature verification and duplicate-delivery checks. These are distinct: a legitimate repeated message must not create a second fulfillment or refund. Keep a durable record linking the order, payment transaction and downstream operation, and make retries safe at the business-operation level.

For an illustrative reconciliation exercise, create ten test orders, each with one successful payment capture. Return one of them in full. The expected record is ten captured orders and one full refund, not nine orders. Compare commerce records with provider transactions and warehouse exports by stable identifiers, currency and amount. If order export fails after payment succeeds, the next action is to recover fulfillment or resolve the order, not charge the buyer again. Treat unexpected differences as exceptions for an assigned operator; do not silently force totals to match.

Deliberately deliver one event twice, hold another back and process an update late. Confirm that duplicates have no second business effect, missing work is found by reconciliation, and a late event cannot overwrite a newer valid state. Reconciliation frequency and escalation deadlines belong in the agreed scope. These are proposed acceptance tests, not claims about defaults in every platform.

Medusa’s events and subscribers documentation distinguishes asynchronous follow-up actions from steps integral to a commerce flow. Apply that distinction when reviewing any component design: a required order validation must not be treated like an optional notification that can fail after the order completes. Sources checked 3 November 2026.

Rehearse a rollback that preserves orders

Start with a contained storefront rollout only if both old and new paths can safely share the intended backend. Assign the switch-back decision and test the old path while the pilot is running. Preserve carts where supported, maintain important URLs and check redirects, canonicals, language routes and checkout return links. A rollback of frontend code does not undo a captured payment.

A backend migration needs a separate cutover plan. Record which system may accept new orders, the data-transfer checkpoint, the final stock position and how orders created around cutover will reach fulfillment. Avoid two independent writers changing the same order or inventory record. Do not promise instant rollback after irreversible data changes; test whether recovery requires a forward correction, an export reconciliation or a controlled pause in ordering.

Decide from the pilot, then commission the smallest change

Choose an improvement to the existing store if it passes the required journey with a smaller operating burden. Choose a separate storefront if it resolves the measured constraint and the team accepts the additional ownership. Replace the backend only when its commerce limitations remain after realistic extension options have been tested.

MyMerch’s published case provides evidence of Shopify workflow and storefront work. It does not document a headless migration or establish a conversion uplift for your store. Bring the failed journey, system list and pilot findings to a commerce scoping conversation; those inputs are more useful than a preferred architecture label.