Press Enter to search or Esc to close

Migrate off Shopify: what carries over to a custom build and what you should rebuild clean

Migrate off Shopify: what carries over to a custom build and what you should rebuild clean

Your Shopify product catalog, order history, and five years of customer records migrate cleanly to a custom build; the platform fee, the app stack, and the constraints that drove you here stay behind.

If you're doing $40,000 a month on Shopify and your checkout flow runs through three separate apps, a Liquid snippet someone added two years ago, and a workaround you're too embarrassed to put in the onboarding docs, you already feel it. Fifteen years and 760 custom builds in, I've seen that setup walk through the door every few months. People at that stage usually don't need convincing that something's wrong. What they need is a clear read on what actually moves with them if they leave, and what they're better off rebuilding from scratch.

That's what this is.

When Shopify still makes sense

I want to say this clearly before anything else: Shopify is a good product for what it's designed to do. Straightforward retail, standard fulfillment, no unusual pricing logic, no need to own the checkout experience top to bottom. If that's your business, a custom build would be overkill. The development cost, the ongoing maintenance, the time to spec it properly: none of that pays off when the platform already fits. A builder who tells everyone they need custom work isn't giving you a straight read.

The situations where leaving makes sense have a pattern. You're running wholesale logic on top of a retail platform. You've got pricing rules that need a stack of apps to approximate. Your fulfillment branches in ways no combination of Shopify's native tools covers cleanly. If you're spending real hours every month managing the system instead of the business, that's the signal.

What transfers cleanly

The good news first. Your product catalog, order history, and customer records transfer without drama. These live in your data, not in Shopify's logic layer. A standard export pulls everything: SKUs, variants, images, metafields, tags, customer purchase history, lifetime value, email lists. If you've got 4,200 products and five years of order data, all of that lands cleanly in a new database.

Shopify stores your data in a structured format that's straightforward to export and import. We've migrated catalogs from 80 SKUs to over 12,000. The size rarely causes problems. What does occasionally take work is old data hygiene: duplicate customer records, inconsistent tags, archived products that were never cleaned up. That's a normal part of any migration audit, not a blocker.

One thing worth knowing: your Shopify theme doesn't transfer. The frontend gets rebuilt as part of the custom build, which is mostly a benefit. It's designed around your actual content and workflow, not around a template someone else wrote.

What you leave behind on purpose

Shopify's checkout logic doesn't transfer, and you don't want it to. That checkout experience was built around Shopify's assumptions about retail. If your business has grown around workarounds for those assumptions, a migration is your chance to design checkout around how you actually sell.

The app stack stays behind. Every app you've installed was solving a problem the platform didn't handle natively. Subscription billing, tiered B2B pricing, custom wholesale portals, complex discount stacking: all workarounds. On a custom build, that logic lives in the system. No monthly subscription for each feature. No API rate limit that bites you when order volume spikes. No third-party update that breaks your integration overnight.

The Liquid hacks stay behind. The Zapier zaps stay behind. Two years of patching gaps between tools is not a process. It's an adaptation to a platform that wasn't quite the right fit.

A custom build doesn't replicate your Shopify setup. It replaces what that setup was trying to do, without the constraints that shaped it.

The fee and constraint trade-off

Let me put numbers on this, because the math is part of the decision.

Shopify Advanced runs around $400 a month, with a 0.5% transaction fee on every order. At $500,000 in annual revenue, that's roughly $2,500 a year in transaction fees before you count the platform subscription. Add six to ten apps at $50 to $200 per month each and you're looking at $8,000 to $15,000 a year just to operate within the platform. That's not infrastructure cost. It's the ongoing rent for functionality your business depends on.

Shopify Plus drops the transaction fee but runs $2,000 a month, $24,000 a year. At $2 million with a complex operation that Plus genuinely enables, the math can hold. At $400,000, it's a significant overhead for a system you're already working around.

A custom build carries a one-time development cost and hosting that typically runs $50 to $300 a month. No transaction percentage. No per-feature subscription. No ceiling on what the next feature can be.

The crossover point tends to sit between $300,000 and $700,000 in annual revenue, depending on your app stack. Above that line, a custom build typically covers its development cost within 18 to 24 months and removes the ceiling at the same time.

Is your app stack costing $8,000 to $15,000 a year to approximate logic your business should own outright? A custom build is the direct answer to that question: a checkout designed around how you actually sell, business rules (tiered pricing, fulfillment branches, payment terms) written into the system instead of patched from subscriptions, and no transaction percentage or per-feature rent once the build is live. The development cost typically recovers within 18 to 24 months at the revenue level where a migration makes sense, and the workarounds don't carry forward. Build your store on a codebase you own

Before and after: one workflow rebuilt clean

A client came to us running wholesale on Shopify. Tiered pricing by customer group, minimum order quantities that varied by product category, net-30 payment terms for certain accounts. Shopify handles none of that natively.

Their setup: a wholesale app at $189 a month, a B2B portal plugin at $79 a month, custom Liquid to show and hide pricing by customer tag, a Zapier zap that wrote qualifying orders to a Google Sheet, and a manual step every morning where someone checked that sheet and updated a tag in Shopify to release the order for fulfillment.

Four tools, one daily manual task, and $268 a month to approximate functionality the business needed to own outright. That's $3,216 a year in subscriptions, not counting the Liquid template nobody wanted to touch or the daily step that couldn't be skipped.

The rebuilt version: customer groups with tiered pricing stored in the database, minimum quantities enforced at the cart level, net-30 accounts flagged automatically and routed to an approval queue, and one internal dashboard where the team sees pending approvals, open orders, and account status.

The daily spreadsheet check is gone. All four subscriptions are gone. The Liquid hack is gone. The Zapier zap is gone. Processing time dropped from the next morning to immediate. What replaced them is a system shaped around how this business actually works.

How a migration actually runs

A Shopify migration to a custom build typically takes eight to ten weeks from first call to go-live.

The first call usually runs about an hour. We go through the current setup, the pain points, the workflows that need to work differently, and the data that needs to come across. From there we scope the build and agree on a timeline before any code is written. No guessing on your end about what's included.

Week one is a data audit: full export, structure review, anything that needs cleanup before import. Weeks two through five are the build: data layer, business logic, frontend, in that order. Weeks six and seven are parallel testing, where both systems run live and we compare outputs on real transactions.

Go-live is a cutover, not a launch event. Shopify stays live until the custom build has processed real orders cleanly for at least a week. If anything surfaces in that window, it gets caught before it touches a customer.

What's different from working through a platform or a large agency: there's no handoff to a ticket queue. You're talking to the person who built the system, who knows where every piece of logic lives and why. Questions in the first few weeks get answered the same day.

How to start

Before anything else, ask yourself one question: what's the next thing I need to do on this platform, and can I actually do it cleanly, without a hack?

Not "can another app handle it." Can the platform do the thing your business needs, the way it needs it done.

If the honest answer is no, that's where the conversation starts. You don't need a full spec. A short description of the workflow that's giving you trouble is enough to open a conversation. We'll tell you directly whether a full migration is the right call or whether a cleaner fix exists on your current stack. Not every conversation ends in a rebuild.

But the ones that do usually start with one specific thing that stopped working the way it should.

If the annual app subscriptions and transaction fees have crossed the point where a custom build pays back within two years, move to a custom e-commerce build

Related Articles

  • Client Login

    Restore password
  • New Registration

or
Make sure @fastw3b.com email domain is white-listed in your email client to restore password, verify registration, get order confirmations, etc.