When You Replatform, What Happens To The Reporting Everyone Relies On?

Replatforming decisions are everywhere in retail right now: a move to Shopify Plus, a shift to headless or composable commerce, a consolidation of two brands onto one stack. Vendors pitch the parts of a migration that are easy to demo: catalogue, checkout, fulfilment, personalisation. Unfortunately, reporting gets less planning time, despite providing the daily dashboards, exports, and numbers that trading, merchandising, and finance teams check every morning.

If you're looking into a similar move, this is a question worth sitting with before a single vendor conversation happens: can the reports that your trading and merchandising teams rely on be available and reliable on day one? We’ve seen this play out in practice- after smoothly migrating two sister brands within a global fashion e-commerce group from a legacy platform to Shopify, the company asked: could they still see their operations as clearly as before?

The assessment for platform migration ran across eight weeks: scoping and metric mapping for the first brand, a Shopify investigation phase, then a second pass repeating the same rigour for the second brand once its review started. Reporting deserved that dedicated runway precisely because it's easy to assume it'll "just work" once the transactional side is live.

The proposition: mapping 433 metrics, and finding a 60% gap

Mindera approached it the way we'd want any migration reporting workstream approached: through documentation analysis, business validation, and hands-on exploration of what the new platform actually offered, rather than what its marketing implied. Across the two brands' existing reports, we mapped 433 individual metrics. Working with each business, we narrowed that down to the 146 they considered critical, the numbers that show up in a trading review, not a nice-to-have buried three tabs deep.

Then we checked each one against Shopify's native reporting. For one brand, 37% was a direct match. For the other, 39%. That leaves roughly six in ten of the metrics each business had flagged as critical without a native equivalent on day one.

These weren't obscure edge cases. They were things like return-reason tracking, cancellation splits by cause, the markdown-versus-full-price breakdown of sales, and average processing time across each stage of order fulfilment: the exact numbers a merchandising or trading team pulls up daily, not once a quarter. The gap ended up being business-wide, touching order management, operational and business reporting, and pricing analysis roughly equally.

Shopify itself isn't a thin reporting product. It organises its analytics into eleven categories spanning the full order lifecycle, from acquisition and marketing through to fulfilment, returns and finance, and we mapped 402 Shopify-side metrics in total to compare against. The gap wasn't a case of the new platform offering too little. It was a case of the new platform organising and defining things differently enough that a straight one-for-one carryover was never realistic, and that kind of mismatch only surfaces once someone sits down and checks, report by report, rather than assuming.

What this means for your own migration

Note, that none of this means Shopify, or any platform, is the wrong choice. It means "feature parity" as a vendor claim is almost always scoped to the transactional experience, and reporting parity has to be checked separately, on its own terms.

If you're heading into a similar migration, test every report against the new platform before go-live, rather than assuming continuity because the platform is objectively more capable overall. Export raw data for the metrics that don't have a native home yet, so the business isn't flying blind while a longer-term fix gets built. And make a deliberate call, report by report, on which gaps are worth closing with custom development or a third-party app, and which the business can simply retire because nobody was actually acting on that number anyway.

Most importantly, give reporting its own workstream and its own timeline inside the migration plan, running in parallel with the transactional cutover rather than as an afterthought once the "real" migration is done. That's the single change that would have turned this from a surprise into a scoped, manageable piece of work.

The scoping discipline matters as much as the fix itself. Not every metric a business has ever tracked deserves equal attention; narrowing to what the business actually considers critical is what makes the rest of the exercise tractable. A migration team that tries to preserve every legacy report by default will spend months rebuilding things nobody was reading. One that skips the scoping step entirely will discover the gaps live, in front of the people who most need the numbers to be right. Validating what matters with the business first, then checking it rigorously against the new platform, is what actually protects decision-making through the transition.

The real risk in a platform migration usually isn't whether checkout works on day one. It's whether the business can still see itself clearly on day one, and whether anyone scoped that question before go-live rather than after.

Key takeaways

• We mapped 433 metrics for two sister fashion brands migrating to Shopify, narrowing to 146 business-critical ones.
• Only 37–39% of critical metrics directly matched the new platform's native reporting, a ~60% gap.
• Gaps clustered around returns, cancellations, markdowns and fulfilment timing: daily operational metrics, not rare edge cases.
• Reporting deserves its own workstream, tested and signed off in parallel with the transactional migration, not after it.
• Where gaps exist, decide deliberately between custom development, raw data export, or simply retiring a metric nobody was really using.

We're always happy to walk through what a reporting gap analysis could look like ahead of your own migration, so the surprises show up in a workshop instead of a trading meeting.