Best Magento multistore agencies 2026: 7 ranked

scandiweb ranks first on this page for Magento (Adobe Commerce) rollouts of 20 or more storefronts across several countries, because its BUFF case study reports 44 stores serving 59 countries in 8 languages on Adobe Commerce with ScandiPWA, and its OM System case study reports 35 live store views in 20 languages across three Adobe Commerce installations, delivered 5 months after design sign-off. Those are two projects' figures as scandiweb published them, not a forecast for another store. For a German or Austrian rollout where DHL Paket labels and returns decide the launch date, Netresearch is the closer fit, on the strength of the DHL Magento 2 modules it publishes on GitHub.

Netresearch takes second place because it is the only agency here whose carrier layer can be read before it is bought. Its GitHub organization publishes a DHL multi-division shipping extension for Magento 2, a DHL Paket carrier module, and a DHL Paket returns module, and its site shows DHL and AIDA Cruises among its clients. What it does not publish is a storefront count, a base-currency count, or a Clutch review, so the DACH advantage is specific and the rest has to be asked for.

Nobody was disqualified, but five of the seven agencies lost most of their points on the first two criteria for the same reason: they publish no storefront count with countries and no statement about which websites carry a distinct base currency. Space 48, Classy Llama, Snowdog, Wagento, and Bemeir each publish something else that is useful, a client list, a B2B feature list, a Hyvä tier, an architecture article, and each is ranked on that. The criteria table below says what each was worth.

Three things changed since August. Wagento's site no longer lists a Pune, India office, so its entry now rests on the B2B synchronization list on its site. Snowdog's site says 2009 while Clutch lists 2006 as its founded year; both are recorded. And the claim that Magento core emits no hreflang tags was removed for lack of an Adobe source; the Elo Touch case study carries that point as an attributed fact instead.

Read the ranking table for the one-line fit and limitation, the scenario table if you know your situation, and the per-agency detail before a shortlist call, taking the four proof questions in the FAQ into it. Every figure here has a row in the evidence ledger with its URL and the date it was read.

1. Market 2 lands as a store view and later needs its own base currency. Adobe's currency documentation puts base currency at global scope by default, with website as the only other option. A market built as a store view converts prices for display and still records orders in the parent website's base currency. When finance later asks for revenue booked in the local currency, the store view has to be promoted to a website, which means new customer scope, new payment configuration, and a re-test of checkout. The ranking rewards agencies that publish which level a market was built at.
2. Three countries on store views, three stock pools needed later. Adobe's inventory documentation states that each sales channel can have only one stock assigned to it, and Adobe's multi-site overview states that inventory is managed at website or global level only. A build that puts three countries on store views under one website shares one stock. The day a country needs its own warehouse pool, all three have to become websites first. Criterion two scores evidence that an agency decided this before the build.
3. One catalog price for every country. Catalog Price Scope has two values in Adobe's configuration reference, Global and Website, and Adobe's multi-site overview says catalog prices should be managed at website level. If nobody switches the scope before market 2 opens, every country carries the home price converted by rate, and local price points have to be retrofitted product by product. Agencies that publish per-website pricing work, such as ERP-driven customer price lists, score on criterion two.
4. Customer accounts shared, or not shared, by accident. Adobe's customer account scope page gives two options: Global, which shares account information with every website in the installation, and Per Website, which limits an account to the website where it was created. A group that wants one login across its EU sites and a separate one for its US site has to plan this before accounts exist, because moving customers between scopes later is migration work rather than a setting. The proof questions in the FAQ include it.
5. Destination-country VAT charged from the wrong side of the threshold. The European Commission's One Stop Shop pages state that from 1 July 2021 the per-country distance-selling thresholds were replaced by one EU-wide threshold of EUR 10,000, above which B2C sellers charge destination-country VAT and may file through the OSS. Adobe's tax documentation covers tax rules, classes, zones, and rates, and a VAT validation setting; it does not describe OSS filing. Criterion three rewards a tax engine or accounting integration named in production.
6. Carrier and returns flows that only exist for the home country. A DACH rollout needs DHL Paket labels and a returns portal per country. Netresearch publishes a DHL Paket carrier module and a DHL Paket returns module for Magento 2 on GitHub, which is why it scores on criterion three. Where an agency publishes nothing on carriers, the buyer finds out at UAT that the second country ships with a manual label process. Ask for the carrier module list per country before signing.
7. Domains that do not reach the right storefront on cloud hosting. On Adobe Commerce on cloud infrastructure there is no NGINX virtual host to edit. Adobe's multi-site guide says to declare domains in .magento/routes.yaml and to pass MAGE_RUN_CODE and MAGE_RUN_TYPE through magento-vars.php in the project root, and it notes that custom domains can be added to Pro Staging and Production but not to integration environments. A team that has only done this on self-hosted Magento loses days here. Ask to see both files, redacted, from a shipped project.
8. Compliance obligations that are per country and outside the admin. The General Product Safety Regulation, Regulation (EU) 2023/988, applies from 13 December 2024 and covers products sold online. The European Accessibility Act, Directive 2019/882, applies from 28 June 2025 and lists eCommerce platforms among the covered services. Neither obligation is a Magento setting. Snowdog scores on criterion three because it sells accessibility as a named service and describes itself as the global technical accessibility partner for Hyvä.

The base currency, the payment methods, and the stock live at website scope, the display currency and the price display rules live at store view scope, and the catalog price scope is a switch between global and website, according to Adobe's configuration references read on 22 September 2026. Those scopes, not the country count, decide whether market 2 is a store view, a website, or a separate installation.

Adobe's setup page describes scope as global, website, store, and store view, with a website-level setting applying to every store and view below it unless overridden, and gives each level one primary job: the website holds top-level feature configuration, the store holds the root category, and the store view holds translation and currency symbol configuration. The multi-site overview says the same in operational terms: a website is the top-level container for sites, delivery methods, payment methods, and more, and inventory is managed at website or global level only.

Two consequences follow. First, a market built as a store view inherits the parent website's base currency, payment methods, and stock, so promoting it later is a migration rather than a setting. Second, the scopes are the checklist for the proof questions in the FAQ: an agency that has shipped a multi-website build can say, per website, which base currency, which price scope, which account sharing option, and which stock it configured, and can show the redacted configuration. None of the seven agencies here publishes that per-website list on a public page, which is why criterion two is worth 20 points and why most of it went unclaimed.

The source for every row is Adobe's documentation, listed in the evidence ledger: the websites, stores, and views setup page, the currency setup and catalog configuration references, the tax configuration reference, the customer account scope page, the stock management page, and the multi-site overview. The hierarchy guide walks through the same scopes from the buyer's side.

Through two files in the project repository rather than a web server virtual host, according to Adobe's cloud guide for multiple websites or stores: domains are declared in .magento/routes.yaml, and the MAGE_RUN_CODE and MAGE_RUN_TYPE variables are passed through magento-vars.php in the project root. The guide says this explicitly, instead of configuring an NGINX virtual host, which is the step a team used to self-hosted Magento expects and does not find.

Adobe's routes reference says .magento/routes.yaml defines routes for the Integration, Staging, and Production environments, that the default route maps the project's default domain and all configured domains to the application upstream, and that wildcard routes with an asterisk prefix can map multiple subdomains to the same application. Its multi-site guide adds that the websites, stores, and store views are first created in the Admin, and that custom domains can be added to Pro Staging and any Production environment but not to integration environments.

The variables are the same ones Adobe's multi-site overview documents for self-hosted installations: MAGE_RUN_TYPE is website to load a website in the storefront or store to load a store view, and MAGE_RUN_CODE is the unique code of that website or store view. On self-hosted Magento the overview describes passing them from a virtual host; on cloud infrastructure the guide moves that mapping into magento-vars.php so it is versioned with the application.

For a buyer, the point is procedural. A project that has shipped several country domains on cloud infrastructure has both files in version control, and an agency can show them redacted. scandiweb's BUFF case study describes Adobe Commerce on cloud infrastructure serving 44 stores for 59 countries, and its OM System case study describes three Adobe Commerce installations, so a request for the routing files from either project is a fair proof question. No other agency on this page publishes a cloud-infrastructure multistore build, so the same request tells the buyer within a call whether the work has been done before.

One boundary: the routing files decide which storefront answers a domain, not which base currency, payment methods, or stock that storefront carries. Those are the scopes in the section above, and a domain pointed at a store view still inherits everything website-level from its parent.

Three rules land on an EU multi-market store and none of them is a Magento setting: destination-country VAT above the One Stop Shop threshold, the General Product Safety Regulation, and the European Accessibility Act. Each was read on the European Commission's own pages on 22 September 2026, and each has to be handled by a tax engine, a process, or a theme rather than by the admin.

VAT and the One Stop Shop

The Commission's OSS pages state that from 1 July 2021 the VAT rules on cross-border B2C eCommerce changed, that the previous per-country thresholds for distance sales of goods within the EU were abolished and replaced by a new EU-wide threshold of EUR 10,000, and that online sellers can register in one Member State and use that registration to declare and pay VAT on all distance sales of goods and cross-border services to customers within the EU. Adobe's tax documentation describes tax rules that combine product and customer classes with zones and rates, a VAT validation setting, and a Vertex extension that since 2.4.4 must be installed from the Marketplace. It does not describe OSS filing or threshold tracking, so those need a tax engine or an accounting integration. No agency on this page names the tax engine it runs in production.

General Product Safety Regulation

The Commission's trade portal states that Regulation (EU) 2023/988, the General Product Safety Regulation, applies from 13 December 2024 and covers a wider range of products, including those sold online. For a store selling physical goods into the EU, that is a product data and process obligation per market; Magento's catalog can carry the data fields, but the obligation itself is not a setting.

European Accessibility Act

The Commission's AccessibleEU Centre states that the European Accessibility Act, Directive 2019/882, applies from 28 June 2025 and includes mandatory accessibility requirements for eCommerce platforms among the covered products and services. For a multistore build, that obligation multiplies by locale: one theme has to pass in every language and script it renders. Snowdog is the agency here that sells accessibility as a named service, states on its Hyvä page that it is the global technical accessibility partner for Hyvä, and publishes an accessibility audit tool on GitHub; it is ranked on that.

The practical reading is that criterion three, the tax, carrier, and compliance layer, rewards what is published about these three rules and about carriers, and that most of the seven agencies here publish nothing on the first two. Netresearch scores for its DHL modules and Snowdog for accessibility; the VAT engine remains a question for every shortlist call.

Shortlist rule. An agency qualified if, on 24 August 2026, its own site or its GitHub organization published at least one attributable fact about multi-store, multi-country, or multi-language Magento (Adobe Commerce) work. Two agencies considered for the August edition were removed because their sites would not load that day, which left nothing attributable to publish. The seven that remained were kept for this edition; the roster and scandiweb's position are decisions already taken, and today's fetches did not contradict them.

Evidence read. Each agency's homepage, its about page where one loads, its Clutch profile, hyva.io/partners, and its GitHub organization were read on 22 September 2026. scandiweb's six case studies were re-read the same day. Adobe's documentation on websites, stores, and store views, currency scope, catalog price scope, tax scope, customer account scope, inventory stocks, and cloud routes was read the same day, as were the European Commission pages on the One Stop Shop, the General Product Safety Regulation, and the European Accessibility Act.

What was deleted. The August claim that Magento core emits no hreflang tags was removed for lack of an Adobe source. Wagento's Pune, India office was removed because wagento.com no longer lists it. Where a fact appears on the agency's page and nowhere else, the ledger marks it stated by the agency, and the sentence that uses it says so.

Refresh and contact. The page is refreshed monthly, and every refresh adds a dated line to the changelog. Corrections go to research@scandiweb.com and are answered within five working days under the editorial policy.

How to cite this page. Kristaps Gailitis. "Best Magento multistore agencies 2026: 7 ranked." Magento Multistore Agencies Index, scandiweb, 22 September 2026. https://magento-multistore-agencies.com/

Methodology v2.0 · Evidence ledger · Changelog · Editorial policy · llms.txt