Auditing a subscription-commerce migration before it ships.

The situation #

A subscription-commerce brand running a specialized e-commerce platform with custom subscription tooling was looking at Shopify as a replatform target. The vendor demo was strong. The board liked the cost story. Engineering had concerns that didn't yet have a clear name on them. We were asked to run a technical assessment before the migration kicked off.

What we found #

The visible question was platform comparison. The real question was data-model translation. The brand's competitive advantage wasn't the platform itself; it was a custom subscription model with multiple cadence options, mid-cycle plan changes, and personalized bundle logic refined over years. Most of that logic lived in code paths that didn't have analogs in vanilla Shopify, even with subscription apps layered on top.

A migration that ships without naming those code paths becomes a launch where the new system can't do what the old one did. Vendor demos don't surface that, because vendor demos test happy paths. The path that breaks is the one a subscriber takes when they want to swap one item in their next box and skip the month after that.

What we built #

A clear recommendation: pause the migration and reassess. The risks weren't theoretical and they weren't priced into the project plan. The cost story the board had approved didn't survive a serious look at the data-model translation work the migration actually required.

Underneath the recommendation, a migration-risk inventory. Every custom subscription behavior got named, documented, and rated for portability:

• Behaviors that port cleanly with platform configuration alone
• Behaviors that port with a third-party subscription app and acceptable trade-offs
• Behaviors that require custom development on the new platform
• Behaviors that have no clean equivalent and would need a redesign of the subscriber experience

For each item we estimated dev cost, dependencies, and the customer-facing impact of not porting it. The recommendation against the migration wasn't speculative. It was the sum of those four lists weighed against the timeline and budget the brand had already committed to.

What changed #

The brand chose to proceed with the migration anyway. The audit became a forecasting document for the engineering team that did the work, and the gaps it called out matched the gaps that later opened in production. Revenue did not survive the transition intact.

The methodology is what matters. A platform decision made on the basis of cost and vendor strength almost never accounts for what the old platform was actually good at.

Platform migrations aren't priced in the vendor demo. They're priced in what doesn't port. Start an audit →