Most Magento migration guides walk through the tool’s steps. This one covers what decides whether anything goes missing: what to count, how to prove each record arrived, and why nothing old is switched off until its new home is verified. It rests on the replatform we ran for Al Majed for Oud and on our own migration scope.
What “zero data loss” meant on one real store
When Al Majed for Oud moved to the new Magento store we built, years of products, orders and customer records had to come across. Losing a customer’s order history, or a product page that ranked, would have moved the revenue problem rather than solving it.
The case record sets out the method in one sentence: every product, order and customer record was inventoried and mapped before the replatform began, and nothing was switched off until its new home was verified. The full history arrived intact, and search visibility carried over. The Al Majed for Oud case study has the rest of the engagement.
“Zero data loss” is a claim you can only make if you counted first. In our scope it means a record-for-record reconciliation at the destination: every item on the old store is either found on the new one or listed as a deliberate decision not to bring it.
The inventory: count everything before anything moves
The inventory is a sheet, not a feeling. Each row below is something we count on the old store, with where it tends to hide and how we prove it arrived.
| What to count | Where it hides | How to prove it arrived |
|---|---|---|
| Products, including disabled and out-of-stock items | Filtered out of the admin’s default views | Count by status and type on both sides; spot-check variants and their options |
| Images and media | Files referenced by products but stored outside the catalogue export | Count files, then check a sample of product pages for missing images |
| Customers | Guest checkouts that never created an account | Count accounts; confirm a sample can sign in or reset a password |
| Orders and their statuses | Old statuses the new store does not have | Count by status and year; open a sample of old orders as the customer would |
| URLs that earned rankings or links | Old category paths and product URLs nobody links to internally any more | Every URL on the list returns the right page or a redirect to it |
| Integrations and scheduled jobs | A stock sync or an export that runs at night and is in nobody’s notes | Each one listed, rebuilt or retired by name |
| Settings and environment values | Tax rules, shipping tables and payment settings set years ago | Compared line by line, then tested with real test orders |
Counting what exists is quick. Finding what nobody wrote down is not, and that is usually where the migration estimate moves.
The redirect map is part of the migration, not an SEO extra
On the Al Majed replatform, every URL that had ever earned a ranking got a mapped redirect, and the new category structure was designed around how customers search. Treating the move as an SEO project is how the store’s search visibility carried over to the new store.
The way we build the list of URLs to map:
- Crawl the old store for every live URL.
- Add every page with search impressions in Search Console over the last year, including ones the crawl did not find.
- Add every URL that has links from other sites, from your backlink tool of choice.
- Map each one to its closest equivalent on the new store, one to one. Send a page to the homepage only when nothing related exists.
- Test the full map on staging, then watch for not-found errors and lost queries for several weeks after launch.
Rehearse, cut over, and keep the old store warm
We run the whole migration on staging first, start to finish, and the rehearsal produces the cutover runbook: the exact order of steps, who does each, and how long each took. The rollback plan is agreed in writing before the switch is thrown.
On cutover day, new orders keep arriving on the old store until the last moment. Moving from Magento 1 to Magento 2, Adobe’s Data Migration Tool handles this with its delta mode, which carries across records created after the main data run. Moving from another platform, the same job falls to a final incremental export.
Then the rule that gives the method its name: the old store is held warm, not deleted. If a reconciliation count is off or an integration fails, there is somewhere to go back to. We monitor the new store against the pre-move baseline until the graphs settle, and only then is anything switched off.
- 01Rehearse on stagingThe whole migration, start to finish
- 02Write the runbookExact order, who does each step, how long
- 03Agree the rollbackIn writing, before the switch is thrown
- 04Cut overOld store takes orders until the last moment
- 05Late recordsDelta mode, or a final incremental export
- 06Old store warmHeld, not deleted, in case a count is off
- 07MonitorAgainst the pre-move baseline until graphs settle
- Switch off the old storeOnly once its new home is verified
When a migration is the wrong answer
Some stores ask for a migration when the problem is a slow theme, a plugin conflict or an under-resourced team. A move will not fix any of those. Our migration audit exists for this reason: an inventory and a written verdict, including whether the move is worth making at all.
Three cases where we would say not yet. An upgrade within Magento may be enough if the store is one or two versions behind. A store that has not counted its data cannot be quoted honestly, so the audit comes first.
A store moving off Magento altogether needs a different plan; our Magento to Shopify migration page covers that route. For the wider question, read when you should actually migrate your platform.
