International expansion on Adobe Commerce has two valid architectural answers: run multiple store views inside a single Adobe Commerce installation, or run separate Adobe Commerce instances per country or region. Both are documented, both are supported, both have shipped successful international rollouts. They have very different operational shapes, and the right choice depends almost entirely on how much your business logic varies by country and how independent your country teams need to be.
The merchants who get this right at the architecture stage have an international setup that scales for years. The merchants who pick wrong fight the architecture every time a country team needs something the architecture cannot deliver. Bemeir’s Adobe Commerce team has shipped both patterns for clients expanding into Europe, Asia, and Latin America, and the trade-offs are clearer than the platform documentation suggests.
What Adobe Commerce gives you for multi-store
Adobe Commerce’s multi-store architecture has three nesting levels: Website, Store, and Store View. Each level controls different aspects of the storefront.
Website. Controls customer accounts (customers can be shared across websites or unique per website), default currency, payment methods, shipping methods, and tax configuration. Multiple websites in one Adobe Commerce installation can have different customer bases and different payment infrastructure.
Store. Controls the catalog. Each store has its own root category, which defines which products are visible in that store. Multiple stores under one website share customer accounts but can sell different catalogs.
Store View. Controls the storefront presentation: language, currency display, locale-specific content, and storefront theme. Multiple store views under one store share the catalog but present it differently per language or region.
This three-level structure is more flexible than most merchants use. A single Adobe Commerce installation can host a US website with English and Spanish store views, a Canadian website with English and French store views, and a UK website with English and Welsh store views, all sharing infrastructure and product master data.
The case for store views
Running multiple international storefronts as store views (or stores, or websites) inside a single Adobe Commerce installation has real advantages.
Shared product master data. Add a new product once, mark it as visible in the regions where it should appear, and the new SKU shows up across all relevant storefronts. No data syncing between systems, no duplicate SKU management, no risk of price or attribute drift between countries.
Shared customer accounts (optional). Customer accounts can be configured as global, regional, or per-storefront. For brands where customers move across regions (digital products, international travel-oriented brands), global accounts are a real convenience.
Shared infrastructure cost. One Adobe Commerce installation, one hosting bill, one set of Varnish and Redis instances, one database to back up. The infrastructure cost of three store views vs. one is marginal.
Unified admin experience. Merchandising, order management, and customer service teams use a single Adobe Commerce admin panel to manage all regions. Reporting and analytics roll up across all storefronts.
Faster time to launch a new region. Adding a new store view is a configuration change, not a new infrastructure deployment. A new language can launch in weeks; a new country with a new payment method can launch in months.
For brands where the international expansion is mostly language and currency differences with relatively similar product offerings and similar business logic, store views are the better architecture. This describes a meaningful share of the international rollouts our team scopes.
The case for separate instances
Running each country or region as its own Adobe Commerce installation has different advantages, ones that matter when the business logic genuinely differs by region.
Independent release cycles. Each country can deploy on its own schedule. A US release does not have to wait for a UK QA cycle. Each country’s engineering team can iterate independently.
Independent customizations. Each country can install country-specific extensions, country-specific payment methods, country-specific tax integrations, and country-specific compliance modules without affecting other regions.
Independent scaling. Each country’s infrastructure can be scaled to its own traffic patterns. Black Friday in the US does not require provisioning extra capacity in the UK installation. The Adobe Commerce Cloud documentation on infrastructure scaling covers the scaling patterns.
Country-specific data sovereignty. GDPR requirements, China’s data localization laws, Russia’s data localization requirements (for merchants still operating there), and similar regulations sometimes mandate that customer data stay within a specific geography. Separate instances make this easier than a single multi-region installation.
Independent reporting and accounting. Each country has its own database, its own order numbers, its own reporting. For multinationals with separate country P&Ls and separate finance teams, this is often closer to how the business actually operates.
For multinationals where each country runs as a meaningful independent business with significant operational autonomy, separate instances are usually the better architecture. The infrastructure cost is higher, but the autonomy is worth it.
How they actually compare in operation
The headline trade-offs are clear, but the day-to-day operational reality is where the architecture either supports the team or fights them.
| Dimension | Store views (single installation) | Separate instances |
|---|---|---|
| Initial implementation cost | Lower | 2-4x higher |
| New region launch effort | Weeks | Months |
| Infrastructure cost (annual) | 1x baseline | 1.6-2.5x baseline |
| Engineering complexity | Single codebase | Multiple codebases to keep aligned |
| Deployment frequency per region | Coupled | Independent |
| Risk of cross-region bugs | Higher | Lower |
| Cross-region reporting | Easy | Requires data warehouse aggregation |
| Per-country compliance | Possible but constrained | Easy |
| Catalog management for global brand | Shared, simple | Synced, complex |
| Payment method flexibility | Constrained by single installation | Per-instance flexible |
There is no universally right answer. The merchants who pick store views and later regret it are usually merchants whose country businesses diverged faster than the architecture could accommodate. The merchants who pick separate instances and later regret it are usually merchants whose country teams ended up wanting to share catalog and customer data more than the architecture allowed.
The decision framework that works
The questions to ask in order:
How similar is the product catalog across regions? If 80%+ of the SKUs are shared across regions with regional pricing and translation differences, store views are usually right. If each region sells substantially different products, separate instances become more appealing.
How much do regional business rules diverge? Different shipping carriers, different payment gateways, different tax handling, different return policies, different compliance requirements: each divergence pushes toward separate instances. Adobe Commerce’s multi-store can handle some of this, but the configuration complexity grows fast.
How autonomous are the country teams? If each country has its own engineering team that wants to ship on its own schedule, separate instances respect that autonomy. If a single central team manages all regions, store views are easier to operate.
How important is global reporting? Cross-region inventory, customer, and order reporting is much easier in a single installation. A data warehouse can solve this for separate instances but adds engineering cost.
What does the next five years look like? Store views and separate instances are not easy to migrate between. Picking the wrong one means a re-architecture down the road, which is much more expensive than picking right at the start.
The hybrid pattern we recommend most often
The pattern that fits the largest share of mid-market international rollouts: store views for regions that are operationally similar (e.g., all of EMEA on a single Adobe Commerce installation as separate store views), separate instances for regions that are operationally distinct (e.g., a separate Adobe Commerce installation for North America, another for APAC).
This hybrid balances the operational simplicity of store views within a region with the autonomy of separate instances across regions. The customer master, catalog, and infrastructure can be regional, with cross-region data warehouse aggregation handling global reporting.
Bemeir’s Magento team has implemented this hybrid pattern for clients expanding from US-only to North America + Europe + APAC over a two-year horizon. The architecture starts with the single instance, adds a European instance when European complexity justifies it, and adds an APAC instance when APAC is large enough to need its own setup. Each step is a deliberate decision, not an accident.
What this costs to operate
A useful sanity check on the architecture decision: model the annual cost of each option over five years.
For store views (single installation supporting US, UK, DE, FR):
- Infrastructure: roughly $48K-$120K annually depending on traffic
- Engineering team: 2-4 developers shared across regions
- Annual extension and platform licensing: $25K-$75K
- Cross-region QA and release management: 0.5-1 FTE
For separate instances (US, UK, DE, FR as four installations):
- Infrastructure: roughly $120K-$280K annually
- Engineering team: 4-8 developers (could be regional or central)
- Annual extension and platform licensing: $80K-$200K (license per instance)
- Cross-region coordination: 1-2 FTE
The cost ratio is roughly 1.6x to 2.5x for separate instances. Over five years, that compounds significantly. The autonomy and flexibility need to justify the cost.
When to revisit the decision
Even a good architecture decision should be revisited every two to three years as the business evolves. Triggers that should prompt a re-evaluation:
The country teams start asking for fundamentally different capabilities. The compliance landscape changes in a region you operate in. A country business grows to a meaningful share of revenue and needs operational autonomy it doesn’t have. The infrastructure cost of the current architecture starts compounding faster than revenue growth.
A re-architecture from one pattern to the other is a six-to-twelve-month project, not a quarter project. It is worth doing when the business case is clear, but it is also worth avoiding by picking right at the start.
For most merchants we work with, the architecture decision is one of the highest-leverage conversations we have in the discovery phase. The implementation effort flows downstream from that decision, and the operational shape of the international business for the next five years is set by it. Worth taking seriously and grounding in real business evidence, not in a default assumption that one pattern is automatically modern or another is automatically legacy. Both are valid; the question is which one fits your business.
