If you've spent any time evaluating B2B platforms, you've probably hit the same fork in the road. Option A: pick a fast, modern storefront (Shopify, BigCommerce, the headless flavor of the day) and write integrations that copy ERP data into it on a schedule. Option B: pick a platform that talks directly to the ERP at request time. Sana Commerce is squarely in the second camp, and that single architectural decision changes nearly every conversation that follows.
The job of the storefront changes
In the copy-the-data model, the storefront owns the data. The ERP is a back-office source that keeps the storefront fed. The storefront has to maintain its own pricing engine, its own inventory state, its own customer-segment logic — usually as derivative copies of what the ERP already knows. When the ERP is the ultimate authority for any of those (and in B2B it almost always is — pricing tiers, contract pricing, available-to-promise, credit holds, ship-to rules), the storefront becomes a place where ERP truth gets reinterpreted.
In the ERP-first model, the storefront delegates. When a logged-in customer hits a product page, Sana asks the ERP: "this customer, this item, today — what's the price?" The ERP answers. Inventory works the same way. So do shipping rules, credit holds, payment terms, and customer-specific catalogs. There is no second copy that can drift.
Where this is unambiguously the right call
Three patterns make ERP-first the obvious answer:
- Customer-specific pricing that's already mature in the ERP. If your sales team has spent years building tier rules, contract overrides, and quantity-break tables in NAV / Business Central / S/4HANA, you don't want to rebuild that pricing engine inside a storefront — and you definitely don't want a copy of it that has to be re-validated every time the ERP rules change.
- Real-time available-to-promise. A customer placing a multi-line PO needs to see whether the order can actually ship together. ATP from a periodic ETL is just a worse version of ATP from the ERP itself.
- Credit holds and account state. If the AR side of the house puts a customer on hold at 3pm, the storefront should not be selling to them at 3:01.
The tradeoff you're actually making
The honest version of the ERP-first pitch is: you're trading some peak performance for correctness. A static storefront with cached prices is faster than one that round-trips to the ERP. Sana mitigates this with caching and connection pooling, but the upper bound on page-load time is set by how fast your ERP can answer.
For most B2B catalogs (1,000 to 100,000 SKUs, hundreds to low-thousands of authenticated buyers), this is not the bottleneck. But if you're pushing 10M SKUs on a public-facing catalog where 95% of traffic is unauthenticated browse, you'll feel the weight of the integration where you'd rather have a CDN-cached page. The fix isn't to abandon the model — it's to be deliberate about what's behind the login wall (and ERP-fed) versus what's in front (and aggressively cached).
Three things to get right early
1. The customer record IS the integration contract
Sana ties web users to ERP customer records. If the ERP's customer master is messy — duplicate accounts, unclear ship-to vs bill-to relationships, inconsistent payment-terms assignments — the storefront will surface that mess in places customers can see. We've spent more than one project's first month doing customer-master cleanup that nobody had budgeted for. Build that into the plan.
2. Add-ons live on Sana's own framework
If you've built BigCommerce or Shopify before, your instinct will be to hand-write integrations as standalone web services. Sana has its own add-on model, and projects that respect it stay maintainable through Sana's quarterly upgrades. Projects that side-step it accumulate upgrade tax and eventually have to be rewritten anyway.
3. Don't sneak in a second source of truth
The most expensive ERP-first projects are the ones that, halfway through, decided to put a "performance cache" of catalog data in a separate service "just for browse pages" — and then started writing reconciliation code, then a sync dashboard, then alerting for sync drift. Now you have two systems of record and the integration discipline you bought Sana for.
Sana 9.x on-prem versus Sana Commerce Cloud
If you're already running Sana 9.x, the question of whether to move to Sana Commerce Cloud is its own conversation. The short version: Cloud is a different product, not a hosted version of the same thing. The integration model is the same in spirit (ERP-first, real-time pricing, customer record as contract), but Cloud uses a SaaS architecture, a more modern frontend stack, and a different add-on model. If you've heavily customized Sana 9.x, "moving to Cloud" is closer to a re-implementation than an upgrade. Don't accept a vendor pitch that paints it otherwise without a real assessment.
What this means for buyers
If you're evaluating platforms today and your business genuinely runs on the ERP, ERP-first is not a marketing claim — it's the architectural decision that makes the rest of your B2B program achievable without an army of integration engineers. If your ERP is light or your business has outgrown it, the math is different. Either way, the worst outcome is picking an ERP-first platform and then trying to use it like a copy-the-data platform. The platform won't fight you, but the people maintaining it will burn out.
If you're sizing this decision on a real project, we'd rather talk to you than have you guess from a blog post — that's literally the work we do. Start a conversation here or read more about our Sana Commerce capabilities.