Best Magento cloud migration agencies 2026: 7 ranked

scandiweb ranks first on this page for a move onto Adobe Commerce on cloud infrastructure, when the store runs more than a handful of country sites and organic traffic has to survive the URL change. Its BUFF case study records a migration from Magento Open Source to Adobe Commerce on cloud infrastructure that now serves 44 stores in 59 countries and eight languages, with organic traffic held after more than 120K 301 redirects. That is one project's result, not a forecast for another store. For the opposite route, leaving Adobe Commerce Cloud for managed hosting, Sonassi and MGT Commerce are the closer fit, because each publishes a free managed migration onto Magento hosting it runs, and scandiweb publishes no exit case.

Sonassi ranks second and MGT Commerce third because they are the only agencies here whose own sites describe moving a Magento store onto infrastructure they operate themselves. Sonassi states on its site that it stopped building Magento stores in 2015 to concentrate on hosting. MGT Commerce states 5,000+ stores hosted on managed AWS and prints its monthly plan prices on its homepage. Neither publishes a before-and-after case for a named store that left Adobe's cloud, and that gap is what kept both below first place.

Nobody was disqualified. Points were lost for absence. No agency here publishes a named Adobe Commerce Cloud exit with numbers, none of the six other agencies publishes a migration case with a before-and-after number on the pages read, only scandiweb and Snowdog appear on the hyva.io partner list, and only MGT Commerce prints a price on its homepage.

Two things changed in 2026. Adobe's documentation for Adobe Commerce as a Cloud Service states that the edition does not support Luma storefronts and that its data migration service handles first-party core commerce data only, so a move to the SaaS edition is a rebuild for any customized store. Adobe Commerce 2.4.6 left regular support on 11 August 2026, and Adobe's lifecycle page states that from 1 June 2027 Adobe will no longer maintain Cloud environments running unsupported Commerce versions, so a store on an old version faces a choice between an upgrade in place and a move.

Use the ranking table for the shortlist, the scenario table to match your situation, and the evidence ledger to check every number before it goes into a board paper.

1. Fastly VCL that will not port. Adobe's Fastly page, updated 25 August 2026, documents custom VCL snippets as Varnish 2.1 compliant, so a snippet written for Adobe's Fastly service does not drop into a self-hosted Varnish install unchanged. The failure mode is a cache that never hits after cutover, or a purge that stops firing. Criterion 3 rewards an agency that says who rewrites the VCL and what replaces the web application firewall and the image optimization.
2. The deploy pipeline stops at cutover. On cloud infrastructure the build, deploy, and post-deploy hooks live in the .magento.app.yaml file and run through Adobe's ece-tools package, which Adobe describes as the scripts that manage and deploy the application. Off Adobe's cloud, none of that exists. The failure mode is a first production deploy done by hand in the small hours. Criterion 3 asks for the replacement pipeline by name.
3. Order IDs stop advancing in threes. Adobe documents Pro production as a Galera cluster with one MariaDB per node and an auto-increment setting of three across every database, so entity and order IDs advance in threes. After a move to a single-writer database they advance by one. The failure mode is an ERP order intake or accounting export keyed on a contiguous increment_id that drops or duplicates rows without an error. Criterion 4 rewards a published ERP case.
4. The var directory left behind. Adobe's remote storage page, updated 19 August 2026, states that the sync command migrates files in pub/media and not the import and export files in var, and that the feature applies to Commerce 2.4.2 and later. The failure mode is a media library that arrives intact while every scheduled import file is gone. Nobody on this page publishes a media migration method, so this stays a question for the first call.
5. A Luma storefront on the SaaS route. Adobe's overview of Adobe Commerce as a Cloud Service, updated 11 September 2026, states that the edition does not support Luma storefronts. A merchant who budgets a data move and gets a storefront rebuild has the wrong number by a multiple. Criterion 5 rewards the two agencies listed on hyva.io, scandiweb and Snowdog, because a rebuilt frontend is the part of the move an agency can show.
6. Third-party data that the SaaS migration skips. Adobe's migration page for the SaaS edition, updated 11 September 2026, states that its data migration service supports first-party core commerce data only, does not handle custom or third-party entities, and that custom tables identified during assessment need an App Builder customization. The failure mode is a loyalty, subscription, or B2B quote table that never arrives. Ask for the assessment output before the quote.
7. Redirect gaps that cost organic traffic. A replatform changes URL structure, and a 301 map with gaps costs rankings for months. scandiweb's Zvaigzne ABC case reports 21,000 redirects with branded impressions up 47.4% year on year, and its BUFF case reports more than 120K redirects with organic traffic held. Those are two projects, not a rule. Criterion 1 rewards an agency that publishes the redirect count, because the count is the audit.
8. ERP connector drift after go-live. The connector is the piece that keeps breaking after the store moves. scandiweb's IONTO case describes an Infor ERP connector that went from frequent daily sync errors to none after an overhaul, and its Macron case names SAP and Pimcore on a B2B replatform. Wagento states six ERP platforms integrated. The failure mode is a connector nobody documented that fails on the first Monday. Criterion 4 covers it.
9. The four things Adobe never owned. Cron topology and background job timing, transactional email sent from an IP with no reputation, hardcoded server paths inside custom modules, and third-party services still calling the old egress IPs after the DNS change. None of this is in Adobe's documentation because none of it was Adobe's. No agency here publishes a cutover checklist, so ask for one and read it before signing.

Four parts of a store on Adobe Commerce on cloud infrastructure belong to Adobe, and a merchant leaving has to replace each one before any order data moves. All four are documented on Adobe's Experience League, and the update dates below are the ones shown on the pages read on 22 September 2026.

Fastly

Adobe's Fastly page, updated 25 August 2026, lists the services included at no additional cost: a Varnish-based CDN, cache management with custom VCL snippets, GeoIP, TLS enforcement, custom timeouts and error pages, a web application firewall available on Pro and Starter Production environments only, DDoS protection against layer 3 and 4 attacks, origin cloaking, image optimization, and a domain-validated Let's Encrypt certificate for each Staging and Production environment. The same page documents the custom VCL snippets as Varnish 2.1 compliant, so they do not drop into a self-hosted Varnish install unchanged. Budget a VCL rewrite, a replacement WAF, a replacement image pipeline, and new TLS termination.

Build and deploy

Adobe's ece-tools page, updated 10 September 2026, describes the package as a set of scripts and tools designed to manage and deploy the Commerce application, with build, deploy, and post-deploy commands that run by default from the hooks property of the .magento.app.yaml file, and functions covering cron jobs, configuration checks, and Adobe patches. None of that exists off Adobe's cloud. The replacement pipeline belongs in the statement of work by name, and the app/etc/env.php for the new environment has to be written before the first deploy runs.

Database

Adobe's Pro architecture page, updated 1 September 2026, documents the production environment as three virtual machines behind an Elastic Load Balancer managed by an HAProxy per VM, running a Galera database cluster with one MariaDB MySQL database per node and an auto-increment setting of three for unique IDs across every database. Entity and order IDs therefore advance in threes. Anything downstream that assumes contiguous increments, such as ERP order intake, accounting exports, or a warehouse system keyed on increment_id, has to be tested before the cutover date.

Media and shared files

The same Pro architecture page documents GlusterFS as the file server for static file deployments and synchronization, with four directory mounts: var, pub/media, pub/static, and app/etc. Off Adobe's cloud, media normally moves to Amazon S3 through the Remote Storage module, which Adobe's remote storage page, updated 19 August 2026, documents for Commerce 2.4.2 and later with Amazon S3 as the one listed provider and limited support on cloud infrastructure. Adobe states that the sync command migrates files in pub/media and not the import and export files in var, so the var directory needs its own plan.

What Adobe never owned

Four things still break at cutover even though none of them was Adobe's: cron topology and background job timing, transactional email sent from an IP with no reputation, hardcoded server paths inside custom modules, and third-party services still calling the old egress IPs after the DNS change. No agency on this page publishes a cutover checklist, so ask each shortlisted firm for one.

Timing and cost

Adobe publishes no timeline for a move in either direction. The rebuild of Fastly, the deploy pipeline, and media storage happens before any DNS change, so ask each shortlisted firm for the go-live date of a named store it moved. On cost, Adobe's cloud folds hosting, Fastly, the WAF, and platform operations into one invoice; self-managed splits the same functions into a license, an infrastructure bill, and either a DevOps hire or a retainer. Ask for a three-year model with those lines shown separately.

Adobe Commerce as a Cloud Service is the multi-tenant edition that Adobe's feature comparison describes as automatically upgraded through a versionless model. Its documentation was updated on 11 September 2026, and three of its statements decide the budget for any store considering the move.

First, the storefront. Adobe's overview states that Adobe Commerce as a Cloud Service does not support Luma storefronts, and describes the storefront as powered by Edge Delivery Services with document-based authoring or visual editing. A Luma store, or any store whose theme is a Luma descendant, gets a new frontend as part of the move. That is the reason criterion 5 rewards a Hyvä listing on hyva.io: scandiweb at Platinum and Snowdog at Gold are the two agencies here with a published frontend rebuild practice.

Second, the customizations. Adobe's feature comparison states that the SaaS edition is out-of-process only, through APIs, events, and App Builder, while the PaaS edition supports in-process PHP customization and the Marketplace's PHP extensions. The same page states the PaaS edition requires manual upgrade and patching at six patch releases and one minor release a year, while the SaaS edition is automatically upgraded by Adobe through a versionless model. Every PHP extension a store relies on today either has an out-of-process equivalent or has to be rebuilt.

Third, the data. Adobe's migration page describes an assessment that produces effort estimates after identifying custom modules, third-party extensions, integrations, database schema, and custom tables; a Commerce Developer MCP for AI-assisted modernization that moves customizations to App Builder and storefronts to Edge Delivery Services; and a Commerce Data Migration Service for extracting, loading, and verifying catalog, customer, and order data. The page states the migration service supports first-party core commerce data only, does not handle custom or third-party entities, and that custom tables identified during assessment are not handled by the standard migration and require an App Builder customization.

One more statement changes how upgrades feel after the move. The overview states that Adobe sends in-app notifications when new feature and security updates are released, with a 30-day period to evaluate them in sandbox instances before they are applied to production automatically. A store that moves to the SaaS edition trades the version table on this page for a rolling 30-day window.

No agency on this page publishes a completed move to Adobe Commerce as a Cloud Service with a number. That absence is recorded, not penalized beyond criterion 2, because the edition is new enough that the published record has not caught up. A merchant on this route should run Adobe's assessment first and put its output, not the agency's estimate, at the top of the quote.

Adobe's own feature comparison names the editions that create the confusion: Adobe Commerce as a Cloud Service, multi-tenant and upgraded automatically, and Adobe Commerce on Cloud, single-tenant with manual upgrades. Add the self-managed license, which Adobe's remote storage and lifecycle pages document alongside the cloud editions, and a merchant searching for a cloud migration agency is on one of three routes that share almost no work.

The first route is the one with the most published evidence on this page. The second is the newest, and its published record is Adobe's own documentation rather than agency cases. The third is the hardest to buy, because leaving means rebuilding Fastly, the deploy pipeline, the database topology, and the file storage before a single order moves, and because neither of the two firms here that publish the hosting leg publishes an application migration case.

The practical consequence is that the first question to ask any agency is which route it means. An agency that answers with a case study on the wrong route is not lying; it is answering a different question. This page scores route coverage at 20 points for that reason and states, for each agency, which route its own site evidences.

Seven agencies were shortlisted in August 2026 because each publishes, on its own site, work that maps to one of the three routes this page covers: onto Adobe Commerce on cloud infrastructure, onto Adobe Commerce as a Cloud Service, or off Adobe's cloud to hosting the agency runs. The roster was fixed at first publication and is unchanged in this edition. The shortlist rule and the exclusions are on the methodology page.

Every fact about an agency was read on that agency's own site, its Clutch profile, hyva.io, or a company register on the date in the evidence ledger, and the sentence that uses it names the source. Platform facts come from Adobe's Experience League pages with the update date shown where the fact is used. Six scandiweb case studies and all seven homepages were re-read on 22 September 2026.

Claims removed in this edition because they could not be read on a page that day: Wagento's Pune office, scandiweb's AWS Partner statement, and the environment variable name that Adobe's older documentation used for service credentials, whose page no longer exists under Adobe's reorganized documentation. Each has a ledger row marked removed, and the changelog records the edit.

The page is refreshed monthly with a changelog line, and the author answers correction requests at research@scandiweb.com within five working days. The citation line below is the one to use.

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

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