Operating a portfolio of consumer brands on a single Adobe Commerce instance is one of the most operationally consequential platform decisions a multi-brand retailer can make. The two models the platform supports look superficially similar but produce very different operational shapes. The shared-instance model centralizes catalog and operations across brands. The separated-store model isolates each brand on its own instance with shared corporate services.
The right choice depends on how the business actually operates across the brands. Centralized merchandising and shared inventory point toward the shared-instance model. Brand-autonomous merchandising and brand-specific operational requirements point toward separation. Either model can be operated well, and either can be operated badly. The cost of getting the model wrong is high enough that the decision deserves real diligence.
Bemeir’s Adobe Commerce engineering practice has built multi-brand platforms in both models. The framework below is what we use when scoping a multi-brand build, and the considerations are the ones that actually determine the operational outcome.
What each model looks like in practice
The shared-instance model runs a single Adobe Commerce application with multiple websites configured. Each website represents a brand. The catalog is shared at the platform level, with per-website catalog assignments controlling which products are available where. Pricing, content, themes, and configuration vary per website. Customer accounts can be shared across websites or scoped per website.
The separated-store model runs a separate Adobe Commerce instance per brand. Each instance has its own catalog, its own database, its own deployment, and its own operational rhythm. Shared services like corporate ERP integration, common analytics, and shared identity may layer on top, but the storefronts are independent.
The shared-instance model is operationally efficient when brands share most of their operational pattern. The separated-store model is operationally cleaner when brands need to make independent decisions about their own platform.
Where the shared-instance model wins
Three patterns favor the shared-instance model.
Shared inventory is the strongest. If the brands draw from a common warehouse and fulfillment network, running them on a single instance simplifies inventory management. Adobe Commerce’s Multi-Source Inventory module handles the per-website allocation cleanly. Stock changes propagate naturally without cross-instance sync.
Centralized merchandising is the second. If a small merchandising team manages products across all brands, working in a single admin reduces the operational burden of switching between systems. The same product can be onboarded once and assigned to multiple brand websites.
Shared customer base is the third. If customers are likely to buy across brands, running on a shared instance lets the loyalty program, the order history, and the customer support tooling work seamlessly. Customer-segment-based promotions can target the customer regardless of which brand storefront they are browsing.
These three patterns tend to cluster in vertically integrated multi-brand retailers, especially in fashion, beauty, and outdoor recreation where the brands share supply chains and customer overlap is meaningful.
Where the separated-store model wins
Four patterns favor the separated-store model.
Independent operational cadence is the strongest. If each brand runs its own release schedule, its own promotion calendar, and its own technology roadmap, separation reduces the coordination cost of getting things done. Deployments can ship without coordinating across brand teams. Features can launch without requiring a platform-wide change.
Distinct technology requirements is the second. If one brand needs a headless storefront for performance and another brand needs full Hyvä for operational simplicity, separation lets each brand make the right choice. The shared-instance model forces a single theme architecture across all brands.
Independent financial reporting is the third. Multi-brand businesses that report separately to investors or that operate under different corporate structures often need clean separation between the brands’ financial flows. Separated instances make this cleaner than the shared model, where the database, the order tables, and the financial integrations are all combined.
Acquisition-driven portfolios are the fourth. Companies that have acquired the brands rather than built them often inherit different platforms, different operational patterns, and different team structures. Consolidating onto a shared instance is a large project that may not produce enough operational benefit to justify the disruption.
The pattern is that separation respects the autonomy of each brand at the cost of operational duplication, while shared respects operational efficiency at the cost of brand autonomy.
The hybrid model
The third option, which we increasingly recommend for portfolios above three or four brands, is a hybrid. Group brands by operational similarity. Brands that share inventory, merchandising, and customer base run on a shared instance. Brands that are operationally distinct run on their own instances. Common services like ERP, identity, and analytics are unified across the portfolio.
The hybrid model produces clusters of two to four brands per shared instance, with separation at the cluster boundary. This pattern lets each cluster optimize for the operational efficiency of its members while preserving cluster-level autonomy. It is the most common pattern we see at multi-brand retailers above 200 million in combined GMV.
The trade-off is operational complexity at the platform level. Running two or three Adobe Commerce instances plus the common services on top is more expensive than running one of either pure model. The complexity is justified when the savings within each shared cluster exceed the duplication cost of having multiple instances.
Technical considerations for shared-instance
The shared-instance model has specific Adobe Commerce mechanics that determine how cleanly it operates.
The Website, Store, and Store View hierarchy is the configuration surface. Websites are the top level and carry their own customer accounts, root categories, and base currency. Stores within a website share the catalog. Store views share the store and add language and locale variations.
For a multi-brand build, each brand is typically a Website. The Website level provides enough isolation that brand-specific configuration is clean. The shared customer base option lives at the Website level, so businesses can choose to share or separate per their needs.
Per-website catalog management uses the Magento concept of category assignments. The same product can be assigned to multiple websites with different prices, descriptions, and availability. Shared Catalogs from the B2B module add further granularity for businesses with multi-tier customer pricing.
Theme management lets each website have its own theme. This is non-trivial operationally because a shared codebase means theme changes have to be tested across all themes for any platform update. The Adobe Commerce theme inheritance documentation covers the mechanics.
The table below summarizes the configuration surface for a typical four-brand shared instance.
| Configuration level | Per-brand options | Notes |
|---|---|---|
| Website | Currency, root category, customer scope | Top-level isolation |
| Store | Catalog visibility, shared catalog assignment | Used for B2B segmentation |
| Store view | Language, locale, theme | Used for translations |
| Theme | Brand-specific design | Each website has own theme |
| Inventory | Per-website allocation via MSI | Stock can be shared or split |
| Promotions | Per-website rules | Some rules can apply across websites |
Technical considerations for separated-stores
The separated-store model has different mechanics. Each instance is independent, which means each instance has its own version, its own patch level, its own deployment pipeline, and its own monitoring stack.
The shared services that tie the instances together typically include identity, where customers can log into multiple brand storefronts with a single account managed in a separate identity provider. The Auth0 multi-tenant patterns and the Okta customer identity guide are common reference points.
ERP integration is the second shared service. The brands typically feed into a single corporate ERP for financial reporting, inventory, and operational consolidation. The integration architecture needs to handle the data from multiple Adobe Commerce instances and normalize it for the ERP.
Customer service tooling is the third. A multi-brand retailer typically wants a single support team that can serve any brand. The tooling needs to span the instances, either by integrating each instance with the support platform or by centralizing data in a customer data platform that the support tooling reads from.
The operational cost of running separated stores scales roughly linearly with the number of brands, while the operational cost of a shared instance scales sub-linearly because much of the operational burden is shared. This is why portfolios above five or six brands rarely run pure separation; the cost compounds.
What we recommend at scoping time
The conversation we run at the start of a multi-brand build covers six questions.
How much inventory overlap exists across the brands? High overlap favors shared. Low overlap favors separation.
How much merchandising team overlap exists? Centralized merchandising favors shared. Brand-autonomous merchandising favors separation.
How important is the cross-brand customer journey? If customers buying across brands is strategic, shared is the cleaner model. If brands are deliberately distinct, separation lets each brand have its own customer relationship.
How distinct are the brands’ technology requirements? Aligned requirements favor shared. Divergent requirements favor separation or hybrid.
What is the engineering team’s capacity to operate multiple instances? Lean teams favor shared. Larger teams can run separation.
What is the portfolio’s growth trajectory? Portfolios likely to add more brands favor a model that scales. Hybrid scales better than pure shared above five brands and better than pure separation at any scale.
The output of this conversation is a model recommendation that the executive team can evaluate. Bemeir’s pattern is to produce both an operational analysis and a five-year total cost of ownership comparison so the decision is anchored in business reality rather than in engineering preference.
If you are evaluating multi-brand platforms across Shopify Plus, Shopware, or BigCommerce in addition to Adobe Commerce, the same framework applies. The platform-specific mechanics differ. The operational questions are the same. The right multi-brand model is the one that respects how the portfolio actually wants to operate, not the one the platform vendor wants you to choose.
