The mapping is simpler than most Magento teams expect, and the gaps are in different places than they expect. Moving Magento B2B to Shopify Plus, a Magento company account becomes a Shopify Company. Each ship-to address that needs its own pricing, terms or tax treatment becomes a company location. Each shared catalogue becomes a catalog with a price list attached. Company users become contacts on a location, with per-contact ordering permissions. Tier pricing becomes volume pricing on the price list; qty increments become quantity rules. That covers maybe 80% of a typical Adobe Commerce B2B setup. The other 20% — negotiable quotes, requisition lists, purchase-order approval chains, company credit limits — has no native home, and you need to decide what happens to each one before anybody touches data.
The object model, side by side
Magento gives you a company, a company admin, and a company structure that can nest teams and users several levels deep. Shopify gives you two levels: Company, then company locations, with contacts hanging off locations. That's it. No teams, no nesting, no manager-approves-junior relationship built in.
So a distributor with a head office and 40 branches has two sane shapes on Shopify. One Company with 40 locations gives you consolidated order history under a single account, one company profile, and per-branch pricing and terms. Forty separate Companies gives you clean separation but no roll-up view. We pick the first almost every time, because the finance team on the buyer's side wants one statement, and because a contact can be attached to more than one location if a regional manager buys for three branches.
Where this genuinely breaks: payment terms sit on the location, not the company. If your Magento setup used a single company credit limit shared across branches, Shopify has no equivalent. Net 30 on each of 40 locations is 40 independent terms, with no shared cap and no balance check at checkout. More on that below, because it's the thing that most often forces an integration.
Shared catalogues become catalogs, and you need far fewer than you have
Magento installations accumulate shared catalogues the way garages accumulate cables. We regularly open an Adobe Commerce admin and find several hundred custom catalogues where six pricing structures are actually in use, plus a handful of genuinely negotiated accounts.
Work out the real number before you build anything. Export every customer group and every catalogue price, then group by pricing rule, not by customer. A worked example from a job we scoped last year, numbers rounded: 620 active companies, 4,300 SKUs. On paper, 611 custom catalogues. In reality, six tiers defined as flat percentages off MRP (12%, 18%, 22%, 27%, 30%, 35%) and 38 accounts with per-SKU negotiated prices that didn't follow any tier.
Built as fixed prices, six tiers × 4,300 SKUs is 25,800 price rows to create, and 25,800 rows to maintain every time cost changes. Built as percentage adjustments off the published retail price, it's six catalogs with one rule each. The 38 negotiated accounts get their own catalogs with fixed prices, and those we import SKU by SKU because there's no rule to express. Total: 44 catalogs, not 611.
Percentage catalogs have a real cost, though. Every retail price change silently moves your wholesale price, so if merchandising runs an MRP correction on Friday afternoon, your distributor prices move with it. If your margins are thin enough that this matters, use fixed prices and accept the maintenance. We tend to run percentage catalogs for the broad tiers and fixed prices for anything where a rupee of drift would trigger a phone call.
One rule we don't bend: one catalog per company location. Shopify lets you attach several, and there's documented behaviour for which price wins, but debugging "why is this buyer seeing ₹412 instead of ₹389" at 11pm during a festive rush is not a problem worth inheriting. Merge the catalogs, keep the assignment single, sleep better.
Product visibility comes along with the price list
This is the part Magento people usually like. A Shopify catalog controls both price and availability — products you don't put in a catalog simply aren't purchasable for the locations using it. Magento's catalogue permissions, where you hide categories or price from certain customer groups, collapse into the same object. If your export-only SKUs shouldn't reach domestic dealers, they don't go in the domestic catalog.
Search and browsing are a separate question. A B2B buyer with a 4,300-SKU catalog types a part number, not a product name, and Shopify's stock search is mediocre at partial SKU matching. That's a storefront problem to solve with a proper filter and search layer — FilterPro is ours — rather than something the catalog structure can fix.
Tier pricing, case packs and minimum orders
Magento tier pricing maps cleanly onto volume pricing inside a price list: quantity breaks per variant, per catalog. If a SKU is ₹389 at 1–11 units, ₹362 at 12–47 and ₹341 at 48+, that's three rows on one entry.
Quantity rules are the better upgrade. Magento stores usually enforce case packs through qty increments configured per product, or through a custom module somebody wrote in 2019 that nobody wants to touch. Shopify handles minimum, maximum and increment per variant per catalog natively, so a case of 12 for dealers and a case of 48 for the modern-trade catalog is configuration, not code. Buyers who type 20 get corrected to 24 in the cart before they reach checkout.
Order-level minimums are the awkward gap. There's no native "₹25,000 minimum order value for this location" setting. It goes to a cart validation function or an app.
What Shopify B2B does not do
Say these out loud in the scoping call, not in week six.
- Negotiable quotes. No RFQ object. The usual pattern: give the location permission to submit orders as drafts, so the buyer builds a basket and sends it to your sales rep, who adjusts lines and prices on the draft order and sends back an invoice link. It covers most real quoting. It does not cover multi-round negotiation with version history and expiry dates.
- Requisition lists. Buyers reorder from order history, or you build saved lists. Reorder-from-history handles the weekly-replenishment case surprisingly well; it doesn't handle the buyer who maintains twelve named lists by project.
- Purchase-order approval rules. Magento's approval workflows — over ₹X needs the company admin's sign-off — have no equivalent. Contacts either can place orders or can't.
- Credit limits. Payment terms exist. Enforced balance caps do not. If your business genuinely stops shipping when an account crosses its limit, that check has to live in your ERP or in a checkout validation, fed by receivables data.
Each of those is buildable. Two of them, approvals and credit checks, are usually where custom app work lands on these projects, because both need to read something Shopify doesn't hold.
GST, invoices and the Indian B2B specifics
Shopify will calculate GST rates fine. It will not produce a tax invoice your buyer's accountant accepts. You need GSTIN captured against the company location (a metafield, validated on the form), place-of-supply logic that decides IGST versus CGST/SGST, HSN codes on the line items, and an invoice document with your GSTIN, invoice number series and signature block. That's an invoicing app or a push into Zoho Books or Tally. Plan it as a workstream, not a checkbox.
Payment terms mean the buyer isn't paying at checkout, so your gateway matters less than you'd think for the net-30 accounts. It matters for the ones who pay upfront: keep a Razorpay route for UPI and cards, add bank transfer as a manual method for RTGS/NEFT, and get somebody in accounts to confirm they can reconcile Shopify order numbers against bank references before launch. And test discounts on the B2B checkout specifically. Promotion behaviour differs from your DTC flow, and the assumption that your existing coupon stack carries over is one we've seen cost a launch week.
Moving the data
There's no importer for this. Companies, locations, contacts, catalogs and price lists all go in through the Admin GraphQL API — companyCreate, companyLocationCreate, catalog and price-list mutations, fixed prices added in batches. Products and orders can travel by the usual migration route; the B2B layer is scripted.
Order of operations that works: products and variants first, then catalogs with their price rules, then companies and locations, then contacts, then assign catalogs to locations, then historical orders. Build it as a re-runnable script keyed on your Magento company ID stored in a metafield, because you will run it three or four times. Our first pass on price data is wrong often enough that we now budget a full reconciliation cycle: export every price Shopify returns for a sample of 50 companies × 30 SKUs, diff it against the Magento values, and hand the mismatches to the client's sales team rather than to a developer. They spot the ones that were wrong in Magento too.
Buyer logins will break on cutover
Shopify's B2B features require the newer customer accounts, which means no passwords. Buyers get a six-digit code by email and log in with that. You cannot migrate Magento password hashes into this, and no amount of clever scripting changes it.
So the week before go-live, your sales team calls every active buyer. Not an email blast — calls, or at minimum a WhatsApp message from the rep they know. Tell them the login changes, tell them which email address to use, and make sure that address is a person who checks it rather than purchase@ forwarding into a shared tray nobody watches. The projects that go badly here go badly for this reason alone.
When Plus isn't the answer yet
Native B2B is a Plus feature, and Plus is a contract commitment. If your wholesale operation is 15 accounts on three price tiers with orders taken over the phone, you do not need it. A standard Shopify plan with a wholesale pricing app, or draft orders sent as invoice links, will run that business for a fraction of the cost, and we've told people so and lost the project.
Plus earns its keep when the buyer self-serves: hundreds of accounts, real per-account pricing, buyers placing their own reorders at 8am without a rep involved, terms and tax varying by location. Then the native objects save you a custom build that would cost more than the plan does. The comparison worth running is your current Adobe Commerce total — licence, hosting, the developer on retainer who keeps the B2B module patched — against Plus plus the integration work. Our notes on what Shopify builds actually cost in India cover the second half of that sum.
If you want the first half checked against your own data, send us a Magento company and shared-catalogue export and we'll tell you how many catalogs it really collapses to and which of the four gaps above applies to you. Ask for the audit, or read how we scope Plus builds from Bengaluru on our Shopify Plus page.