Migration
Magento and Adobe Commerce
to Shopify Plus
The most common route into this practice, and currently the most time-pressured: Adobe Commerce 2.4.4 extended support ended in April 2026 and 2.4.5 ends in August, while Adobe pushes Open Source users toward paid Cloud licensing.
The decision is rarely about features any more. It is about a total cost of ownership running several times the managed alternative, and a stack that needs a developer on call to stay upright.
The deadline, and what it actually means
Nothing switches off. That is worth saying plainly, because a good deal of the noise around these dates trades on the implication that something does. A Magento store whose version has passed end of support keeps taking orders on the morning after exactly as it did the night before.
What stops is security patching from Adobe. From that point, every newly disclosed vulnerability in the platform is one the merchant fixes themselves, back-ports, or carries. Extension vendors start dropping the version at their own pace. And a store handling card data is expected, under PCI DSS, to run software that still receives vendor security updates — so the compliance position degrades quietly rather than failing on a particular morning.
The honest framing is a rising risk curve, not a cliff. It does put a clock on the decision, and it means the merchants moving in 2026 are a cohort under dated pressure rather than a steady trickle — which matters mainly because it affects how busy the competent delivery partners are at the moment the quote is requested.
Adobe Commerce 2.4.4 extended support ended April 2026. 2.4.5 ends August 2026. Both are Adobe's own published lifecycle dates — worth checking against the vendor rather than against anyone quoting for the work, including this page.
Catalogue size changes what the project is
The word "migration" covers three fairly different pieces of work. A quote that takes the same shape across all three has not asked the question yet.
Around 5,000 SKUs
The data moves cleanly and the work is mostly elsewhere — theme, checkout, integrations, redirects. The catalogue is small enough to inspect by hand at the end, which is worth more than it sounds.
Around 40,000 SKUs
Attribute mapping becomes the project. Magento's attribute sets and configurable products do not map one-to-one onto Shopify's option model, and the reconciliation is where the time goes. Sampling replaces inspection, so the sampling method has to be agreed up front.
200,000 SKUs and up
Now it is a data-engineering job with a storefront attached. Import limits, variant ceilings and the source of truth for the catalogue all become design decisions — and in most stores this size the answer is that the catalogue's real home is the ERP, not either platform.
The third case is the one that most often turns out not to be a migration at all, but a systems decision that a migration was standing in for.
URLs and the redirect map
This is the part that costs money when it is left late, and it is left late constantly — because it is unglamorous, because it belongs to nobody by default, and because it can only be finished once the new URL structure is settled.
Shopify's URL structure is fixed in ways Magento's is not: products live under /products/, collections under /collections/, and a Magento store with category-nested product paths will not reproduce its old URLs. Every one needs a redirect, and the ones that matter most are not the ones with the most traffic — they are the ones carrying the most inbound links, which is a different list and has to come from backlink data rather than analytics.
The failure mode
Rarely a missing redirect. Usually a chain of them.
An old URL pointing at a URL that itself redirects, two or three deep, each hop shedding a little authority and a little speed. The map is built and verified before cutover, then verified again against the live site afterwards — a redirect that behaved on staging can be intercepted by a platform rule in production.
Extensions and custom logic
A mature Magento store carries somewhere between a dozen and fifty extensions, plus whatever was written directly into the codebase over the years. The audit that has to happen first is not "what is installed" but "what is load-bearing", and those two lists are never the same length.
Native on Plus
Checkout customisation, multi-currency, staff permissions, wholesale pricing. Things Magento needed an extension for that Plus does in the platform — this column is where the cost-of-ownership argument actually lives.
App equivalent
Reviews, subscriptions, loyalty, advanced search, feed management. Real equivalents exist; the work is choosing them and accepting that a subscription line replaces a licence line. Both belong in the cost model.
Has to be rebuilt
Bespoke pricing rules, unusual tax or shipping logic, anything reaching into an ERP or a warehouse system. This column is the honest cost of the project, and it is sized by reading the code rather than by asking what the store does.
The third column is where a migration quote goes wrong most often, because it is the only one that cannot be estimated from a feature list.
B2B, customer groups and tier pricing
Magento's customer groups are a general-purpose mechanism: a group is a label any rule can hang off, and stores that have run for years tend to have accumulated rules nobody has read recently. Shopify Plus covers the same ground through company profiles, catalogues and price lists — a more opinionated model, a better fit for most wholesale operations, and a different shape.
So the migration question is not "does Plus support B2B", because it does. It is whether the store's existing pricing logic survives translation into that model, and what happens to the cases that do not — bespoke rules written against customer groups over a decade sometimes do not, and cutover is the expensive place to find that out.
Where a business runs retail and trade off one catalogue, this is usually both the reason the project is worth doing and the reason it needs scoping before a number gets quoted.
Net payment terms
Native on Plus
Per-customer catalogues
Native on Plus
Quantity breaks
Native on Plus
Quote workflows
Native on Plus
The other routes onto Plus
Magento is the most time-pressured route in 2026, not the only one. The work has the same shape wherever it starts — audit what is load-bearing, map the URLs early, rehearse the data, plan the rollback — and what changes is where the difficulty concentrates.
Routes delivered
Magento, WooCommerce, Wix and EKM. Four routes onto Shopify, run end to end. EKM was the hard one — a non-standard export with no clean path, so the extraction was built from scratch.
Same shape, not yet run here
Shopware, PrestaShop, BigCommerce, Volusion. Stated plainly rather than implied: these are the same class of work and we have not delivered one. Where that matters to a decision, it belongs in the proposal rather than on a page.
The variable that actually moves the quote is the same on every route, and it is not the source platform: it is how much custom logic reaches into systems outside the store. A BigCommerce store with a stock ERP behind it is a simpler project than a Magento store with none.
What it costs and how long it takes
Published rates for Magento to Shopify Plus migrations run from around $20,000 to well past $250,000, typically across three to six months. The range is that wide because it spans a small catalogue on a stock theme at one end and a re-platform with ERP integration and a custom storefront at the other — which is another way of saying the number means very little until the questions above have been answered.
Crossdock's working band is £15,000 to £25,000 for a migration delivered as prime contractor, with £10,000 as a floor for a genuinely simple move. Above that band the project is usually carrying a systems decision as well, and it gets scoped and priced as two pieces of work rather than one.
What moves the number, in rough order: the rebuild column above, the number of systems the store has to keep talking to after the move, catalogue complexity rather than catalogue size, and whether the business can take a cutover window or needs both stacks running in parallel.
None of that is the platform licence, which is a separate cost to the business and is not ours — the whole picture, licence and the parts that sit around it, is Shopify Plus pricing.
What this practice has and has not done
Crossdock is a new practice and has not yet delivered a published Shopify Plus migration. A page claiming otherwise at this stage would be inventing it, and anyone spending five figures is entitled to know which sort of page they are reading.
What stands behind it: StoreBuilder Ltd has delivered platform migrations onto Shopify from EKM and from Wix — including one whose EKM customer export was non-standard enough that the converter had to be built from scratch — along with the search, redirect and tracking work that decides whether a migration keeps its revenue. The slices a Plus project needs beyond that — ERP, warehouse systems, the specialist integrations — are delivered by named partners under a prime contract, so one operation is accountable for the outcome rather than four.
The sensible first step is the diagnostic rather than a proposal: a short structured read establishing what the store actually contains and what the move would involve — free, and useful whoever ends up delivering it.
More on how a project runs: the sequence and the cutover, what goes wrong and why, and the diagnostic itself.
Tell us what is breaking
What the systems are doing now, and what you need them to do. We will tell you whether it is a platform problem or something cheaper.