Should we migrate to a Shopify-native subscription setup, or keep our subscription app (Recharge/Skio) completely separate from the core platform migration timeline?
Subscription migration and platform migration belong on separate timelines. Deploi keeps the subscription app live through the replatform and rebuilds only the product-page purchase-option layer on the new theme, roughly 46 hours of scoped work. Coupling the two puts payment tokens, billing state and theme cutover in the same release window, which is where the 2 to 5% subscriber loss reported for migrations concentrates (July 2026 research).
Why the two look like one project and are not
A replatform moves catalog, customers, orders, content and theme. A subscription migration moves billing contracts and payment credentials. The first is a data problem with a rollback. The second is a money problem without one: a failed charge is not a 404, it is a churned subscriber and a support ticket.
What we do instead
- Keep the existing subscription platform live and billing throughout the replatform.
- Rebuild the product-page purchase-option layer natively on the new theme, so new sign-ups land in your own markup rather than a vendor widget.
- Cut the storefront over.
- Let two full billing cycles run clean on the new storefront.
- Then, and only then, open the question of whether the billing platform itself should move.
The plan gate to check before step 2. Shopify Subscriptions requires a theme that supports sections and blocks: Online Store 2.0 themes by Shopify, the Horizon family, Debut 15.0 or later, or Brooklyn 17.0 or later (per Shopify's docs, September 2026). A replatform is the natural moment to satisfy that requirement, which is a genuine argument for sequencing the theme work first.
When coupling is defensible. One case: the current subscription platform is the reason for the replatform; you are leaving a platform the vendor no longer supports. Then they are one project because they always were. Another: you are below roughly 2,000 active subscribers and buying the vendor's migration service, where the incremental risk is small enough to absorb into a larger cutover.
The honest boundary. Decoupling costs you a second change-management cycle and a second round of subscriber emails. That is real, and merchants reasonably hate it. We still take it over one window in which a theme regression and a billing regression are indistinguishable at 2am.
The Deploi point of view
Our own position, from building on Shopify. Separate from the facts above.
- Our take: Decouple by default. The replatform gets the theme and the purchase-option layer; the billing engine gets its own quarter.
- What we’ve seen: The failure we keep meeting is not a bad migration script; it is a cutover weekend where nobody can tell whether a drop in subscription revenue is the theme, the feed or the billing move, because all three shipped together.
- Times we’ve shipped this: 5 builds delivered.
- What it takes: roughly 46 hours scoped for the product-page purchase-option layer (directional Deploi estimate from a small sample of engagements, not a measured average).
- What this page adds: the sequencing, and the specific theme-version gate that makes the purchase-option rebuild a natural part of the replatform rather than a separate ask.
Reviewed by Martin Dejnicki, Director of SEO & AI Search. Facts verified 2026-09-13.