If a B2B store is no longer growing as planned, there can be many reasons for this, and one of them is the platform. Problems with SaaS store systems don’t arise solely from the load. They also arise when business logic extends beyond the standard scope: in ERP integration, product data synchronization, roles and approvals, update cycles, and API limits. You can check whether this applies to your store.
This guide explains how to identify scaling limitations, how to measure them, and what options are available – with or without switching platforms. It does not compare providers but rather provides criteria.
In B2B, scalability doesn’t just mean processing more orders per minute. It’s about whether a platform can support growing business logic: customer-specific price lists, multi-level approvals, complex product portfolio management, and integration with ERP, CRM, and PIM systems.
In this guide, we distinguish between three levels. This is a model chosen for the purposes of this article; it is not a universally applicable definition.
Standard SaaS platforms provide a preconfigured infrastructure. This reduces the initial setup effort. Business processes not covered by the standard must be supplemented with apps, plugins, or middleware, and these solutions require maintenance, updates, and coordination – even if the platform or ERP system changes.
In B2B, this limitation can become apparent sooner than in B2C because digital channels there are often expected to handle the same level of complexity as internal operations: customized terms, budget approvals, purchase on account, and framework agreements.
A SaaS store is like an off-the-rack suit. It fits right from the start, and minor adjustments can be made quickly. As the business grows, there comes a point when the fit can no longer be adjusted through modifications. Specifically, this means: Apps, plugins, and middleware extend the standard functionality, but they usually do not alter the platform’s underlying structure.
Three areas warrant a closer look: ERP integration, product data synchronization, and authorization structures.
In B2B, prices, inventory levels, customer master data, credit limits, and delivery times typically come from the ERP system. If this data does not flow reliably in both directions, errors can occur. And the more systems involved, the more difficult it is to trace where an error originated in quotes, orders, or invoices.
The interface itself is often not the problem. The greater challenge lies in mapping the ERP’s B2B logic: net and gross prices, tax zones, discount scales, and payment terms. Whatever the e-commerce platform’s standard features don’t cover ends up in a middleware layer, and the more complex the logic, the more resource-intensive and error-prone this layer can become during ongoing operations.
Anyone who manages a large number of items with variants, technical data sheets, and multilingual descriptions needs a central data source – usually a PIM system. The connection to the online store is then crucial.
If data is transferred via CSV imports or third-party connectors, this works as long as data changes in a predictable manner; however, with daily updates from ERP and PIM, synchronization conflicts can arise that must be resolved manually or with additional automation. Our overview of Pimcore commerce architectures compares which architectures are suitable for connecting Pimcore and the online store, based on four models and eleven criteria.
B2B purchasing often involves multiple people. Companies use multi-level approvals, budget limits per role, separate buyer accounts, and cost centers; if standard features only partially support these structures, custom workarounds are created that must be reevaluated after platform updates.
In addition to integration, limitations become apparent during day-to-day operations: with updates, performance, and API limits.
SaaS providers control the timing and scope of their updates. This reduces the company’s own maintenance effort but limits the ability to plan or postpone changes on a case-by-case basis. If an update changes the checkout logic or renders a plugin incompatible, the operator has little room to maneuver, and an ERP connector that no longer synchronizes correctly after an update can disrupt the order flow.
Whether complex price calculations or large catalogs lead to response-time bottlenecks depends on the platform architecture, the implementation of price calculation, caching and indexing, the data model, and the available resources. Customer-specific, quantity-based, or time-based prices calculated in real time on the product page, as well as catalogs with many attributes and language versions, are typical test cases. Therefore, measure response times under typical and high load conditions (see Step 3).
Headless architectures separate the front end from the back end and promise flexibility; however, the front end relies on the platform’s APIs, and their limits can constrain performance.
Providers document these limits differently, for example, by API type and pricing plan. According to BigCommerce’s developer documentation (accessed in October 2026), the REST APIs allow 150 to 450 requests per 30 seconds, depending on the pricing plan; a plan with no limits is reserved for some enterprise customers, and even there, the provider can restrict excessive usage. Therefore, before deciding on a headless setup, check which API your frontend uses and what limits apply to it. We are familiar with these limits from our own integrations of Pimcore with BigCommerce via the Data Director; they become manageable when synchronization runs are designed with them in mind from the start. A limit does not necessarily indicate a store’s speed, and a high limit does not guarantee good performance.
If your business model relies on standardized pricing, a manageable product range, and low ERP complexity, current SaaS platforms often provide solid coverage of the required functionality while keeping operations lean. Typical examples include newcomers to B2B commerce, manufacturers selling directly to end customers, and companies in the evaluation phase. No hosting, no patching, no server management.
Three patterns indicate that the existing solution is reaching its limits.
These four steps lead from the current state analysis to the target architecture.
Identify all systems that communicate with the online store. These include ERP, PIM, CRM, inventory management, payment, shipping, and marketplaces. For each interface, document the data direction (one-way or two-way), the frequency, the format, and the error handling – since error handling in particular often determines how stable a connection is in day-to-day operations.
List all business processes that run – or should run – through the online store: price calculation, approvals, returns, invoicing, and the customer portal. Evaluate each process individually. Does it run natively within the platform, via a plugin, or through an external solution, and who maintains that solution?
You can’t rely on gut feelings to determine whether a threshold has been reached. We recommend monitoring certain metrics over several months and comparing them to business performance, as individual outliers—such as those caused by a promotion or an update – can skew the picture. Target values depend on your online store; there are no universal thresholds.
Added to this is the actual total cost of ownership (TCO) of the current solution, the economic benchmark: platform license, plugin costs, middleware, external development, hosting, maintenance, and internal effort for manual processes. A single value proves nothing. The picture becomes meaningful when multiple indicators point in the same direction.
Our assessment: A platform limitation becomes a problem requiring action when technical or functional constraints can be repeatedly demonstrated and their consequences become relevant to costs, operational stability, or further development. This is a rule of thumb, not a standard.
Based on the first three steps, determine which architecture supports your requirements: Which platform? Which operating model? Which integrations? Which responsibilities? Compare the expected total cost of the target architecture with that of the current solution.
You can find a structural comparison of monolithic, headless, and composable commerce in terms of effort, operational complexity, and five-year costs on our Composable Commerce page.
In many cases, the platform can be expanded through targeted enhancements: a PIM as a central data source, stable middleware for ERP integration, or a custom front end. For Pimcore projects, we use our Data Director for this purpose that integrates ERP systems with Pimcore and transfers data in both directions. This can reduce project risk, shorten the implementation timeline, and preserve existing processes. However, it shifts complexity to additional components that you must operate.
If the extension is not sufficient, a migration may be necessary. It begins with a requirements analysis, not with the choice of platform: Which ERP logic, which pricing structures, and which approval processes need to be mapped? Without this clarification, the effort estimate remains uncertain, and after go-live, there is a risk of surprises that can only be resolved through rework. A thorough analysis takes time but can save you from having to make corrections later on.
Feature lists alone say little about a platform’s suitability. What matters is not whether a feature exists, but how it functions within your system landscape: How does the pricing logic behave under load? How stable is ERP synchronization during daily batch runs?
An architecture change involves redistributing functions and responsibilities among the online store, front end, integrations, and other systems. Those who serve multiple markets or front ends, or who want to modernize their architecture in stages, may want to consider switching to composable commerce; our article “Composable Commerce for SMEs in the DACH Region: When It’s Worth It – and When It Isn’t” explains when this is a good idea.
Scalability limits aren’t solely a platform issue. They depend on integrations, the operating model, data management, and growth planning all at once. SaaS platforms are a valid starting point, but they can become a bottleneck if the business logic exceeds the platform’s limits.
The first step is simple: Map out your system landscape, track a few key metrics, and only then decide whether expansion, migration, or an architectural change is appropriate.
If you’d like to review the results together: Tell us where your store stands and what it needs to achieve. We’ll get back to you with the right questions and a proposal for how to move forward. A few lines are all it takes.
We’ll get back to you with the right questions and a proposal for how to proceed.