Magento migration services
Three different projects get called a Magento migration, and they fail for different reasons. Here is how we scope each one, and what we have learned running them since before Magento 1 reached end of life.
Which migration are you actually doing?
The word covers three jobs with almost nothing in common. Getting the name right early is most of the estimate, because each one puts its risk somewhere different.
Magento 1 to Magento 2
Magento 1 reached end of life in June 2020 and stores are still on it. This is not an upgrade — it is a rebuild with a data migration attached. Nothing about the theme, the extensions or the customisations carries across, and the honest question is whether Magento 2 is still the right destination in 2026 or whether the budget belongs somewhere else.
Magento 2 version upgrades
Adobe Commerce moves, extensions lag behind it, and a store that skipped three releases is a bigger job than a store that skipped one. The work is mostly dependency archaeology and regression testing, and it is the one case where in-place is almost always right.
Migrating off Magento
Some catalogs no longer need a monolith. We move stores to BigCommerce, to Shopify Plus, and to an index-first stack on Next.js with Elastic or OpenSearch behind it. We will say plainly when staying on Adobe Commerce is the cheaper answer — a replatform to escape a maintenance bill often just relocates it.
What actually goes wrong•
None of these are surprises. They are the five failures we plan around at the start, because each one is far cheaper to prevent than to discover during a cutover weekend.
Upgrade in place, or move?•
The two options are not close on cost, and the deciding factor is usually the catalog rather than the code.
How we run one•
Three phases. The first two are where migrations are won, and they are the two that get compressed when a date is set before a scope.
Establish what is actually there
Before anything moves, we inventory the thing being moved.
- Full crawl plus Search Console coverage, to build the URL map from evidence
- Extension inventory, scored by whether the behaviour is load-bearing
- Catalog and attribute audit, including what each attribute is for
- Integration map — ERP, PIM, OMS, payments, tax, shipping
Move meaning, not just rows
The migration itself is scripted and repeatable, and run many times before it is run for real.
- Products, categories, customers, order history with referential integrity checked
- Attribute and facet configuration rebuilt deliberately, not inferred
- Akeneo or another PIM as the source of record where catalog complexity warrants it
- Reconciliation counts on every entity, every run
Make the switch boring, then watch it
A rehearsed cutover is a short one. Index recovery takes weeks after it, and the first fortnight is what tells you where the URL map was wrong.
- Redirects deployed with the launch, not after it
- Sitemaps and canonicals correct on day one
- Load tested against real concurrency, not a warm staging cache
- Rollback plan written down and tested
- Coverage and impressions tracked against the pre-migration baseline
- Redirect gaps found from live 404s and crawl data
- Search relevance retuned against real queries on the new platform
Why us
Two decades of enterprise commerce delivery, and a Magento practice that goes back far enough that our own archive is mostly Magento 1 end-of-life warnings written while it was still news. We work across Adobe Commerce, BigCommerce, Shopify Plus, Akeneo and Oracle WebCenter, and we build index-first storefronts on Next.js with Elastic or OpenSearch.
That range is the point: we have no reason to argue you onto a particular platform, because we deliver on all of them.
Tell us what you are on and where you are going
Send the platform, the catalog size and roughly what is customised. We will come back with which of the three migrations this is, what it usually costs, and whether we think you should do it at all.