Most replatform plans spend their time on the things that are easy to see: the theme, the product import, the apps that replace Magento extensions. Those matter. But the failures we get called in to fix after a migration are almost never about products. They are about URLs that no longer resolve, orders placed during cut-over that landed nowhere, and customers who cannot log in.
Here is the pattern we use for moving a large Magento store to Shopify Plus without a maintenance window, and why we treat the redirect map as the centre of the project rather than a task at the end.
why is the redirect map the project?
A Magento store that has been trading for a while has accumulated URLs everywhere: category paths, product paths with and without category prefixes, layered navigation URLs, old campaign landing pages, CMS pages, and URL rewrites that point to other rewrites. Search engines have indexed many of them. Customers have bookmarked some. Marketing emails and ads link to others.
Shopify has its own fixed URL structure for products, collections and pages. Almost every old URL will change. Each one that changes without a redirect is a lost ranking and a broken link.
So the first thing we build is not the theme. It is a complete inventory of URLs that matter, mapped to their new home.
building the map
We build the map from several sources, because no single one is complete:
- Magento’s URL rewrite data. The canonical list of what the store itself knows about.
- Search console and analytics exports. The URLs that actually receive traffic and impressions, including ones Magento no longer generates.
- Server logs. The long tail: old links still being requested.
- Backlink exports. External links you do not control and cannot update.
Then we normalise and match:
-- One row per legacy path, with its traffic and its target.
SELECT legacy_path,
sessions_90d,
target_type, -- product | collection | page | search | home
target_handle,
match_method -- sku | id | title | manual
FROM redirect_map
ORDER BY sessions_90d DESC;
Most rows match automatically by SKU or entity ID. The rest are matched by hand, highest traffic first. Every row has a method, so we can audit how it was decided.
A few rules we hold to:
- No chains. An old URL redirects straight to its final destination, never through another redirect.
- No blanket redirects to the homepage. A discontinued product goes to its closest collection, not the front door.
- Query strings handled deliberately. Layered navigation URLs map to filtered collections where it makes sense, and to the parent collection where it does not.
- Tested before cut-over. Every row is requested against the new store on a staging domain, and every response is checked for status and destination.
The map is then loaded into Shopify’s URL redirects, in bulk, before launch.
data: snapshot, then delta
The data move happens in two passes so the old store can keep trading.
- Snapshot. A full migration of products, customers and historical orders into the new store, days or weeks ahead. This is where the bulk of mapping and cleanup happens.
- Delta. Right before cut-over, everything created or changed since the snapshot is moved again: new orders, new customers, updated stock.
Both passes are idempotent. Every record carries its Magento ID, stored in a metafield, so re-running the delta updates records rather than duplicating them. That is what lets us rehearse the whole migration several times on a staging store without fear.
how do you cut over without a maintenance window?
On the day, the sequence is short:
- DNS TTLs lowered well in advance.
- Final delta sync, with the gap between the last Magento order and DNS switch kept as short as possible.
- DNS switched to Shopify.
- Magento left running in read-only mode for a period, so any order placed in the overlap is captured and synced in a final pass.
- Redirect checks, checkout checks and order flow checks run against the live domain.
Nobody sees a holding page. Customers on the old store finish their sessions there; new sessions arrive on Shopify.
the parts people forget
- Customer passwords do not migrate. Customer accounts come across, passwords do not. Plan the reactivation message and the timing, and expect support questions.
- Integrations point at Magento. ERP, WMS and marketing tools all need to switch at the same moment, and each needs its own test.
- Order numbering. Decide whether new orders continue the old sequence or start fresh, and tell finance and the warehouse.
- Post-launch monitoring. Watch 404s in the first weeks and add redirects for anything the map missed. There is always something.
what good looks like
A good migration is uneventful. Search traffic dips slightly and recovers. Customers notice a faster store, not a broken one. The team does not spend the first month answering tickets about missing pages.
It gets there because the dull parts were done first: the URL inventory, the matching, the repeatable sync and the rehearsals.
If you are planning a replatform onto Plus, see how we handle large-scale deployments or read the anonymised replatform write-up.