If your store still runs on an unsupported Magento 1 build, a heavily customised WooCommerce install nobody fully understands anymore, or a bespoke platform from 2016, you already know the pain — every change takes longer than it should, and every developer you bring in wants to touch something nobody’s touched in years. The question isn’t whether to move off it. It’s whether to migrate or rebuild, and those are two very different projects with very different costs.
This guide breaks down the difference, the signs that tell you which one you need, and what each actually costs in time and budget.
What Counts as a Legacy Ecommerce Platform?
A platform is legacy when it’s no longer actively maintained by its vendor, when the version you’re running has stopped receiving security patches, or when the codebase has been customised so heavily that upgrading it safely is no longer realistic. Magento 1 (end-of-life since 2020) is the most common case we see, followed by custom PHP builds from agencies that no longer exist, and WooCommerce installs carrying 40+ plugins accumulated over a decade.
Age alone doesn’t make a platform legacy — a well-maintained five-year-old Shopify store is fine. The signal is unmaintained, unpatched, and undocumented.
Signs It’s Time to Move
- Page speed has degraded and no amount of caching or plugin tuning fixes it
- Checkout abandonment is high and support tells you it’s “just how the platform behaves”
- Every new plugin or extension risks breaking something else — plugin conflicts are now routine
- No one on your team, or your agency’s team, can explain parts of the codebase
- You’re one payment gateway or PCI compliance update away from a forced, unplanned migration
Migrate vs. Rebuild: The Actual Difference
A migration moves your existing data, catalogue structure, and functionality onto a new, supported platform with minimal redesign. The goal is stability, not reinvention — same store, safer foundation.
A rebuild re-architects the store: new information architecture, new checkout flow, often a new catalogue structure, sometimes a new business model (subscriptions, B2B tiers, multi-warehouse fulfilment). The goal is fixing structural problems a migration can’t touch.
Most stores that ask “should we migrate?” actually need one or the other depending on why they’re moving — a slow, unsupported platform with a catalogue that otherwise works well is a migration. A platform that’s technically fine but converting poorly because of genuine UX or catalogue problems is a rebuild.
How to Decide
- Choose migration if the core shopping experience works and the problem is stability, security, or platform support
- Choose rebuild if conversion problems are structural — confusing navigation, a catalogue that doesn’t match how customers actually shop, or a checkout that needs capabilities the current platform can’t support
- Choose a phased approach — migrate first to stabilise, then rebuild features iteratively — when the business can’t absorb a long freeze on new development
Timelines and Cost Ranges
A straightforward migration for a mid-sized catalogue (under 5,000 SKUs) typically runs 4 to 8 weeks, largely spent on data migration, redirect mapping, and QA. A full rebuild — new design, new information architecture, new app stack — usually runs 3 to 6 months depending on catalogue complexity and how many custom integrations need rebuilding from scratch.
Budget follows the same split: migrations are scoped and priced tightly because the deliverable is well-defined. Rebuilds carry more variability because design and UX decisions get made along the way — get a fixed-scope quote with assumptions stated explicitly, not a rough estimate.
Protecting SEO Equity During the Move
The single biggest risk in either path is losing organic rankings built up over years on the old platform. Every URL that currently ranks needs a mapped 301 redirect to its new-platform equivalent — not a blanket redirect to the homepage. Canonical tags, structured data, and XML sitemaps need to be rebuilt and resubmitted on launch day, and rankings should be monitored weekly for the first two months post-migration, since search engines take time to recrawl and re-index a moved site.
What a Migration Project Actually Looks Like
A well-run migration follows a predictable sequence, and skipping steps is where most of the SEO and data-loss horror stories come from.
- Discovery and audit. Full inventory of every URL currently indexed, every integration in use, and every customisation the current platform relies on — you can’t migrate what you haven’t mapped.
- Data mapping. Products, customer records, order history, and reviews get mapped field-by-field to the new platform’s data model — this is where most quiet data loss happens if rushed.
- Redirect mapping. Every old URL gets a specific new-platform destination, built before launch day, not improvised afterward.
- Staged QA. The new store runs in a staging environment against real data, tested across checkout, search, filtering, and every payment method, before anything goes live.
- Phased rollout and monitoring. Launch during a low-traffic window, watch rankings, crawl errors, and conversion rate daily for the first two weeks, and keep the old platform’s data accessible as a fallback for at least 90 days.
Frequently Asked Questions
What counts as a legacy ecommerce platform?
Any platform version no longer receiving vendor security patches, or a codebase so heavily customised that safe upgrades are no longer realistic. Magento 1 and unmaintained custom builds are the most common examples.
How long does an ecommerce platform migration take?
A straightforward migration for a mid-sized catalogue typically takes 4 to 8 weeks. Larger catalogues, multiple integrations, or multi-currency/multi-region setups extend that timeline.
Will I lose SEO rankings during a migration?
Only if redirects and structured data aren’t handled properly. A migration with a full URL-mapped 301 redirect plan typically preserves the bulk of existing rankings within 4 to 8 weeks of relaunch.
Should I migrate or rebuild an outgrown Magento 1 store?
If the catalogue and shopping experience still work and the only problem is the unsupported platform, migrate. If conversion has been a long-standing structural problem, use the move as the opportunity to rebuild.
What does a rebuild cost compared to a migration?
Migrations are priced more tightly since the scope is well-defined — moving what exists. Rebuilds cost more and carry wider ranges because new design and UX work is being created, not moved.
Can I migrate and rebuild at the same time?
It’s possible but riskier — combining a platform change with a full redesign makes it harder to isolate whether a post-launch problem is a migration error or a new design issue. A phased approach (stabilise first, redesign iteratively) is usually the safer sequence for stores that can’t absorb a long freeze on new development.
Whether your store needs a stability-first migration or a full structural rebuild depends on specifics a generic guide can’t answer — the catalogue, the platform, and what’s actually broken. If you want a clear read on which path fits your store, book a technical audit with Mayday.
