Building a unified commerce platform for multiple brands requires a shared commerce foundation with isolated brand identities. Use a single Magento/Adobe Commerce instance with separate websites/stores per brand, configure shared product catalogs with brand-specific attributes, manage unified reporting across brands, and implement careful role-based access controls. This approach reduces operational overhead by 30-40% versus managing separate platforms.
The Multi-Brand Problem Nobody Talks About
You’ve got three successful brands acquired over the past five years. Each runs on its own e-commerce platform – separate infrastructure, separate teams, separate databases, separate headaches. Now you’re managing three sets of server costs, three content pipelines, three customer data islands, and no unified view of your business.
The dream: one modern platform that powers all brands while keeping each one unique. The reality for most companies: a tangled mess of custom integrations and manual data syncs that take months to implement and break every quarter.
At Bemeir, we’ve consolidated multi-brand operations for mid-market retailers managing 2-6 distinct brands. The teams that succeed treat this as an architecture problem first, a commerce platform problem second. Unified commerce doesn’t mean every brand looks the same. It means every brand shares infrastructure where it matters and diverges only where it has to.
Architecture Decision: Shared Platform vs. Multiple Instances
This is your first fork in the road, and it determines everything downstream.
Option 1: Single Magento Instance with Multiple Websites/Stores
One Magento codebase, multiple “websites” (each with a unique domain), multiple “stores” (each with its own catalog/pricing/shipping rules).
Pros:
– Single admin interface
– Unified reporting and dashboards
– Shared extensions and customizations
– Lower server costs (one database, one app server cluster)
– Easier to synchronize catalog updates across brands
– Consolidated customer data (if brands allow cross-shopping)
Cons:
– If one brand’s code breaks, all brands are affected
– Requires careful role-based access control to prevent cross-brand leakage
– Harder to upgrade if brands use incompatible extensions
– Single database means performance impact if one brand gets a traffic spike
Option 2: Separate Magento Instances (Federated Architecture)
Each brand runs its own Magento instance with its own database, servers, and codebase.
Pros:
– Complete isolation. One brand’s performance issues don’t affect others
– Easy to upgrade brands independently
– Teams work autonomously without stepping on each other
– Can customize heavily per brand without affecting others
Cons:
– Triple (or more) infrastructure costs
– Manual synchronization of shared data (catalogs, customer data, pricing)
– Fragmented reporting requires ETL pipelines
– Onboarding new team members requires learning N different systems
Our Recommendation (And Why):
Start with Option 1 (single instance) unless brands need complete autonomy or have contradictory technical requirements. Single instance consolidates operational overhead dramatically. Federated only makes sense if you have massive traffic variance, completely different product catalogs, or political reasons to separate teams.
If you must go federated, you’re essentially rebuilding half the work we describe here in custom API integrations. Expect 3x the engineering effort.
Setting Up Multi-Website Architecture in Magento
Assume you’re consolidating three brands: Premium (luxury goods), Everyday (mainstream), and Value (budget).
Step 1: Create Websites in Admin
Create three:
– Website Code: premium_brand, Name: “Premium Collection”
– Website Code: everyday_brand, Name: “Everyday Brand”
– Website Code: value_brand, Name: “Value Collection”
Step 2: Create Stores Under Each Website
Under each website, create at least one store. Most multi-brand setups have 1-2 stores per website (one for the main domain, one for a region-specific variant if needed).
Example for Premium Brand:
– Website: “Premium Collection”
– Store Code: premium_default
– Store Name: “Premium Collection – Default”
– Store View (Code: premium_en, Name: “English”)
Step 3: Configure Root Categories Per Store
Each store needs its own product category tree. This is where brands diverge most visibly.
Create root categories:
– Premium Brand Root Category (assign to premium_default store)
– Everyday Brand Root Category (assign to everyday_default store)
– Value Brand Root Category (assign to value_default store)
Step 4: Map Domains to Websites
In Admin or env.php, configure domain routing:
Or configure via .htaccess:
Shared vs. Isolated Catalogs: The Strategy That Matters
Here’s the critical decision: do brands share products or maintain separate catalogs?
Scenario A: Completely Separate Catalogs (Most Common)
Each brand has its own product catalog with no overlap. Premium sells luxury handbags, Everyday sells basics, Value sells closeouts.
- Create separate attribute sets per brand (e.g., “Premium Handbag”, “Everyday Apparel”, “Value Closeout”)
- Each store’s root category contains only that brand’s products
- Enable visibility rules so products don’t appear in unintended stores
Example:
Scenario B: Shared Catalog with Brand Differentiation (Sophisticated)
You sell the same product line under different brands with different pricing, positioning, or bundling. A t-shirt is premium at Premium Collection, standard at Everyday, discounted at Value.
This requires shared products but brand-specific customization:
Theme Customization Per Brand Without Duplicating Code
Running three themes is a maintenance nightmare. Run one theme with brand-specific CSS and content overrides.
Option 1: Single Theme with Brand-Specific CSS Variables
Then inject the brand data attribute:
Option 2: Store-Specific Template Overrides
For more complex customization, override templates per store:
Load conditionally:
Unified Catalog Management Across Brands
Managing 50K SKUs across three brands without drowning in spreadsheets requires systematic processes.
Shared Attributes (Apply to All Brands):
– SKU
– Name
– Description
– Price (base, overridden per store)
– Images (brand-agnostic)
– Inventory/Stock
– Meta Title/Description
– URL Key
Brand-Specific Attributes (Per Attribute Set):
For Premium:
– Designer Name
– Collection Season
– Materials & Craftsmanship
– Care Instructions (Premium-specific)
For Everyday:
– Size Range
– Care Instructions (Simplified)
– Color Variants
For Value:
– Closeout Reason
– Original Brand
– Discount from MSRP
Import Process (Using CSV + Custom Importer):
Unified Reporting and Analytics
One of the biggest wins of consolidating onto a single platform: unified reporting.
Dashboard Metrics Across All Brands:
Display:
– Total Revenue (all brands) vs. by brand
– Order count (all brands) vs. by brand
– Average Order Value by brand
– Traffic by brand
– Conversion rate by brand
– Top products (across all brands)
– Customer acquisition cost by brand
Custom SQL Report (Unified Data):
Or use Magento’s GraphQL for programmatic reporting:
Role-Based Access Control: Preventing Cross-Brand Leakage
Multi-brand requires tight permission management. A Premium marketer should not see Value pricing. Ever.
Create Brand-Specific Admin Roles:
Stores > Permissions > Admin Roles
-
Role: “Premium Brand Manager”
– Resource Access: Only Premium website/store
– Catalog: Full access
– Orders: View only
– Extensions: No -
Role: “Everyday Brand Manager”
– Resource Access: Only Everyday website/store
– Catalog: Full access
– Orders: Full access
– Extensions: No -
Role: “Multi-Brand Admin” (Limited)
– Resource Access: All websites
– Catalog: View only (cross-brand perspective)
– Orders: View only
– Reports: Full access
– Extensions: No
Enforce Catalog Visibility by Role:
Common Pitfalls and Solutions
Pitfall #1: Category Conflicts
You want a “Men’s Clothing” category in both Premium and Everyday, but they need different layouts and pricing.
Solution: Create separate categories with identical names under each brand’s root category. Use custom SQL to prevent cross-brand visibility.
Pitfall #2: Inventory Overselling Across Brands
You run out of SKU-12345 at Premium but still have it in the Value warehouse. Magento’s MSI can’t distinguish “inventory reserved for Premium vs. Value” if you’re on the same product.
Solution: Either maintain separate product SKUs per brand, or use custom stock attributes that map inventory to brand/warehouse pairs.
Pitfall #3: Pricing Logic Conflicts
Premium uses tiered pricing, Everyday uses volume discounts, Value uses flash sales. All on the same product.
Solution: Don’t. Use separate products or brand-specific price rules that exclude other brands.
Pitfall #4: SEO Cannibalization
Same product appears on all three brand sites. Google doesn’t know which is the “real” one.
Solution: Implement hreflang tags and canonical URLs. Set one brand as the canonical source, others use hreflang pointing back.
Implementation Roadmap
Phase 1: Foundation (Weeks 1-4)
– Assess current platforms (data, customizations, traffic patterns)
– Create Magento multi-website structure
– Set up brand-specific sites and root categories
– Configure domain routing
Phase 2: Catalog Migration (Weeks 5-10)
– Audit and clean all three catalogs
– Create unified attribute sets with brand-specific customization
– Migrate products, inventory, pricing
– Implement visibility rules and brand filters
Phase 3: Storefront & Checkout (Weeks 11-16)
– Build single theme with brand overrides
– Implement role-based access control
– Configure shipping, tax, payment rules per brand
– Test checkout flows for each brand
Phase 4: Reporting & Operations (Weeks 17-20)
– Build unified dashboards and reporting
– Set up automated data syncs and backups
– Train team on multi-brand admin
– Soft launch with internal testing
Phase 5: Launch & Stabilization (Weeks 21-24)
– Migrate traffic from old platforms (staggered by brand)
– Monitor performance and data integrity
– Handle any cross-brand issues that emerge
– Optimize based on real user behavior
