Replatforming is one of the most expensive decisions an ecommerce business can make, and most of the advice available online skips straight to execution, pick a partner, map your product data, plan your redirects, build a timeline. That’s useful once you’ve already decided to move. It’s the wrong starting point if you haven’t decided yet.
This is not a migration checklist. It’s an evaluation checklist, the questions worth working through before you sign off on a Shopify Plus upgrade, a full theme rebuild, or a switch away from Shopify entirely, so you can be confident replatforming actually solves the problem you think it does.
If you’re already sold on the move and just need the execution steps, our Shopify migration checklist covers that ground. Here, we’re focused on the decision itself: what’s actually broken, what replatforming can and can’t fix, and how to pressure-test the business case before budget gets committed and a project kicks off.
Why the evaluation phase is a separate step from migration planning
Once a replatforming project starts, momentum takes over. Timelines get set, a development partner gets briefed, and stakeholders start planning around a go-live date. That’s exactly why the evaluation has to happen first and separately, it’s the only point in the process where you can still walk away, choose a smaller fix, or change direction without sunk cost clouding the judgement.
In our experience scoping Shopify projects for Australian merchants, the decision to replatform tends to get made for one of three reasons: a genuine platform ceiling has been hit, a competitor or industry peer switched and it seemed like the thing to do, or an agency pitch made replatforming sound like the fix for a problem that was never actually about the platform. Only the first one holds up under scrutiny. The other two are how businesses end up spending six figures on a rebuild and discovering the original problem, slow page speed, poor conversion rate, weak organic visibility, is still there twelve months later, just on a different stack.
The goal of an evaluation phase is to separate symptom from cause before money moves.
Signals that genuinely justify replatforming, and the ones that don’t
Some reasons to replatform are well-founded. Others are commonly mistaken for platform problems when the real issue sits somewhere else entirely.
Reasons that usually hold up:
- You’ve hit a genuine feature ceiling, for example, you need checkout customisation (custom shipping logic, complex discount stacking, checkout UI extensions) that standard Shopify checkout doesn’t support, and only Shopify Plus’s checkout extensibility framework can deliver it.
- Your B2B or wholesale requirements have outgrown what’s achievable without a platform tier change, company accounts, net payment terms, tiered pricing at scale, or custom quoting workflows.
- You’re consistently hitting API rate limits or integration ceilings that are documented platform constraints, not app misconfiguration.
- Order volume, GMV, or entity complexity (multiple brands, storefronts, or currencies under one operation) has moved you into territory Shopify itself scopes differently, this is the point where it’s worth reading is Shopify Plus actually worth it rather than assuming a full platform migration is required.
- Shopify has deprecated or is sunsetting a feature your store depends on (this has happened before, for example with checkout.liquid customisation), and there’s no supported path forward on your current tier.
Reasons that usually don’t:
- The site feels slow. In most audits we run, this traces back to app bloat, unoptimised images, or a heavy theme, not a platform limitation. Shopify’s infrastructure handles enterprise-scale traffic without difficulty; the store built on top of it is usually where the drag comes from.
- Conversion rate is underperforming. This is far more often a UX, offer, or checkout-friction problem than a platform one.
- Organic traffic has plateaued or declined. Technical SEO issues, thin collection content, weak internal linking, missing structured data, poor Core Web Vitals from third-party app scripts, are rarely solved by moving platforms, and a replatform done without an SEO migration plan can make rankings worse, not better.
- “Everyone in our category is doing it.” Competitor behaviour isn’t a business case.
- An agency has told you your current build is “outdated” without pointing to a specific, documented limitation you’re bumping into today.
If your reasons sit in the second list, replatforming is very likely the wrong first move, a targeted fix (performance optimisation, a CRO pass, an SEO audit) will get you further for less money and far less risk.
The Shopify Replatforming Evaluation Checklist
Work through these in order. Each step is designed to either validate the case for replatforming or surface a cheaper, faster alternative.
-
Write the problem down in one sentence, without mentioning a solution. Not “we need to move to a headless build”, instead, “our checkout can’t handle net-30 terms for wholesale accounts.” A clear problem statement makes it obvious whether replatforming is actually required.
-
Separate platform-level limitations from store-level issues. Get a technical audit of the current build, theme performance, app stack, data structure, integrations, before assuming the platform itself is the constraint. Most stores we assess have store-level issues masquerading as platform issues.
-
Check whether a tier change solves it before assuming a full switch is needed. Moving from standard Shopify to Shopify Plus is a significant step, but it’s not the same undertaking as leaving Shopify altogether. Compare the two properly using something like our Shopify vs Shopify Plus comparison before scoping a bigger project than you need.
-
Inventory every app, integration, and custom code dependency on your current build. ERP connections, freight and fulfilment integrations, loyalty and review apps, custom Liquid, each one needs to be re-mapped or replaced on the new platform, and this is usually where replatforming budgets and timelines blow out.
-
Model the real cost, not just the build quote. A replatform is development cost plus app re-subscription costs, plus the SEO risk of a large-scale URL and content change, plus the internal time cost of testing and QA, plus a period of reduced velocity on other projects while the team is focused on migration. Ranges vary hugely by scope and complexity, but treat any quote that only covers development hours as incomplete, resources like our Shopify migration cost guide and Shopify agency cost guide are useful for sanity-checking a quote against realistic Australian market ranges.
-
Assess SEO and URL structure risk specifically. If you’re changing platforms (rather than staying on Shopify and upgrading tier), your entire URL structure is at risk of changing. Map how redirects, canonical structure, and existing rankings will be preserved before you commit, this is a distinct risk from the development cost and deserves its own sign-off.
-
Check timing against your trading calendar. Migrations like this typically take somewhere in the order of six to twelve weeks depending on scope, longer for complex B2B or multi-entity builds. Scheduling a go-live in the lead-up to your peak trading period is one of the most common and most avoidable mistakes we see.
-
Confirm internal capacity, not just budget. Someone on your team needs to own QA, content migration sign-off, and stakeholder communication throughout the project. If nobody has the bandwidth, that’s a real constraint on timing, not a detail to solve later.
-
Define what success looks like and how you’ll measure it. “Faster site” or “better SEO” aren’t measurable outcomes. Set a specific, checkable target, page load time, conversion rate, organic traffic recovery timeline, before the project starts, so you can actually tell afterwards whether replatforming delivered.
-
Get an outside technical opinion before signing off. An external audit, separate from whoever is pitching you the rebuild, is the cheapest insurance in the entire process. It either confirms the case for replatforming or saves you from a project you didn’t need.
When to bring in a specialist
Working through this checklist internally will get you most of the way to a sound decision, but the technical audit in steps two and six, separating platform limitations from store-level issues, and quantifying SEO risk, is genuinely hard to do objectively from inside the business. This is exactly the kind of evaluation our Shopify replatforming work is built around: an independent assessment of whether replatforming is the right call, what scope actually makes sense, and what the realistic cost and timeline look like before anything is built.
Frequently asked questions
How do I know if my Shopify problems are platform issues or store issues?
Start with a technical audit of your current theme, app stack, and integrations before assuming the platform itself is the limitation. In our experience, the majority of performance and conversion issues raised as “reasons to replatform” trace back to app bloat, theme customisation, or content gaps rather than anything Shopify’s core platform is actually preventing.
Is moving to Shopify Plus considered replatforming, or just an upgrade?
It sits somewhere between the two. You keep the same core platform and much of your existing setup, but checkout behaviour, app ecosystem access, and some technical capabilities change meaningfully enough that it deserves the same evaluation rigour as a full replatform, not a decision made on a sales call alone.
How long does a proper replatforming evaluation take?
For a straightforward store, working through an evaluation checklist like this one can take one to two weeks, mostly spent on the technical audit and cost modelling steps. For complex B2B, multi-entity, or highly integrated stores, allow closer to three to four weeks to get a defensible answer.
What’s the biggest mistake merchants make when deciding to replatform?
Treating a symptom, slow site, weak conversion, flat organic traffic, as proof the platform is the problem, without first confirming that a targeted fix wouldn’t solve it for a fraction of the cost. The second most common mistake is under-costing app re-integration and SEO risk in the initial business case.
Does replatforming guarantee better SEO or performance?
No, and it can genuinely make both worse if the migration isn’t planned with SEO and performance in mind, lost redirects, flattened content, and untested Core Web Vitals on the new build are common outcomes of a rushed migration. Replatforming creates the opportunity to fix these things properly; it doesn’t fix them automatically.
Ready to get a clear answer?
If you’re still weighing whether replatforming is genuinely the right call, an outside opinion is worth more at this stage than another internal debate. Book a call with our team and we’ll help you work through the evaluation properly, before any development budget is committed.
