The Shopify Replatforming Decision Tree: Move to Plus, Stay on Standard, or Go Headless?

Replatforming is the most expensive decision a growing Shopify brand makes that nobody wants to own. It sits in the gap between marketing (who want a faster, prettier store) and finance (who see a five figure invoice and a quarter of disruption), and it usually gets made on a gut feeling rather than a model. We think that is backwards. The platform you sit on is an infrastructure decision, and infrastructure decisions deserve a decision tree, not a vibe.

At Insiteful we scope replatforming projects for Australian brands every month, and the same question comes in four disguises: “Should we move to Shopify Plus?”, “Should we rebuild on standard Shopify?”, “Should we just optimise what we have?”, and the one a consultant planted last week, “Should we go headless?”. They feel like four separate questions. They are actually one question with four exits. This article is the literal decision tree we run, with the numbers and the failure modes attached, so you can see where your store lands before you spend a dollar.

The stakes are real. Roughly 83% of data migration projects either fail outright or blow past their budget and timeline, and poor migration execution can knock around 30% off organic traffic in the months after launch. Get the decision and the execution right and the upside is just as large: 90% of recent migrators reported revenue improvements, and roughly a third saw sales lift by 30% or more. The difference between those two outcomes is almost never the platform. It is the diagnosis.

The four real options on the table

Before the tree, name the exits. Every “we need to replatform” conversation resolves to one of these four. Naming them kills the false binary that the word “replatform” usually creates, where a founder assumes the only choice is “stay broken” or “spend $120,000 AUD on a rebuild”.

The most common mistake we see is brands conflating “rebuild in place” with “replatform”. They are emotionally identical (a new store, a project, a launch) but financially and technically very different. A rebuild keeps your platform, your data, your URLs and your SEO surface, and removes the migration risk entirely. That distinction alone has saved clients of ours from spending on a Plus migration they did not need.

The decision tree we run with every client

Here is the actual logic, simplified into pseudocode so it is unambiguous. We run a more detailed version inside a scoping spreadsheet, but this is the skeleton. Read it top to bottom and stop at the first exit that fits.

function recommend_path(store):
    # Gate 0 - is the platform actually the problem?
    if store.problem in [slow, ugly, low_converting] and store.platform == shopify:
        return "REBUILD IN PLACE"   # 70% of enquiries land here

    # Gate 1 - have you hit a hard ceiling on standard Shopify?
    if store.needs in [shopify_functions, scripts, checkout_branding,
                       b2b_native, multi_store, launchpad]:
        return "MOVE TO PLUS"

    # Gate 2 - is GMV making Plus cheaper than your fees?
    if store.monthly_gmv_aud > plus_breakeven(store.processing_rate):
        return "MOVE TO PLUS"

    # Gate 3 - are you below the Advanced plan's limits?
    if store.plan in [basic, grow] and store.needs in [advanced_reports,
                       carrier_calculated_shipping, lower_card_rates]:
        return "TIER UP TO ADVANCED"

    # Gate 4 - the headless question
    if store.monthly_revenue_aud > 3_000_000 \
       and store.has_dev_on_retainer \
       and store.front_end == "genuinely bespoke":
        return "CONSIDER HEADLESS"   # < 5% of enquiries

    return "REBUILD IN PLACE"        # default, not failure

Notice the default. When the logic runs out, the answer is “rebuild in place”, not “migrate”. That is deliberate. The burden of proof sits with migration, because migration is the option that carries the 83% failure statistic. If we cannot point to a specific capability you are blocked on, or a specific dollar figure where the maths flips, we will not recommend you move. The cheapest replatform is the one you did not need.

Signal one: when you have genuinely outgrown standard Shopify

Standard Shopify (Basic, Grow and Advanced) is far more capable than the “you must go Plus” crowd suggests. We run brands turning over several million dollars a year on Advanced without issue. The honest triggers for Plus are capability triggers, not ego triggers. You need Plus when you hit one of these walls:

You need Shopify Functions for custom logic. Functions let you write back end logic for discounts, shipping, payment customisation and bundling that runs at Shopify’s edge. They are a Plus tier feature and they routinely replace three or four paid apps. We covered this in depth in our breakdown of Shopify Functions and the apps they replace. If your discount logic is currently held together by two apps and a tag based hack, Functions is a real reason to move.

You need checkout branding and steps beyond what standard allows. Standard Shopify gives you a clean, fast checkout but limited control. Plus opens checkout extensibility, custom fields, and branded one page checkout. If your conversion problem is a checkout problem, that capability gap is worth modelling.

You need native B2B, multi store, or Launchpad. Wholesale price lists, separate B2B catalogues, sister stores under one organisation, and automated sale event scheduling are all Plus only. A brand running frequent timed drops gets direct value from Launchpad scheduling rather than a developer staying up until midnight.

Here is the test we apply. Write down the single capability you cannot get on standard Shopify. If you cannot fill that blank with something concrete, you do not have a Plus trigger, you have a build problem, and Gate 0 of the tree applies.

Signal two: when GMV makes Plus the cheaper option

The other legitimate Plus trigger is pure arithmetic. Standard Shopify charges a monthly subscription plus card processing. Advanced runs around $399 USD per month (about $299 with annual billing). Shopify Plus starts near $2,300 USD per month on a three year term and shifts to a variable platform fee (commonly cited at 0.25% to 0.40% of GMV) once you cross a high monthly volume threshold, capped at $40,000 USD per month. The number that actually moves the decision, though, is the processing rate. Plus brands negotiate lower card rates, and at enough volume that discount alone can outweigh the higher subscription.

This is the breakeven model we build for clients. It is a single line of logic, but seeing it in dollars changes the conversation.

# Rough Plus breakeven on processing savings alone (AUD)
advanced_monthly   = 460        # ~ $399 USD in AUD, monthly billing
plus_monthly       = 3_500      # ~ $2,300 USD in AUD, est.
rate_saving        = 0.003      # ~0.30% better card rate on Plus

extra_cost_per_month = plus_monthly - advanced_monthly   # 3,040
breakeven_gmv = extra_cost_per_month / rate_saving        # ~ $1.01M AUD / mo

# Translation: on processing savings ALONE, Plus starts paying for
# itself somewhere north of ~$1M AUD monthly GMV. Below that, the
# justification has to be a capability, not the card rate.

We show clients this because it reframes the question. If you are doing $400,000 AUD a month, Plus will not pay for itself on processing. It has to earn its keep through a capability (Functions, B2B, checkout) instead. If you are doing $1.5M AUD a month, the maths starts working on its own and the capabilities become a bonus. The number you plug into the model is your real negotiated rate, not the rack rate, which is why we always pull your actual Shopify Payments statements before we model this.

When staying put and fixing the build is the right call

Around seven in ten replatforming enquiries we take should never become a migration. The store is slow, dated or converting poorly, and the owner has concluded the platform is to blame. Almost always, it is the build, the theme, and the app stack. Replatforming a bad build just gives you the same problems on a new invoice.

The diagnostic we run before recommending any migration is a five point build audit. If the answer to most of these is “the build”, the recommendation is rebuild in place, and we have just saved you a migration you did not need.

Performance is the clearest example. A store that loads in 4.8 seconds does not load slowly because it is on standard Shopify. It loads slowly because it carries eleven apps that each inject render blocking script, a theme that ships uncompressed hero images, and a slider nobody uses. We walk through exactly this kind of diagnosis in our guide to Core Web Vitals on Shopify. Moving that same bloated build to Plus changes the invoice and nothing else. This matters commercially because around 53% of mobile visits are abandoned when a page takes longer than three seconds to load, and each additional second of delay cuts conversions by roughly 7%. A rebuild in place attacks that directly, at a fraction of the cost and none of the migration risk.

Where headless actually fits (and why it usually does not)

Headless is the option a strategy deck loves and a balance sheet rarely does. Decoupling your front end from Shopify’s back end can deliver a genuinely bespoke experience and excellent performance. It also multiplies your cost and your operational complexity, and for the overwhelming majority of Australian brands it is the wrong tool.

The numbers are the argument. A Hydrogen based headless build commonly runs $30,000 to $150,000 USD or more to build, with a twelve month total cost of ownership of $80,000 to $200,000 USD once you add the ongoing developer retainer. That is widely estimated at three to five times the total cost of ownership of a standard Shopify Plus setup, and it comes with permanent dependency on skilled React developers. You are no longer managing one vendor. You are coordinating a front end framework, a hosting layer, the Storefront API, and every app you now have to re implement because it no longer drops into your theme.

Our position is that headless earns its place only when a brand is past roughly $3M AUD in revenue, has a developer or team on retainer, and has a front end requirement that is genuinely impossible inside a well built Liquid theme. That is a real but narrow set. For everyone else, the same performance and design ambitions are achievable on native Shopify with a properly engineered theme. We made the full case in why we do not build headless stores. The short version: native Shopify, built well, gets you most of the performance ceiling without the headless tax. The decision tree only reaches the headless exit when all three gates are true, which is why fewer than one in twenty of our enquiries land there.

The AUD cost picture

Replatforming budgets get quoted in ranges so wide they are useless. Here is how the real money breaks down for an Australian mid market brand, in AUD, so you can sanity check any quote you receive.

Two things stand out. First, “rebuild in place” and “move to Plus” cost roughly the same to build, because the work (theme, app stack, QA) is the same. The difference is the ongoing platform fee and the migration risk, which is exactly why the capability question has to come first. Second, headless is not a little more expensive, it is an order of magnitude more expensive across the life of the store. Industry data puts most replatforming projects in the $25,000 to $500,000 USD range depending on scope, and the brands at the top of that range are almost always paying the headless premium. We size our own build and Plus migration work for Australian brands in the $8,500 to $25,000 AUD range, and we will tell you when your problem is small enough that the bottom of that range, or a simple tier up, is all you need.

The migration risks the decision tree is designed to avoid

The whole point of the tree is to keep you out of the migration failure statistics unless the move is genuinely justified. When a migration is justified, the risk does not disappear, it just becomes manageable. These are the three failure modes we plan against on every project, and the artefacts we use to neutralise them.

Data migration failure (the 83% problem). The single biggest risk is the data move itself. We never run a production import without a dry run on staging first, with verified row counts on every entity (products, variants, customers, orders, redirects). The rule is simple: if the counts do not reconcile on staging, the production import does not run.

SEO collapse from broken URLs. A botched migration tanks organic traffic because old URLs return 404s and equity evaporates. The fix is a complete redirect map built before launch, not after. A fragment of the mapping logic we generate looks like this:

# Old platform URL pattern  ->  New Shopify URL pattern
/product-category/{cat}/    ->  /collections/{cat}
/product/{slug}/            ->  /products/{slug}
/blog/{year}/{month}/{slug} ->  /blogs/news/{slug}
/account/orders             ->  /account

# Every legacy URL with traffic or a backlink gets an explicit 301.
# We pull the list from Search Console + the old sitemap, not guesswork.

We have used disciplined redirect work to hold six figure SEO surfaces through a migration, the same approach we detail in our WooCommerce to Shopify migration breakdown and our Magento to Shopify timeline.

Downtime at cutover. Operational disruption during a switch is expensive. Some industry estimates put the cost of unplanned IT downtime at around $5,600 USD per minute for larger operations. We schedule DNS swaps for a midweek evening in Melbourne time, monitor LCP, conversion rate and 404 patterns live for the first 48 hours, and hold the project open for 30 days specifically to catch the long tail of redirect issues.

How we do it at Insiteful

Our replatforming engagement starts with the decision, not the build. The first deliverable is not a quote, it is a recommendation, and that recommendation is frequently “do not migrate”. We would rather lose the larger migration invoice and keep the relationship than sell you a Plus move you will resent in six months.

Phase one, the diagnosis. We pull your Shopify Payments statements, your Search Console data, your app list and your current Core Web Vitals, and we run the decision tree against real numbers, not assumptions. You get a one page recommendation with the exit, the reason, and the dollar model behind it.

Phase two, scope and breakeven. If the recommendation is Plus, we model the breakeven on your real negotiated processing rate, not the rack rate, so the case is honest. If it is a rebuild in place, we scope the theme and app rationalisation work and show you the performance and conversion upside without touching your platform, data or URLs.

Phase three, the build and the safety net. Whatever path you take, the migration discipline is the same: staging first, reconciled data counts, a complete redirect map built before launch, a midweek cutover, and live monitoring on the metrics that matter for the first 48 hours. We hold the project open for 30 days after launch to clear the redirect long tail, and we measure success against your pre migration baseline, not against a vanity launch metric.

The reason we lead with the decision tree is that it is the part most agencies skip. It is far easier to sell a big rebuild than to tell a client their platform is fine. But the brands that come back to us, and refer us, are the ones we talked out of an unnecessary migration as often as the ones we built a new Plus store for.

Where your store probably lands

If you take one thing from this, make it the order of the gates. The question is never “should we replatform”. It is “what specific capability are we blocked on, or what dollar figure flips the maths”. Answer that first, and the path falls out of the tree. For most brands the honest answer is a rebuild in place, which is the cheapest, lowest risk and most underrated option in the whole conversation. For a real minority, Plus is a clear win backed by a number. And for a tiny few, headless earns its premium. The expensive mistakes happen when brands skip the diagnosis and reach for the most dramatic exit because it feels like progress.

If you want the decision run against your real numbers rather than a hunch, that is exactly the scoping work we do. Bring your Payments statements, your Search Console data and your app list, and we will tell you which of the four exits your store should take, and just as often, which one it should not.