How do multiple simultaneous B2B catalogs (one per customer segment) migrate to Shopify's 3-catalog limit on non-Plus plans, if we exceed that number?

Read the limit properly, because two limits are at work

Most planning documents record one number and miss the one that actually decides the migration.

The sentence that matters is this one, verbatim: "On the Basic, Grow, and Advanced plans, you can assign up to 3 active catalogs across all your B2B markets. The Shopify Plus plan offers an unlimited number of catalogs and direct assignment to companies and locations."

So the non-Plus restriction is not simply "three." It is that a catalog attaches to a B2B market, not to an individual company location. A per-segment catalog model is not merely capped on non-Plus; it is attached to the wrong axis. You can have three catalogs and still be unable to express "this one account gets this price list," because the mechanism that does that is the Plus-only direct assignment.

That reframes the migration decision completely. The question stops being "can we fit 12 segments into 3 slots" and becomes "is our pricing actually keyed to geography-style groupings, or to individual accounts."

How many price structures do you actually have?

Count price structures, not catalogs. On most legacy B2B platforms, a catalog is cheap to create and gets created for reasons that are not pricing: a label for a sales territory, a snapshot from a merger, a copy someone made to test something in 2019, a per-account clone that differs from its sibling by one SKU.

Run this before you model anything:

1. Export every price list with its effective per-SKU price. Not the discount label, the resulting number.
2. Hash each list. Lists that produce identical prices across the SKU set are one structure, however they are named.
3. Sort the remainder by distance from list price. A large share will collapse into a small number of percentage bands.
4. Isolate the genuine exceptions. Contract prices on named SKUs for named accounts. These are real, and they are usually a short list.
5. Count what is left. That number, not the catalog count, is the input to the plan decision.

In our experience this exercise ends with a smaller number than the client expected, and the gap is the value of running it before choosing a plan.

The four ways past the limit, ranked by what they cost

1. Collapse by pricing rule. Three catalogs is enough for three percentage bands, and a band holds every account whose economics match, regardless of segment label. Quantity breaks live inside a catalog and do not consume a catalog slot, so 30 tiers that are really volume breaks on one list occupy one slot. Cost: the data work above. This is where we start.

2. Use fixed prices inside a band for the genuine exceptions. Fixed prices override the catalog's overall percentage adjustment per product or per variant, so a contract price on 40 SKUs does not need its own catalog. It needs 40 fixed-price rows inside an existing one.

3. Buy a pricing-rules app. Our decision record on the 3-catalog cap scores this BUY when the catalog count is the only blocker, and names SparkLayer at $49 to $299 per month, Wholesale Pricing Discount B2B at $24.99 to $64.99 per month, and BSS B2B Wholesale Pricing at $29 to $99 per month (verified September 2026). Verify current pricing at the listing before you budget; app pricing in this category moves.

4. Upgrade to Plus. Unlimited catalogs and direct company-location assignment. Plus runs $2,500 USD per month on a one-year term or $2,300 on a three-year term. Our record's position, which we hold: upgrade when a second Plus-only feature also justifies it, not for catalog count alone. Paying roughly $2,300 a month to avoid a data-modelling exercise is a poor trade, and the exercise still has to happen eventually because 25 catalogs per company location is a ceiling on Plus too.

When NOT to collapse segments

• When two lists differ for a contractual reason you can point at. A negotiated agreement is not a naming inconsistency. Keep it and express it as fixed prices.
• When the lists differ by currency. Catalog currency is a property of the price list, and merging across currencies loses information you will have to reconstruct.
• When the lists differ by product availability, not price. That is a visibility problem, not a pricing one, and it has its own answer. See the product-visibility page below.
• When you have not exported the effective prices yet. Every collapse decision made from catalog names rather than from prices is a guess.