Insight

When to replatform to Shopify (and when to stay put)

Most Shopify replatform projects don't start with a strategy. They start with a bad week. A checkout outage during a sale, a security patch that broke three integrations, a developer quote for a "simple" change that came back at six weeks and five figures. Someone in the room says "we should just move to Shopify," everyone nods, and a decision that will shape your operations for the next four years gets made on frustration.

I've run replatforms and migrations. The frustration is usually justified. The conclusion sometimes isn't. Before you commit budget, you need to separate the platform you've genuinely outgrown from the process problem you're about to carry across to a new one at considerable expense.

The signs you've actually outgrown your platform

There's a real version of "we need to replatform," and it has specific symptoms. Not vibes. Symptoms you can point at.

  • The maintenance tax is eating your roadmap. If your developers spend more time keeping the current build alive, patching, upgrading, fighting dependency conflicts, than shipping anything that grows revenue, you're paying a maintenance tax on an asset that's depreciating. Magento merchants know this one intimately: the platform is powerful, but the total cost of keeping a self-hosted build secure and current is where the business case for a Shopify migration usually gets made.
  • You've hit an integration ceiling. Every new tool needs a custom connector, every connector needs a specialist, and the specialists have a queue. When your platform can't talk to the systems your business already runs on without a project attached, it's constraining the business rather than serving it.
  • Security and hosting have become your problem. If you're personally worried about PCI compliance, patching cadence, and whether your host can handle Black Friday, you're carrying operational risk that a hosted platform is designed to absorb. That's not a failure of nerve. It's a signal about where your time is worth spending.
  • You can't ship changes at the speed the market moves. When a merchandising tweak or a new landing page requires a developer, a ticket, and a fortnight, marketing stops asking. The store calcifies. That's a genuine growth cost, and it's often the most expensive symptom of all because you never see it on an invoice.

If two or three of these are true and persistent, you haven't got a bad month. You've got a structural mismatch between your platform and your business. That's a legitimate reason to replatform.

The signs you're blaming the platform for a process problem

Here's the part nobody wants to hear. A lot of "we need to replatform" is a business trying to buy its way out of a problem no platform can fix.

Ask yourself honestly: is the platform slow, or is your approvals process slow? Is the tech stopping you from shipping, or is it three stakeholders who can't agree on the homepage? I've watched organisations spend heavily to move to a new platform and arrive with exactly the same problems, because the constraint was never the software. It was the operating model around it.

A few tells that you've got a process problem wearing a platform costume:

  • Nobody can tell you what "better" looks like in numbers. If the goal is "modern" or "easier" rather than a measurable outcome (conversion, page speed, time to publish, cost to serve), you don't have a business case. You have a mood.
  • The current platform is under-used. You're at the ceiling of your capabilities on paper, but half the features you're paying for are switched off or misconfigured. Migrating won't fix an implementation you never finished the first time.
  • The real complaint is about people or process. Slow content updates, no clear ownership, a marketing team locked out of their own store. New software won't hand your team permissions and a workflow. That's a decision, not a download.

Replatforming to escape a process problem is one of the most expensive mistakes in ecommerce, precisely because it feels like progress while you make it.

When Shopify is the right destination, and when it isn't

Assume you've genuinely outgrown your setup. Shopify still isn't automatically the answer, though it's the right answer more often than not for Australian mid-market retailers.

Shopify, and Shopify Plus at the larger end, wins clearly when you want the hosting, security, and platform maintenance to stop being your problem, when you want your marketing team shipping changes without a developer in the loop, and when the app ecosystem covers most of what you need without bespoke builds. That describes a large share of mid-market retail, which is why the move to Shopify has become the default path off ageing Magento and bespoke builds.

Be more careful when your business logic is genuinely unusual, deep B2B pricing rules, complex configurable products, or a fulfilment model that doesn't fit standard patterns. Shopify can handle a lot of this, but the honest question is whether you're adopting the platform's way of working or fighting it with apps and workarounds. Fighting it reintroduces the exact maintenance tax you're trying to leave behind. My Shopify platform page goes deeper on where it fits and where it strains.

The part everyone under-scopes: integration

Here's where replatforms actually leak ROI, and it's almost never the storefront.

The storefront is the visible part, so it gets the attention, the design mockups, the stakeholder demos. But the storefront is maybe a third of the real work. The other two thirds is integration: your ERP, your inventory system, your fulfilment and shipping, your accounting, your CRM. That's the plumbing that keeps orders flowing and stock accurate, and it's invisible right up until it breaks on go-live.

I saw this pattern on a replatform where the storefront was signed off weeks early and everyone relaxed, then the inventory sync between the new platform and the warehouse system turned into the entire critical path. Orders were selling stock the warehouse didn't have. The lesson generalises well beyond ecommerce: on a replatform for a large-volume residential home builder, the same rule held. The visible rebuild was straightforward. Governing how the new system exchanged data with everything already running the business was the whole job. Replatform governance is integration governance.

So when you scope a Shopify replatform, scope the integrations first and hardest. If a vendor's proposal spends three pages on theme design and one paragraph on ERP and inventory sync, that proposal is going to hurt you.

A short framework before you commit

Run these four checks before you sign anything.

  • Name the outcome in numbers. What measurable result justifies this spend, and how will you know within 90 days of launch whether you got it? No number, no project.
  • Separate platform from process. Write down every complaint, then mark each one "the software can't do this" or "we haven't set this up." If most sit in the second column, fix the process first.
  • Map the integrations before the storefront. List every system the store must exchange data with and how reliable that exchange needs to be. That map is your real scope and your real risk.
  • Pressure-test the destination. Confirm Shopify fits your business logic natively rather than by workaround, and be honest where it strains.

Replatforming is a genuine growth lever when the mismatch is structural and the integration work is respected. It's an expensive way to relocate a process problem when it isn't.

If you're not sure which situation you're in, a website health check is the cheapest way to find out before you spend the big money.