Yuvraj Raulji | Magento migration
A migration is four problems wearing one name: the catalogue has to be modelled again rather than copied, the URLs have to survive, the order and customer history has to arrive intact, and the business has to keep trading throughout. The technical part is rarely what goes wrong. The mapping is.
Direct answer
A Magento migration moves a live store from another platform onto Magento 2 or Adobe Commerce. The work is four things at once: remodelling the catalogue into Magento attribute sets rather than copying fields across, preserving the URL structure and redirects so search rankings survive, transferring customers and order history so support and returns still work on day one, and sequencing the cutover so the business keeps trading. Data transfer is the smallest of the four. The catalogue remodelling and the URL work are where migrations are won or lost.
Best suited for
- Outgrowing a hosted platform on catalogue or pricing complexity
- Consolidating several storefronts onto one platform
- Moving off a legacy or unsupported system
- Adding B2B ordering to a business already trading B2C
What this page is not
This page is about arriving on Magento from somewhere else. Changing Magento version, including Magento 1 to Magento 2, is a different job with different risks, and it has its own page.
The problem
The symptom as the person carrying it would describe it, and the part that shows up in the numbers rather than in the ticket queue.
The catalogue does not fit the new model
What it costs
Product data that was flat on the old platform has to become attribute sets, configurable products and scope-aware values. Copied across as-is it produces a catalogue that technically imports and cannot be merchandised, and the cost lands months later on the people trying to use it.
Traffic falls after launch and nobody predicted it
What it costs
The URL structure changed, the redirect map was partial, and the pages that ranked were not the pages anyone tested. This is the most common way a technically successful migration becomes a commercial failure.
Order history did not come across
What it costs
Support cannot answer a question about anything bought before launch, returns break, and lifetime-value reporting starts again from zero. It is discoverable on day one and expensive to fix afterwards.
The cutover needs the shop closed
What it costs
Every day of downtime is revenue, and a big-bang launch concentrates all of the risk into the one night nobody has slept. A phased cutover costs more in planning and much less in outcome.
Approach
In this order, and the order is the opinion. Most of what goes wrong on this kind of engagement is a step taken before the one it depends on.
Map before moving
Every field on the old platform gets a decision: which Magento attribute it becomes, which scope it lives at, or that it is deliberately dropped. The map is the deliverable that makes the rest of the migration boring, and it is the step people try to skip.
Model the catalogue in Magento terms
Attribute sets, configurable and simple product structure, category taxonomy and price scope, built for how the business merchandises rather than for how the last platform happened to store things.
Preserve the URLs
A full redirect map from the ranking pages, not just the top level. Canonicals, layered navigation URL handling and the sitemap are decided at the same time, because on Magento faceted URLs are what quietly consume the crawl budget after launch.
Move customers and orders
Accounts, addresses, order history and, where they exist, credit terms and company accounts. Verified by reconciliation against the source rather than by a row count.
Cut over in phases
Rehearsed on a full data set, with the rollback path written down before it is needed. Where the structure allows it, traffic moves in stages rather than in one night.
Scope
Sources
WooCommerceShopify and Shopify PlusMagento 1Custom and legacy platforms
Data
Catalogue and attributesCustomers and addressesOrder and invoice historyMedia and digital assets
Search preservation
Redirect mappingCanonical strategyLayered navigation URLsSitemap and crawl budget
Cutover
Rehearsal on full dataPhased traffic moveRollback planPost-launch reconciliation
Proof
Both are multi-store Magento 2 platforms where catalogue structure was the constraint.
Magento 2 · Marketplace
Multi-category marketplace
A scalable Magento 2 platform powering a wide multi-category retail catalogue.
Magento 2Multi-categoryScale
Custom platform · B2B
Procurement and approvals platform
Scalable B2B procurement platform streamlining purchase requests and approvals.
B2B workflowsApprovalsIntegrations
Outcome
500K+
SKUs carried across multi-store catalogues
Catalogue scale is what makes the mapping step non-negotiable. At this size a field mapped wrong is not a bug report, it is a category that cannot be merchandised.
Where this came from
From the employment record: multi-store Magento 2 platforms handling 500K+ SKUs and 1M+ monthly users.
Search visibility held through the move
The measure of a migration is what the organic traffic does in the eight weeks after launch, not whether the site went live on the planned date. That is why the redirect map is treated as a launch blocker rather than a follow-up task.
No before-and-after traffic figure is published for a named migration here, because the ones I have worked on belong to the businesses that ran them. The scale figure above is from the delivery record and describes the catalogues involved, not a result claimed for this service.
Questions
- How long does a Magento migration take?
- The mapping and catalogue modelling dominate the timeline, and both scale with how messy the source data is rather than with how many products there are. A clean single-store catalogue is a different order of work from a multi-store catalogue with inconsistent attributes, and the honest answer comes after reading the source data rather than before.
- Will the migration hurt our search rankings?
- It can, and that is the main commercial risk. Rankings are held by mapping every ranking URL to its replacement before launch, keeping the redirect chain to one hop, and deciding canonical and faceted-URL handling at the same time. Rankings usually wobble for a few weeks even when this is done properly; they fall and stay down when it is not.
- Can we migrate without taking the store offline?
- Usually the store stays trading throughout and only the final cutover has a short window. What makes that possible is rehearsing the migration on a full data set first, so the cutover is a repeat of something that has already worked rather than the first attempt.
- Does order history come across?
- Yes, and it should be treated as a requirement rather than an option. Customers, addresses, orders and invoices transfer, and on B2B platforms company accounts and credit terms come with them. It is verified by reconciling values against the source, not by comparing row counts.
- Should we move to Magento or to Shopify Plus?
- It depends on whether your complexity is real. Magento is worth its operating cost when the catalogue, the pricing logic or the approval structure genuinely is complicated; Shopify Plus wins on speed of operation when it is not. That decision belongs before a migration, not during one.
Next step
Describe what is actually in front of you and we will work out whether this is the right piece of work before anyone scopes it. That conversation is usually shorter than people expect, and it occasionally ends with me saying you do not need the project.