Most stores that re-platform are not escaping their platform. They are escaping a build — an aging theme, twenty extensions nobody chose deliberately, hosting sized for the launch traffic of four years ago, and an upgrade that has been deferred so long it now looks like a rebuild.
The takeaway up front: re-platform when the constraint is structural — a business model your platform genuinely cannot express, or a total cost of ownership you cannot staff — and refuse when the constraint is implementation, because a migration copies your problems onto a new stack at full price. The test that separates the two is simple: write down your top five complaints, and mark which ones would still be true on a clean, current Magento install.
The complaints that are usually implementation, not platform
Work through these before you price anything, because each has a fix that costs a fraction of a migration.
"The site is slow." Magento is a large application, but slow storefronts almost always trace to specific, findable causes: full-page cache not being hit, an under-provisioned database or missing Redis and OpenSearch, unoptimised images, an extension injecting JavaScript on every page, or a heavy Luma-derived theme. These are measurable and individually fixable, and a frontend swap is a real option short of leaving — the trade-offs are laid out in the Luma vs Hyvä vs headless comparison.
"Upgrades break everything." That is a symptom of core modifications and unmaintained third-party modules, not of the platform's release cadence. It is also the strongest argument for cleaning house — because you will have to do exactly that work as part of any migration anyway, just under a launch deadline.
"It costs too much to run." Sometimes true and structural. Often it is a licence tier you have outgrown the need for, hosting bought without review, or a retainer covering work nobody has audited in two years. Price the current setup line by line before concluding the platform is the problem; the Magento store cost breakdown shows where the money usually sits.
"We can't find developers." A genuine constraint, and one of the more legitimate reasons to move — but check the market for your budget and region before treating it as fact. It is also partly self-inflicted: a heavily customised store is hard to staff on any platform.
"The admin is confusing for our team." Real, and rarely worth a migration on its own. Role-based permissions, a cleaned-up navigation, and a half-day of training solve most of it.
The reasons that genuinely justify moving
Structural constraints do not go away with better implementation. These are the ones worth acting on:
- Your business model has changed shape. Moving heavily into subscriptions, marketplace selling, complex B2B contract pricing, or a retail footprint that needs tight POS and inventory unification can put you outside what your current build supports without significant custom development.
- Total cost of ownership no longer fits your revenue. Self-hosted commerce carries a permanent cost floor: hosting, security patching, developer time, and version upgrades. Below a certain order volume, a hosted platform is simply cheaper to run — and above a certain complexity, the reverse is true.
- You have no team and no agency. A self-hosted store with nobody responsible for patching is a security incident waiting to happen. If you cannot fund maintenance, that is a structural reason to move somewhere the vendor maintains the software.
- You are on an unsupported version with no upgrade path. Merchants still running Magento 1, which reached end of life in June 2020, are not making a re-platform decision — they are making a migration decision, and the only question is where to.
- A licence tier change would cost more than the whole migration. Worth checking, and it does happen at the boundaries between commercial tiers.
What a migration actually costs
The quote you receive covers building the new store. The real bill has five parts, and the last three are the ones that surprise people.
| Cost area | What it covers | Commonly underestimated because |
|---|---|---|
| Build | Theme, layout, templates, configuration | This is the part people price properly |
| Data migration | Products, categories, customers, order history, reviews | Attribute mapping and custom attributes rarely map one-to-one |
| Integrations | ERP, accounting, shipping, tax, PIM, marketing tools | Each connector is a small project with its own testing |
| SEO continuity | URL mapping, redirects, structured data, canonical rules | A large catalogue means thousands of redirects, and mistakes cost traffic |
| Team change | Retraining staff, rewriting internal processes | Invisible in the quote, paid in the weeks after launch |
The category that sinks projects most often is SEO continuity. Every product and category URL that changes needs a 301 redirect to its new equivalent, and every redirect that is missed is a page that had rankings and now returns a 404. Build the redirect map from a full crawl of the live site — not from a spreadsheet of what the catalogue is supposed to contain — and test it on staging against your top thousand URLs by traffic before go-live.
Second is order history. Deciding whether to bring historical orders across is a real decision with a real price: customers expect to see their past purchases, support needs them for returns, and finance may need them for reporting. Archiving them read-only somewhere else is a legitimate answer, but it must be a decision, not an oversight.
A decision sequence you can run in a week
- Write the five complaints. Specific and concrete: "category pages take six seconds on mobile," not "the site feels slow."
- Mark each as platform or implementation. Would this still be true on a clean, current install of your platform with a modern frontend? If no, it is implementation.
- Price the fix path. Get a quote for resolving the implementation items where you are: hosting review, frontend replacement, extension audit, version upgrade. The safe way to run that upgrade is covered in the upgrade guide.
- Price the move path properly. Build plus data plus integrations plus redirects plus training, with a contingency. Then add the revenue risk of a launch window in your season.
- Compare against a three-year horizon. Re-platforming is not a one-year decision. Include ongoing licence, transaction, app, and hosting fees on both sides — hosted platforms move cost from developers to subscriptions and per-order fees, which changes the crossover point as you grow.
- Run a proof of concept before committing. Take your three hardest requirements — the pricing rule, the ERP sync, the shipping logic — and build them on the candidate platform first. If they are painful in a proof of concept, they will be worse at scale.
If steps two and three show most complaints are implementation and the fix path costs meaningfully less, stay and fix. That is the outcome for most established stores, and it is not a failure of ambition — it is refusing to pay a rebuild price for a maintenance problem.
If you decide to move, protect the revenue
- Do not launch in your peak season. Pick your quietest weeks and give yourself margin.
- Freeze the catalogue during the final data sync, or accept a delta-sync step and test it twice.
- Keep the old store readable for 30 days. Support will need it.
- Have monitoring on day one: error rates, checkout completion, and organic traffic by template. You want to know within hours, not at the end of the month.
- Run a full crawl the day after launch and again a week later, comparing against your pre-launch crawl to find broken redirects and missing pages while they still recover easily.
FAQ
How long does a Magento migration take?
For an established store with real integrations, plan in months rather than weeks — discovery and data mapping alone typically take several weeks before the build starts. Very small catalogues with no ERP and no custom logic move faster. Any timeline that does not name a dedicated window for redirect mapping and integration testing is a timeline that has not been thought through.
Will I lose SEO rankings when I migrate?
You will see movement; how much depends almost entirely on redirect discipline and whether page content and internal linking survive the move. Map every indexed URL to a destination, keep titles and on-page content substantially intact, preserve structured data, and expect a few weeks of fluctuation. Losses become permanent when redirects are missing, not simply because the platform changed.
Is Magento Open Source still a reasonable choice for a smaller store?
It can be, if you have development capability or an agency retainer. The software licence is free; the ongoing cost is hosting, patching, and upgrades, and that cost does not scale down to zero for a small merchant. The honest test is whether someone is accountable for applying security patches — if nobody is, self-hosting is the wrong fit regardless of catalogue size.
Should I move to a hosted platform just to stop worrying about hosting?
That is a legitimate motivation, and it is really a decision about where you want your costs and your control. Hosted platforms trade infrastructure work for subscription and transaction fees plus tighter limits on customisation. It is a good trade for stores whose differentiation is merchandising rather than commerce logic, and a poor one for stores whose competitive advantage lives in custom pricing, catalogue structure, or checkout.
Can I migrate the frontend without changing platform?
Yes, and for a lot of stores that is the highest-return option available. Replacing a heavy legacy theme, or moving to a decoupled frontend, addresses the speed and design complaints that drive most re-platform conversations while leaving your data, integrations, and URLs where they are.
Frame the decision before you price it
Re-platforming is worth doing when the platform is genuinely the constraint, and expensive theatre when it is not. Separate the complaints, price both paths over three years, and prove your hardest requirement on the candidate before you sign anything. When you get to the shortlist stage, compare e-commerce platforms side by side on setup effort, total cost of ownership, customisation depth, and scalability.
