What actually carries over when a B2B catalogue moves platform

A B2B migration is three separate jobs that get quoted as one. Content moves, because a product record is a product record everywhere. Structure gets rebuilt, because no two platforms model a company the same way. And a third category, the one nobody separates out, should stay where it is, because the ERP already owns it and copying it into the storefront is how you end up with a website that quotes a different price than the invoice.

The table below is the whole page in one place. Everything after it is the reasoning for the rows that surprise people.

Four things: prices, credit, order history and invoices. All four have the same failure mode. The storefront copy and the ERP original diverge, nothing errors, and you find out from a customer.

Prices are the clearest case. In Acumatica, a Sales Price Worksheet releases negotiated prices into the ARSalesPrice table with effective and expiration dates, and that is what your inside sales team quotes from. Acumatica’s own community, answering a direct question about syncing that effective price to Shopify, says "Only Default Price is supported". If you migrate your price list into the storefront as static data instead of resolving it from the ERP, then every worksheet released afterwards widens the gap between what the website says and what the invoice says. Nothing in either system will tell you.

Credit is the same shape with a worse consequence. A credit limitA credit limit is the amount a customer may owe at any one time. Buying on account, often on thirty-day terms, is standard in B2B and the limit is enforced by the ERP. copied into a storefront is a number from the day you copied it. The ERP’s number moves with every unpaid invoice. A buyer who is over their limit today will still check out on the storefront’s stale copy.

Order history and invoices are less dangerous and more embarrassing. Your ERP holds every order the customer ever placed, including the phoned-in ones and the EDI ones. A storefront that shows only its own orders is telling the customer a partial truth in a place they went looking for a complete one. Read it through instead. That costs an API call and it is right forever.

Because they are the only part of the migration your customers experience directly, and they land on the same morning.

Take the shape of the problem on Shopify, which documents its limits clearly enough to be worth quoting. A company can hold a maximum of 10,000 locations and 10,000 customers. A company location can hold a maximum of 50 customers and a maximum of 25 catalogues. Those numbers are generous for most distributors and lethal for a few: if you sell to a buying group where one account has hundreds of named purchasers at one ship-to, the 50-customer location limit is a structural problem you need to design around before the data migration, not during it.

Then the passwords. Shopify states that "because passwords are encrypted outside of Shopify, you can’t migrate customer passwords from another online store using a CSV", and separately that "B2B customers can’t use legacy customer accounts". So every buyer is invited to a new login system and asked to set a new password on the same day the site looks different. Two of them will do it, three will phone your order desk, and the rest will go back to emailing purchase orders, which is exactly the behaviour the project was funded to stop.

The fix is boring and it works: invite in waves, start with the buyers your reps talk to weekly, keep the old store reachable for a fortnight, and give the order desk a script. Budget for it as a change-management task with a named owner, because it is not a technical task and no developer will pick it up.

Less than a migration agency will tell you, and more than you would guess in one specific place.

Start with the honest arithmetic. If your product pages require a login, they were never indexed, so there is no ranking to lose and no redirect to write for them. A distributor with 40,000 gated SKUs and 60 public pages has a 60-page SEO migration, not a 40,000-page one. The generic replatforming advice about preserving URL structure is written for retail catalogues that are entirely public, and applying it to a gated B2B catalogue produces a large invoice for work with no traffic behind it.

The place it does matter is the thin public layer: your brand pages, your category landing pages, your line card, your resource content, and any product pages you deliberately left open so buyers can find you before they have an account. That set is small enough to inventory by hand in an afternoon, which is exactly what you should do. Pull your top pages by impressions from Search Console, not by your own sense of what matters, and write a redirect for every one of them.

One thing genuinely worth protecting: if you have public product pages today and the new platform gates them by default, you have not made an SEO mistake, you have removed a channel. Decide that deliberately rather than discovering it after launch when the traffic goes.

Six numbers. Each is an afternoon’s work from systems you already have, and together they change a migration quote more than any conversation about platforms.

A vendor who quotes without asking for these is quoting a template. A vendor who asks for them and then quotes a range is being honest with you.