Written by Felipe Arango from iDeum
Shopify Plus to Vendure
For the Plus store that has started paying, in apps, workarounds and monthly fees, to reach past the platform. What moving to Vendure actually involves, what ports and what gets rebuilt, and how to tell whether it is worth it.
- Timeline
4–7 months
For a mid-market store. Driven mainly by how many integrations you re-point, not by catalogue size.
- Shopify Scripts
30 Jun 2026
The day Script Editor logic stopped running (Shopify changelog). Every store with Script logic rewrote it on Shopify's timetable, not its own.
- B2B order cap
500 lines
Per order on Shopify's native B2B, and draft orders too, so quoting a large basket as a draft does not escape it (Shopify B2B considerations).
- Passwords exported
0
Shopify's customer export has no password field, and Shopify gives no way to read password hashes. Customers set new ones from verification emails sent in batches around cutover.
Stay on Plus, unless you have outgrown it
Shopify Plus is a good platform. If your store is brand-led D2C, your checkout is standard, and your catalogue fits inside it, you should probably stay. Migrating would cost you more than it returns.
This guide is for the other case: the store that has started paying, in apps and workarounds and monthly fees, to reach past the platform for things it will not let you change. If that is your store, here is what moving actually involves, and how to tell whether it is worth it.
The migration in five moves
- 1
Sort the custom work
Walk the theme, apps, Functions, Flow and metafields, and put every item in retire, redesign or adopt.
- 2
Move the catalogue
Products, variants, collections and customers, imported and diffed against Shopify until the difference is zero.
- 3
Build storefront and checkout
The largest single piece of work, run as its own project with its own lead.
- 4
Re-point the integrations
Payments first, then ERP and accounting, then tax, fulfilment and email.
- 5
Cut over
A short freeze, redirects at the edge, password emails in batches, and Plus kept read-only.
Each move has its own section below. The first one costs an afternoon and decides the size of the other four; the order of the rest is built to protect revenue.
Why teams make the move
Two reasons come up in almost every conversation with a Plus merchant who is already looking around.
The first is that going headless is a real engineering commitment, not a setting you switch on. Teams running Shopify's Hydrogen in production report the same costs each time. Third-party pixels and consent wiring have to be rebuilt by hand, because single-page navigation does not fire the pixels a Liquid theme fires for free. The apps that plug into a theme, things like reviews and financing widgets, mostly do not carry over, so working integrations need rebuilding rather than porting. And routine content edits stop being a merchant task and become an engineering ticket.
The second is that the checkout is a blind spot for measurement. Everywhere else in the funnel you can see and attribute what a customer does. Inside Shopify's hosted checkout and Shop Pay, that visibility stops. You do not own the checkout, so serious conversion work turns into a set of workarounds bolted onto the platform. Once the checkout is your own storefront code talking to the Shop API, measurement is part of the site again.
Underneath both is one pattern. The ceiling on customisation sits in a fixed place, and Shopify keeps moving that ceiling on merchants who already built around it. Shopify Scripts, the checkout logic in the Script Editor, stopped running on 30 June 2026 (Shopify changelog). Every store with legacy Script logic had to rewrite it on Shopify's timetable, whatever platform they end up on. That is not a reason to panic about Shopify. It is a reason to notice that when a rewrite is coming either way, choose a target whose roadmap you control.
Is this you?
Four questions decide whether this guide applies to you.
| Question | If yes | If no |
|---|---|---|
| 01Do you have, or can you resource, a dev team comfortable with TypeScript and GraphQL? | If yesYou can own the build. | If noBring in a partner to run it. That is what the partner network is for. |
| 02Is your store B2C today, with B2B as a growth target rather than the current core? | If yesSequence B2C first, as below. | If noTalk to us about the B2B path directly; you may sequence differently. |
| 03Is checkout control, data ownership or platform independence a real business priority? | If yesThis is the trade you are making. | If noShopify Plus may already give you what you need. |
| 04Are you past launch, with real traffic and a catalogue worth migrating carefully? | If yesThe phased approach protects that traffic. | If noA newer store is easier to build on Vendure from day one. |
Most teams that read this far answer yes to the first three. If you answered no across the board, stay where you are and put the budget into merchandising instead. A migration you do not need is the most expensive project on the roadmap.
Sort everything into retire, redesign and adopt
Every Plus store keeps its custom work in five places: the theme, the apps, Shopify Functions, Flow automations, and the metafields you added to stretch the data model. Before anyone writes an import script, walk all five and sort each item into one of three buckets.
That sort is the most valuable hour in the whole project. It turns "migrate everything" into a scoped plan with a clear first step.
Workarounds the platform made you build. Wholesale apps that fake company pricing with tags. Apps whose only job is to move data between two other apps. The test: if it vanished tomorrow and you would rebuild only its data, it belongs here.
Logic that is genuinely yours, rebuilt natively instead of bolted on. Company accounts and price lists. Discount logic as promotions. Flow automations as event subscribers.
Commodity you once customised because Shopify made you. The cart and order states, tax calculation, search, account pages.
After the sort, a sequence built to protect revenue
- 01
Catalogue first
Products, variants, collections and customers move as data through the Admin API. Import, then diff against Shopify on SKU count, price totals and stock. Fix the script and repeat until the difference is zero. This is the least stateful data and the easiest to check, so get it right before anything depends on it.
- 02
Storefront and checkout
The largest single piece of work, because Shopify used to do it for you. Give it its own lead and treat it as its own project, especially coming off a Hydrogen build, where less carries over than instinct suggests.
- 03
Integrations, in the order that protects revenue
Payments first, tested end to end in sandbox before anything else moves. Then the ERP and accounting systems, which a small plugin now feeds from Vendure's event bus instead of Shopify webhooks. Then tax, fulfilment and email. Your systems of record stay where they are. What changes is the commerce layer they talk to.
- 04
Cutover
A short freeze window for customers and order history near go-live. Redirect rules live at the edge before the domain moves. Passwords do not leave Shopify, and creating a customer through the Admin API sends a verification email straight away. Turn off the verification email during the import, then send the emails yourself in batches over the first days so customers set new passwords. Keep Shopify Plus read-only for a while for refund lookups and support, timed to your contract renewal.
The decision to make in week one
One decision drives more scope than any other, and teams leave it too late: what to do with order history. Archive everything as a read-only record and import the last twelve months as live orders. Make that call in week one, in writing, with finance in the room. Left open, it re-scopes the data phase halfway through the build.
What ports, and what gets rebuilt
Moves as data
- Products, variants, options and images
- Collections, tags and product types
- Metafields, once you give them types
- Customers, addresses and B2B companies
- Order history, and a redirect map for the edge
Gets rebuilt, or left behind
- The Liquid theme and the hosted checkout
- Discount codes, Functions and Flow automations
- A Hydrogen storefront's data layer, though its components and routing carry over
- Customer passwords and full gift-card codes, which Shopify never exports (customers, gift cards)
- App data and analytics history
Sequence B2C first, then B2B
For a store running both, do B2C first. Not because B2B is the scary part to postpone, but because B2C is the fastest way to prove the whole pipeline works.
The catalogue migration, the storefront build, the checkout, payments and cutover are the same muscles whether the buyer is a person or a company. Prove them once on the higher-volume, lower-complexity side, and every lesson carries into B2B. By the time B2B is in scope, the team has a working deployment, a validated data pipeline and real production experience. B2B becomes an extension of something proven rather than a leap.
On the B2B side, the Scale plan includes a supported B2B storefront with company accounts, quotes, order approvals and quick ordering already wired. It runs on the same Vendure backend, so the catalogue, data pipeline and integrations from the B2C phase carry over. Teams that want to design their own B2B data model can build it around how their business actually works, rather than fitting a fixed schema built for someone else. This matters more than it sounds: Shopify's native B2B models company to location only and caps orders at 500 line items, draft orders included (Shopify B2B considerations). If your wholesale needs order approvals, quoting or large-basket orders, that ceiling is where you were heading anyway.
Where this does not fit
A guide that says every project is a good fit persuades nobody, so here are the cases where the honest answer is to stay on Shopify Plus.
You should not migrate if your store fits comfortably inside Plus today and you are moving on principle. Or if you have no development team and no appetite to hire or partner for one, because Vendure is code-first and will not run itself. Or if you are below roughly ten million US dollars in GMV with standard needs, where the economics rarely pay back. Or if you have a hard launch or peak-season deadline inside the next few months, because a migration under that clock gives you the worst of both platforms.
A replatform is one of the highest-risk projects a commerce team runs. The right reason to take it on is that a wall you have documented is costing you real money or real growth, not that a better architecture exists somewhere in the abstract. It always does.
Planning a Shopify Plus to Vendure migration? Contact iDeum.
Questions teams ask first
No, and most should not. Plus is the right platform for standard D2C and a lot of wholesale. Moving is worth it when your commerce logic is the thing you compete on and the platform holds it at arm's length.
Four to seven months for a mid-market store, driven mainly by how many integrations you re-point, not by catalogue size.
Yes, and it is often the right call. Keep Plus serving D2C while the complex side moves, or run the old store read-only for support after cutover.
Felipe Arango
Co-founder, iDeum
Felipe Arango is co-founder of iDeum, a commerce agency working between Medellín and Canberra. He has spent recent years moving mid-market and B2B stores off Shopify, from full Plus builds to headless Hydrogen storefronts, onto Vendure, with several migrations underway as he writes this. He is most interested in the point where a store's commerce logic becomes its product and the platform starts getting in the way. He splits his time between Colombia and Australia.
The author's views are his own and may not reflect the views of Vendure.
Planning the move?
Bring the apps and Functions your Plus store made you build. A partner who has run this migration, or Vendure's own engineers alongside your team, will sort them into retire, redesign and adopt before anyone writes code. That first sort tells you the shape and the cost of the whole project in an afternoon.
