Should we migrate to a Shopify-native subscription setup, or keep our subscription app (Recharge/Skio) completely separate from the core platform migration timeline?

Why are a replatform and a subscription migration two projects?

A replatform and a subscription migration are two projects because they fail in different ways. A replatform moves catalog, customers, orders, content and theme, and a bad launch has a rollback. A subscription migration moves billing contracts and payment credentials, and a failed charge has none. Shopify warns that repeated failed renewals can pause, skip or cancel a subscription, and that "Updating a payment method can't restore a cancelled subscription contract" (Shopify Help Center, October 2026).

Shopify's migration guide adds a second reason: "We strongly recommend that you pause any billing in your current application while migrating customer payment methods and contracts" (Shopify developer docs, October 2026). So a billing move needs its own pause, and a launch weekend has no room for one. Whether to leave Recharge or Skio at all is the cost-benefit case for moving to Shopify Subscriptions, a separate decision from when the subscription work runs.

In what order should the replatform and the subscription work run?

The storefront goes first and the billing engine last, so each cutover can fail on its own and be read on its own.

1. Keep the existing subscription platform live and billing throughout the replatform.
2. Rebuild the product-page purchase options natively on the new theme, so new sign-ups land in your own markup rather than a vendor widget.
3. Cut the storefront over.
4. Let two full billing cycles run clean on the new storefront.
5. Then, and only then, open the question of whether the billing platform itself should move, to Shopify Subscriptions or anywhere else.

Keeping the two apart has a real cost: a second change-management cycle and a second round of subscriber emails, and merchants reasonably dislike both. So plan the message for long-tenured, high-value subscribers as its own piece of work, and use the order of operations for moving an active program once step 5 arrives. We still take two cutovers over one window in which a theme regression and a billing regression are indistinguishable at 2am.

What does Shopify Subscriptions need from the new theme?

Shopify Subscriptions needs a theme that is "compatible with sections and blocks" before it can display subscription products (Shopify Help Center, October 2026). Shopify lists the free themes it supports: any Online Store 2.0 theme built by Shopify, the Horizon family, Debut 15.0 or later, and Brooklyn 17.0 or later. If you're unsure about another theme, Shopify says to contact its developer. A replatform is the natural moment to meet that requirement, which is a real argument for sequencing the theme work first.

The purchase options are theme work whichever app bills. Subscription apps create selling plans, and a theme can render them with Liquid and JavaScript (Shopify developer docs, October 2026). So a selector built into the new theme during the replatform reads whichever app's selling plans exist (Deploi's reading of that guide). That means it can survive a later billing move, native or paid.

When is folding the subscription move into the replatform defensible?

Folding the subscription move into the replatform is defensible only when the subscription platform is the reason for the replatform, or when fewer than about 2,000 active subscribers sit on simple plans; outside those two cases, the two stay apart.

Between about 2,000 and 10,000, the same record adds your own reconciliation checklist to a vendor-led migration. From about 10,000 it scores the move CUSTOMIZE: buy the destination, then build the glue the import skips, such as contract mapping and payment-method transfer checks. That glue needs the same people as the launch, which is one more reason to give it its own quarter. Hold the agency to a card-retention benchmark written into its scope, whichever timeline you choose.