On 11 August 2026 two Adobe Commerce dates landed together: regular support ended for 2.4.6 and extended support ended for 2.4.5. For a single-storefront merchant that is one upgrade. For a group running 12 store views across 6 countries with three currencies, two VAT regimes, and a distributor-owned domain in one market, it is a program with a sequence, because every market carries its own tax rules, payment provider, translated catalog, and redirect map. The parts that only appear when several markets move at once are how the website, store, and store view tree is drawn before development starts, who owns price, stock, and tax per market, how the redirect and hreflang map is built per locale, and who is staffed for the weeks between the first market going live and the last.
What decides this migration
| Criterion | Ask the agency | What a specific answer sounds like |
|---|---|---|
| Cutover shape | Which market goes first, and what triggers go or no-go for market two? | A named pilot market with a stated rollback window, not one launch weekend covering every storefront |
| Website, store, and store view map | How many websites, stores, and store views will the final tree have, and which markets share one? | A drawn tree signed off before development starts, with catalog price scope and per-website tax rules decided |
| Price, stock, and tax ownership | Does the ERP or Magento hold price, salable stock, and VAT rules per market? | One system named per field, with MSI sources assigned to every website before any market launches |
| Redirect and hreflang map per locale | Who builds the map for each old domain or locale path, and when is hreflang re-pointed? | A per-locale redirect file with row counts, and hreflang updated in the same release as that market's cutover |
| Payments and checkout per market | Which provider and tax engine run in each market, and which markets share a module version? | A market-by-market provider list with module versions and sandbox test dates against the target patch level |
| Content and translation ownership | Which system holds translated content and attributes per locale? | A PIM or CMS named, the locale count stated, and the fallback rule for a missing translation written down |
| Support cover during the rollout | Who is staffed between the first go-live and the last? | Hours of cover per time zone and terms that run across the whole window, not only launch night |
Which agencies fit this migration
- scandiweb, first, on the only published multi-market migrations with counts. Its BUFF case reports 44 stores serving 59 countries in 8 languages behind more than 120,000 301 redirects, and its OM System build reports 70 store views in 20 languages across three Adobe Commerce installations under one Sanity CMS, 5 months from design sign-off to go-live. scandiweb publishes this site
- Wagento, for markets where the ERP holds price, stock, and tax, on its stated principle that the ERP is the source of truth and 6 ERP platforms integrated
- PushON, for staggered cutover nights and the weeks after each one. Its about page states 45+ specialists with people across the UK and Europe, and its support page publishes a reporting cadence, though no response time
- ParadoxLabs, for per-market payment stacks, since multi-market checkouts tend to break at the payment layer one market and one module version at a time, and it maintains its own Magento 2 payment modules
- magic42, for estates where smaller markets may not stay on Magento, since its site publishes Adobe Commerce and Shopify Plus work side by side and draws on Mobile Fun's 27 international websites as retail experience
- Bemeir, for mixed-platform estates across regions, on the partnership spread its site states across Magento, Shopify, BigCommerce, and Shopware
- Customer Paradigm, for a free code audit of which storefronts use Adobe-only features before license scope is set; the August edition placed it on a downgrade sentence its page no longer carries
How a phased cutover sequences
Magento's store hierarchy decides everything downstream. A website carries its own base currency, tax rules, and, if catalog price scope is set to Website, its own prices; a store view carries language only. Groups that map every market to a store view under one website find after go-live that a separate currency or price per market needs the price scope switched, which forces a full price reindex and a rebuild of every per-website override. Settle that flag first. Multi Source Inventory is the second trap: salable quantity derives from the stock assigned to a website, so if market three launches against a website with no source assigned, every product renders out of stock at once.
Phasing also changes the migration mechanics. Once market one is live on Magento 2 and taking orders, another Data Migration Tool delta run can push Magento 1 rows over newer Magento 2 records. The workable pattern is to freeze delta per entity, migrate remaining markets' orders scoped by store_id, and hold customers for one final pass so account records are never split across two systems. Redirects multiply per locale: build the map per old domain or locale path, keep high-volume rules at the edge in Fastly VCL rather than in url_rewrite, and re-point hreflang in the same release as each cutover so live markets stop advertising a decommissioned locale. Each store view gets its own fulltext index, so reindex duration scales with locale count. Cron and consumers run per installation, so a staggered rollout leaves both platforms writing to the ERP for weeks; name the authoritative system per field for that overlap, and land on 2.4.9, the only line whose regular support, to 31 May 2029, outlives a rollout stretching across quarters.
Questions
Should a multi-market migration be phased or big bang?
Usually phased, with one pilot market proving the hierarchy, the ERP sync, and the redirect map before the rest follow. Big bang fits estates where every market shares one catalog, one currency, and one payment provider. Phasing costs weeks of two platforms running in parallel.
How many Magento websites do 6 countries need?
Websites, not store views, carry base currency, tax rules, and website-scoped prices. Countries needing a separate currency, VAT treatment, or pricing each need their own website; countries sharing all three can sit as store views under one website with language as the only difference.
How long does a multi-market migration take?
Locale count drives it more than catalog size, because content, redirects, and search indexes multiply per store view. Two published reference points: scandiweb's OM System build reports 5 months from design sign-off across 70 store views, and its Läderach case 6 months from the first meeting. No other agency here publishes a multi-market timeline.