Multi-store and multi-country ecommerce on open source

Multi-store ecommerce on open source: why markets change the build

A retailer selling into several countries or running several brands on one estate faces the same core question: which data is shared across markets and which must be separate. Store views, sales channels, currencies, tax rules, price lists, localized catalogs and stock locations each have a different answer, and the answers decide the platform, the data model and the operating cost. A brand that wants one product master with local prices behaves differently from a group that wants independent catalogs, separate customer accounts and per-country fulfillment. Before comparing platforms, write down for each of these items whether it is global, per market or per brand, and who owns the change when a tax rate or price list moves.

On the platform side, the short answer is a fit question. Magento Open Source models markets mainly through store views, store groups and websites, and it has the largest extension ecosystem of the options here, which suits estates where many store views share one codebase and one admin. Saleor models markets through channels, with per-channel pricing, currencies and stock across multiple warehouses, which suits API-first builds where each market has its own price and fulfillment logic. Medusa is also API-first, with its own module model for carts, pricing, inventory and orders, and it suits teams that want to shape the market model in code. Magento 2.4.9 is covered by standard support until May 31, 2029 according to Adobe's lifecycle policy, so confirm the support window that applies to your planned version before you commit.

Choose the platform only after you have settled the shared versus separate decisions with finance, legal and merchandising. Ask any implementation partner to show how each market's tax, currency and price list are configured, where inventory is reserved, and how a change in one market is tested before it reaches the others. The Adobe Commerce lifecycle policy is the natural next read for Magento timelines, and the output of this exercise becomes the requirements list for the rest of the page.

What a multi-market estate must satisfy and what it means for the build

This table maps the requirements a retailer selling across several countries or brands must meet to the decisions they force in the platform build. Read each row as a question to answer before choosing between Magento Open Source, Saleor and Medusa, because the requirement usually determines how many store views, channels or instances the estate needs.

Requirement	Source of the requirement	What it means for the build
Market-level tax and invoicing	Tax and invoicing rules of each country where you sell, confirmed with your tax adviser	Each market needs its own tax configuration and invoice format. Confirm whether the platform calculates tax natively or through an add-on or external tax service, and test invoice numbering per entity.
Per-market currency and price lists	Local pricing policy and currency rules set by the business	Saleor models pricing per channel with its own currency. Magento handles currency and price scope per store view or website. Medusa uses price lists and regions. Confirm how each option handles exchange rate updates and rounding.
Localized catalogs and content	Language requirements, local legal wording and brand guidelines	Decide whether one catalog serves several markets with translated attributes or whether separate catalogs are needed. Translation workflows and content approvals add recurring effort that scales with each locale.
Shared versus separate inventory	Warehouse ownership, stock allocation rules and fulfillment contracts	Shared stock across markets needs one inventory source with per-channel visibility. Separate stock per country needs warehouse or location assignment per channel. Confirm how reservations and returns work across borders.
Customer accounts across markets	Business policy on shared logins and data handling rules for each country	Decide whether one customer account works across all stores or each brand keeps its own. This choice affects GDPR or other privacy processing records, consent storage and account deletion across the estate.
Accessibility for public-sector or EU-facing brands	Accessibility law applicable to your organization, such as WCAG-based obligations confirmed with counsel	For state or local government buyers in the US, the ADA Title II rule requires WCAG 2.1 Level AA, with compliance dates of April 26, 2027 for entities with 50,000 or more people and April 26, 2028 for smaller entities and special districts. Budget storefront theme testing for every market.

How Magento, Saleor and Medusa each model multiple stores

Magento organizes multiple storefronts as a hierarchy. A *website* contains one or more *store groups*, and each store group contains one or more *store views*. Store views are the level where storefront presentation, such as language and locale content, is usually separated, while website scope is where some customer, price and inventory settings can be isolated. The source code is covered by the OSL-3.0 license, and Adobe's lifecycle policy gives 2.4.9 standard support until May 31, 2029, which gives you a known planning horizon for upgrades.

Scope hierarchy: websites, store groups and store views give a natural split for brands, countries and languages within one installation.
Scoped settings: price scope, customer account sharing and inventory assignment are configured per scope, so each choice needs a test before launch.
Licensing and support: OSL-3.0 covers the source, and 2.4.9 has standard support until May 31, 2029, which sets the upgrade cycle for every market at once.
Custom work: country-specific tax rules, payment methods and brand-specific checkout flows often need extension configuration or code, and each extension must be rechecked on every upgrade.
Shared operations: one codebase means one upgrade path, but each added market adds catalog, content and regression test work.

Ask the partner to demonstrate a two-country test with separate prices, tax and stock, and confirm which settings are global and which are scoped in your target version.

Medusa's core framework is MIT licensed, and Enterprise Edition features such as role-based access control require a commercial agreement with MedusaJS, Inc. Its commerce domains are separate modules for carts, orders, product catalogs, pricing and inventory, built on Node.js, TypeScript and PostgreSQL. Multi-market setups are assembled from these modules, so regions, prices and stock locations are configured as module data and extended through custom modules or workflows. The Medusa deployment documentation describes how the runtime is split for production.

Module model: pricing, inventory, product and order modules can be combined or extended, which suits brands that need different catalog or stock logic.
Server and worker: one instance in server mode serves the API and admin dashboard, and one in worker mode runs background tasks, so both need deployment and monitoring.
Production infrastructure: PostgreSQL and Redis are required, and production replaces development modules with Redis-based caching, event bus, workflow engine and locking, plus S3 for file storage.
Migrations and secrets: migrations run through a predeploy script before each startup, and the server and worker both need database credentials plus COOKIE_SECRET and JWT_SECRET values.
Custom work: per-market admin roles may require the Enterprise Edition license, and market-specific workflows usually need custom modules, so confirm the license scope before design.

Ask which Enterprise Edition features your design depends on, and have the partner show migrations, worker health and the /health check in a two-market staging environment.

Which platform fits which multi-market setup

Multi-store and multi-country ecommerce is less about the platform's feature list than about how many catalogs, currencies, tax rules and storefronts you must run, and who will maintain them. The cards below pair each common market model with the platform that fits it and the risk to check before you commit.

Brands sharing one catalog

Several brands draw from a common product master but sell through separate storefronts with their own look, pricing and checkout. Magento Open Source models this as store views and websites under one installation, so shared catalog data and per-brand presentation sit side by side. The main risk is coupling: every brand's theme, extension and release schedule shares one codebase, so a change for one storefront can affect the others. Confirm how the team will test each store view before a release.

One brand across many countries

A single brand that localizes catalogs, prices and tax by country needs per-channel pricing, currencies and stock that can differ by market. Saleor supports per-channel pricing, currencies and products across multiple warehouses through its GraphQL API, which fits this model well. The risk is operational: each channel adds pricing rules, shipping zones and tax configuration that someone must own. Ask who maintains the country rules after launch, not only who builds them.

Headless storefront per market

Some groups run a separate front end for each market, each built by a local agency or team, against one commerce back end. This suits API-first platforms, where the storefront is a client of the commerce API rather than part of it. The risk is contract drift: each storefront may depend on a different API shape, and the back end then cannot change without breaking a market. Agree a versioned API contract and a regression test suite shared across markets.

Team with existing Magento skills

If your developers and agencies already run Magento in production, staying on Magento Open Source keeps the knowledge, extensions and hiring pool you have. Adobe lists three years of standard support for each 2.4.x release, so you can plan upgrades on a known cycle. The risk is the stack itself: the 2.4.9 requirements list PHP 8.5, OpenSearch 3, RabbitMQ 4.3 and Varnish-compatible caching, and Adobe supports only the listed combinations. Budget for those services and for the upgrade work that follows each release.

API-first team choosing Saleor

A team that wants commerce as an API, with a GraphQL surface and extension through webhooks and apps rather than in-process plugins, fits Saleor. Its multi-warehouse fulfillment, split payments and promotion engine cover common multi-market needs without custom core code. The risk is the self-hosted footprint: the API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers must all run and be patched, and the Docker Compose setup asks for at least 5 GB of memory. Confirm who runs the worker tier and the database backups.

Team choosing Medusa

A team building a Node.js and TypeScript stack, with modules for carts, orders, pricing and inventory, may prefer Medusa for multi-market stores and B2B use. Its core is MIT licensed, but some role-based access control features sit in an Enterprise Edition that needs a commercial agreement. The risk is the production topology: a self-hosted deployment needs PostgreSQL, Redis, and separate server and worker instances, with migrations running before each startup. Confirm which access control features your market structure requires before you choose.

Deployment patterns for several markets on self-hosted infrastructure

Every multi-market store has to decide how many running instances it operates and where each one lives. The choice shapes data location, release speed, and what the operations team must keep patched. The cards below set out the common patterns and the components each platform needs before those patterns can run.

One shared instance per market set

A single Magento, Saleor or Medusa installation serves every country, with store views, channels or regions carrying currency, tax, price lists and language. It is the lowest run cost because one database, one upgrade path and one security patch cycle cover all markets. Check whether your data residency rules allow all customer and order records to sit in one hosting region, and confirm that per-market configuration can be changed without a code release.

Separate instances per brand or region

Each brand or legal region gets its own stack, often with its own database and hosting account. This is the usual answer when a regulator, a retailer's data policy or an acquisition requires customer records to stay in a named jurisdiction. The cost is paid many times over: each instance needs its own upgrades, extension testing, backups, monitoring and on-call coverage, and shared catalog data must be synchronized between them.

Shared API with per-market storefronts

Saleor or Medusa runs as one commerce API, while separate storefronts for each market call it. Pricing, stock and promotions stay central, and the market-specific layer is limited to content, design and checkout presentation. Decide early which team owns the API release cycle, because a change to the shared channel model affects every storefront at once.

Magento components for self-managed installs

A self-managed Magento Open Source installation for several markets typically depends on OpenSearch for catalog search, Redis or Valkey for cache and sessions, RabbitMQ for asynchronous queues, and a full-page cache such as Varnish. Adobe lists the supported combinations in its system requirements, and only those combinations are supported. Confirm each component's version against the release you plan to run, and budget for every extra service to be patched and monitored in each instance.

Saleor and Medusa service footprints

Saleor needs its API, the Dashboard, PostgreSQL, Valkey or Redis and Celery workers, with configuration held in environment variables. Medusa needs PostgreSQL, Redis, and two Medusa processes: one in server mode for the API and admin dashboard, and one in worker mode for background tasks. Each extra market instance multiplies these services, so ask the partner to price the full footprint per instance and to show how migrations run before each deployment.

How a multi-market rollout moves from one market to many

The sequence starts by deciding which markets and brands share a platform, then fixes the data model before any store is built. A pilot market proves tax, pricing and fulfillment, and later markets follow in controlled waves until cutover is monitored end to end.

Scope markets, brands and legal entities
Your commercial, legal and tax leads list every country, brand, currency and legal entity that will sell, along with the languages and payment methods each market needs. DeployOpen's architects turn that list into a written scope that names which markets launch first and which are deferred. The step is done when every market has an owner, a launch order and a sign-off on what is in scope for the first release.
Decide the shared and separate data model
The team decides what is shared across markets and what is separate: product catalog, prices, stock locations, customer accounts, promotions and content. For Magento, this maps to store views, websites and store groups. For Saleor and Medusa, it maps to channels, currencies, warehouses and regional configuration. The output is a data model document signed by commerce, finance and legal owners, with one worked example per market showing how an order is priced, taxed and fulfilled.
Configure tax, price lists and currencies
Before any storefront work, the team configures tax rules, price lists, rounding and currency conversion for the pilot market, and confirms who maintains rates over time. Your tax advisor validates the rules against real invoices, and finance confirms how settlements reconcile with the payment provider. The step closes when test orders in the pilot currency produce the expected net, tax and gross amounts in the order records and the ledger export.
Build and test the pilot market
DeployOpen builds the first market on the chosen platform, including localized catalog content, checkout, payment routing, shipping rules and the fulfillment flow to the warehouse or ERP. Test cases cover returns, partial shipments, promotions that cross markets and address formats for each country. The pilot is complete when a controlled group of real orders has passed through checkout, fulfillment and refund without manual workarounds, and the defects are logged and closed.
Add markets in controlled waves
Remaining markets go live in waves grouped by shared tax logic, language or fulfillment network, so each wave reuses tested configuration rather than starting from scratch. Each wave repeats the market checklist: tax, prices, payments, shipping, content and legal notices. The team records the outcome of each wave in a launch log and confirms that the shared data model still holds. A wave closes only after its operational checks pass and its owner signs off.
Plan cutover and redirects
For brands or markets moving from an existing storefront, the team maps every indexed URL to its new equivalent, sets up redirects in a test environment and checks them against a crawl of the current site. Customer accounts, open orders and loyalty balances are migrated and reconciled with counts agreed in advance. The cutover plan names the rollback criteria and the owner for each go or no-go decision. The step is done when the redirect map and reconciliation reports are approved.
Monitor after cutover and hand over
After cutover, DeployOpen's operations team watches checkout errors, payment failures, tax calculation exceptions, stock sync delays and search-to-product mismatches for each market through agreed dashboards and alerts. Performance and error baselines are recorded so later waves can be compared against them. Operations runbooks and ownership of each market are handed to your team or to a retainer. The step is complete when the agreed monitoring is live, the runbooks are accepted, and open defects have named owners.

Evidence to keep for tax, pricing and accessibility reviews

This table lists the evidence a multi-store operator should keep for tax, pricing and accessibility reviews, and the component or record that produces each item. DeployOpen prepares this evidence for your assessors and reviewers, but it does not issue audit reports, attestations or certifications, which independent auditors and certification bodies provide.

Evidence	What it shows	Where it comes from
Channel and store view configuration exports	Which markets, currencies, languages and storefronts exist, and how each is scoped	Platform configuration export (Saleor channels, Medusa sales channels, Magento store views), kept under version control
Price list and tax configuration records	Which tax rules and price lists apply to each market and customer group on a given date	Tax and pricing configuration exports, plus the tax provider or rule set version in use
Currency and price change logs	Who changed exchange rates or prices, when, and what the previous value was	Admin audit log, database change history, and the approval record from your pricing workflow
Localized catalog and content approvals	Which translated product content and legal text was live in each market at a given time	CMS or catalog version history, translation management records and sign-off records
Inventory allocation settings	Whether stock is shared across markets or split by warehouse or channel, and the rule used	Warehouse and stock configuration exports, plus stock reconciliation reports from the ERP or WMS
Accessibility test results against WCAG 2.1 AA	Which storefront templates and checkout steps were tested, with defects logged and closed	Automated scan reports, manual test notes from an accessibility tester and remediation tickets
Upgrade and security patch records	Which platform release, extensions and patches ran in each store, and when they were applied	Change tickets, deployment logs, release notes for the version in use and the vendor's support lifecycle record

What drives cost and effort for a multi-market store

How does the cost of a multi-market ecommerce store change with more countries and brands?

Cost grows with the number of distinct configurations, not just the number of storefronts. Each additional market adds its own currency rules, tax treatment, price lists, localized catalog content, shipping methods and payment providers to configure and test. Brands that share a catalog but differ in pricing or assortment add less than brands that need separate product data and checkout flows. No fixed cost per market is supplied for this page, so ask any partner to price each market and each brand as separate line items, with the shared platform work shown once. Ask which items are reused across markets and which must be rebuilt for each one.

Which multi-store costs are one-time and which recur every year?

One-time work usually includes architecture decisions, store and channel setup, tax and price list configuration, catalog and content migration, integrations with ERP or payment providers, and acceptance testing per market. Recurring work includes hosting for each environment, database and search capacity, security patching, platform upgrades, extension maintenance, tax table and rate updates, and content changes. On Magento Open Source, Adobe's lifecycle policy gives each 2.4.x release three years of standard support, so plan recurring upgrade effort on that cycle. Ask the quote to split one-time and recurring costs in separate tables.

What must the buyer provide before a multi-country store can be configured?

The buyer typically provides the inputs that no platform can invent. These include:

Tax rules per country, including rates, reduced rates, digital services treatment and any marketplace obligations, confirmed by the tax or finance team
Price lists per market and currency, with rounding and promotion rules
Clean catalog data in one format, with translated product names, descriptions, attributes and images per locale
Stock feeds from the ERP or warehouse systems, with the warehouses that serve each market
Payment provider contracts and shipping carrier agreements for each country

Ask the quote to name who supplies each input, the date it is due, and what happens if it arrives late.

Can an internal team build and run a multi-store ecommerce platform without a partner?

A capable internal team can run a multi-store platform, but the question is capacity and skills, not only willingness. The work spans platform engineering, payments and checkout, tax configuration, catalog data, integrations, security testing and upgrades, usually in parallel. Teams often underestimate the upgrade and extension maintenance burden. A partner can carry fixed-scope build work or ongoing support as a retainer, while your staff keep ownership of business rules. Ask any partner to state in writing which tasks it performs, which remain with you, and how knowledge transfer is handled.

How long does a multi-market rollout take, and what sets the duration?

No duration is supplied for this page, so treat any figure you hear as unverified until it is tied to a written scope. The main drivers are the number of markets launched in each phase, how much catalog and price data is clean on day one, how many tax and payment setups are new, whether ERP stock integration already exists, and how much of the checkout is customized. Launching markets in waves, starting with the one that carries the most risk, usually shortens the critical path. Ask for a phased plan with a go-live gate per market and the dependencies each gate needs.

How do platform upgrades affect a multi-store setup on each open-source platform?

Every store, channel and language on one installation is upgraded together, so an upgrade touches all markets at once. On Magento Open Source, Adobe's release schedule ships a full patch for the 2.4.x LTS line annually in May, and security patches are released at least annually for all supported lines, so plan regression tests across every market. Saleor and Medusa separate channels and regions inside one codebase, which also means one upgrade path, while their deployment components such as workers and migrations must be updated in order. Ask partners to describe the upgrade test matrix per market and the rollback plan.

Which quote details should you require to compare multi-store proposals fairly?

Require the quote to state the scope in writing, including the list of markets, brands, channels, currencies, tax rule sets, payment providers and integrations in each phase. Ask for one-time and recurring costs as separate lines, the assumptions behind each estimate, what the buyer must supply and by when, and what is excluded, such as payment provider fees, hosting accounts or third-party extensions. DeployOpen works from fixed-scope written agreements and does not publish a price list, so ask for the same level of detail from every bidder. Compare proposals on the same market list, not on headline totals.

What risks raise cost in a multi-country ecommerce build?

Common cost risks include tax rules that change mid-project, catalog data that is incomplete or inconsistent across languages, ERP stock feeds that do not match warehouse reality, and payment providers that need separate contracts per country. Checkout customizations that differ by market also add testing time and ongoing maintenance. Ask partners how they handle scope changes, which assumptions they track, and how a change to tax or payment rules affects the schedule and budget. Clear change control in the written agreement is usually the most effective protection.

Questions to ask an implementation partner about multi-market scope

Start by asking how the partner models your markets before anyone installs anything. Ask whether each country or brand will be a separate store view, a separate Saleor channel, or a separate Medusa sales channel, and why. Ask them to show, on your own catalog, which settings are shared (product data, customer accounts, promotions) and which are set per market (currency, tax configuration, price list, language, checkout). A partner who answers with a diagram of your markets and the settings each one owns is working from a plan you can check. Ask for that model in writing, because it determines how every later question about tax, pricing and stock gets answered.

Ask how tax and price lists per market will be tested before go-live. Good answers name specific test cases: a basket in each currency, a VAT or sales tax calculation for each destination, a price list that differs by market, a promotion that must not leak across borders, and a refund that reverses the original tax. Ask who writes the expected results, who signs them off in your finance team, and whether the test set is kept for regression after each upgrade. Also ask how exchange rates are maintained, who owns that data and how often prices are recalculated. The partner should be able to say which tax rules come from your tax advisor and which are configured by the implementer, and that boundary belongs in the statement of work.

Ask how shared inventory is modeled across warehouses. In Saleor, stock sits per warehouse and channels decide which warehouses can fulfill an order, so ask which warehouses feed which channel and what happens when one market runs out. In Medusa, ask how stock locations are linked to sales channels. Ask how stock levels are synchronized from your ERP or warehouse system, how often, and what the store does during a sync failure. Localized catalogs need the same discipline: ask how translations and market-specific product content are imported, who maintains them, and how the partner will migrate existing catalogs and URLs per market without breaking search rankings. Confirm the upgrade process as well: ask whether a single release calendar covers all stores, and who applies security patches to each store, including the hosting layer and extensions, and how often.

Which questions do buyers search for before choosing a multi-store platform?

Does Magento Open Source support multiple stores on one installation?

Yes, Magento Open Source is built around a store structure of websites, store groups and store views, so one installation can serve several storefronts. The structure lets you separate languages, currencies and catalog presentation per view while sharing one codebase and admin. What you still have to confirm is how far that model fits your brands: separate customer accounts, separate checkouts and separate inventory sources usually need deliberate configuration and testing. Check the current Magento 2 repository and the 2.4.9 release notes before you design around specific features, since the supported stack changes by release.

Can Saleor handle multiple currencies per channel?

Yes, Saleor supports per-channel pricing, currencies, stock and products, and it models each market as a channel. Each channel can carry its own currency and price list, and products can be published to some channels and not others. Stock can be split across multiple warehouses and assigned to channels, so you decide whether markets share inventory or draw from separate pools. Confirm tax rules per channel, since tax calculation depends on your tax configuration and the regions you sell into, and test them against your own rate tables before launch. The Saleor repository documents the channel and warehouse model.

Does Medusa suit multi-country B2C selling?

Medusa can suit multi-country B2C because its commerce modules cover carts, orders, product catalogs, pricing and inventory, and it runs on Node.js, TypeScript and PostgreSQL. It is a good fit when your team wants to build a custom storefront and control the commerce logic in code. The trade-off is that you own more of the assembly, including regional configuration, tax logic and checkout behavior. Check whether any role-based access features you need fall under the Enterprise Edition, which requires a commercial agreement with MedusaJS, Inc. The Medusa repository lists the supported modules and license terms.

Can our own team run a multi-store open source platform internally?

It depends on the platform and on your operations skills, and the answer should come from a skills review rather than a guess. Each option has several moving parts: Magento needs PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and nginx at versions Adobe lists as supported, while Saleor needs the API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers. Medusa needs PostgreSQL, Redis and separate server and worker instances. Ask whether your team can handle patching, upgrades, backups, monitoring and on-call for that stack. Many organizations split this work between an internal owner and an implementation partner.

What hosting does each multi-store platform need?

Each platform needs its own supporting services, and you should size hosting from the vendor requirements for the version you choose. For Magento Open Source 2.4.9, Adobe lists PHP 8.5, MySQL 8.4 or MariaDB 12.3 or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3 and nginx 1.30 on Linux x86-64, and it supports only the listed combinations. Adobe documents Varnish as the full-page cache for self-managed installs. Saleor's Docker Compose setup asks for at least 5 GB of memory for Docker. Medusa requires PostgreSQL, Redis, S3 for file storage in production and two Medusa instances. Confirm the sizing for your catalog, order volume and peak traffic with the implementation partner.

Should separate brands share one store or run separate installations?

Shared installations reduce the number of systems to run, while separate installations isolate customer data, checkout and change risk between brands. The right choice depends on whether the brands share customers, payment accounts, catalog data and compliance obligations. Magento and Saleor can model several storefronts on one platform, so a shared installation is often technically possible. Confirm with legal and compliance teams how customer data and payment scope cross brands before you decide, because that boundary is often the deciding factor rather than the software.

How much does a multi-store open source build cost?

Cost depends on the number of markets, the depth of tax and price list rules, the integrations to ERP and payment systems, and the hosting you choose. Open source removes license fees for the core platforms, but you still pay for hosting, implementation, extensions or custom modules, security testing, and upgrades that recur each year. Ask for a quote that separates one-time build work from recurring support, and ask what each market adds in configuration and testing. DeployOpen does not publish a price list, and fixed-scope quotes follow from a written scope agreed before work starts.

How DeployOpen scopes and builds a multi-market store

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source commerce inside your own cloud accounts, data centers or air-gapped networks. For multi-market stores, we start with the market model (store views, channels, currencies, tax and price lists) and agree it in writing before any build begins.

How we scope

Map each country, brand and channel to a store view, channel or site, with its currency and tax rules documented.
Define which inventory, price lists and customer accounts are shared across markets and which stay separate.
Agree in writing which platform (Magento Open Source, Saleor or Medusa) and which integrations are in the fixed scope.

How we build

Configure market-specific catalogs, localized content, currencies and tax settings in a staging environment first.
Test checkout, pricing and stock allocation for each market against written acceptance cases before cutover.
Harden the self-hosted stack, including payment page scripts and content security policies, as agreed in the scope.

How we hand over

Deliver architecture diagrams, configuration records and runbooks for each market, brand and channel.
Document how to add a new country, currency or store view without breaking existing price lists.
Train your team on daily operations, order and stock troubleshooting, and the upgrade path for the chosen release line.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, platform upgrades and continuous security testing are available as retainers.
Confirm with us the patch cadence, backup schedule and on-call coverage that a retainer would include for your markets.