Adobe Commerce development
Storefront design
Performance & SEO
AI & agentic commerce
Release tracker
Ecommerce replatforming means moving your store from one commerce platform to another: products, customers, orders, URLs, integrations and the storefront itself. Done well, customers barely notice the switch and search traffic recovers within weeks. The projects that lose sales usually skip one of three things: a clear reason to move, a complete URL redirect map, or a rehearsed cutover with a rollback plan.
This guide starts with the question most guides skip (should you move at all?), then walks through a phased plan you can adapt to any pair of platforms.
Step 0: decide whether to replatform at all
A replatform is one of the most expensive and disruptive projects an online store can run. Sometimes the problem is the platform. Often it is an old theme, a neglected upgrade, a slow host or a tangle of extensions, all of which can be fixed in place for less.
Score each statement from 0 (not true) to 2 (clearly true). Be specific: write down the evidence next to each score.
Replatforming scorecard
| # | Statement | What counts as evidence | Score 0–2 |
|---|---|---|---|
| 1 | The platform cannot support a business model you need within 12 months (B2B, marketplace, multi-region, subscriptions) | A written requirement the current platform's docs say it cannot meet | |
| 2 | Your version is out of support and an upgrade costs close to a rebuild | Vendor support dates; an upgrade estimate | |
| 3 | Total cost of ownership is rising faster than revenue | 12 months of licence, hosting, apps and developer spend | |
| 4 | Key integrations (ERP, PIM, OMS) are brittle or impossible | Incident log, manual workarounds, staff hours | |
| 5 | Performance problems persist after hosting and frontend fixes | Core Web Vitals field data before and after fixes | |
| 6 | Your team cannot hire or keep people with the platform's skills | Open roles, agency availability | |
| 7 | Content and merchandising teams are blocked by the admin | Tasks that need a developer every time | |
| 8 | Platform limits cap growth (catalog size, API rate limits, checkout rules) | Documented limits you are already hitting |
How to read it:
- 0–5: fix in place. Upgrade, tune performance, clean up extensions.
- 6–10: run a short discovery. Price both a fix-in-place plan and a replatform before deciding.
- 11–16: replatforming is likely justified. Start with requirements, not vendor demos.
Two statements deserve extra weight. If item 1 or item 2 scores 2 on its own, take the discovery step even if the total is low, because they tend to force the decision anyway. For Magento stores, item 2 is often the trigger: Adobe Commerce 2.4.6 left standard support on August 11, 2026, while 2.4.9 is supported until May 31, 2029. Upgrading within Magento is usually cheaper than leaving it, which is why a fair comparison such as Magento vs Shopify belongs in the discovery, not after it.
The phased replatforming plan
Every project is different, but the phases and their outputs are not. Durations depend on catalog size, integrations and design scope, so plan them after discovery rather than before.
| Phase | Key activities | Output you should have | Gate to move on |
|---|---|---|---|
| 1. Discovery | Requirements, data audit, integration inventory, SEO baseline | Requirements doc, platform decision, risk list | Signed-off scope |
| 2. Architecture | Data model, integration design, hosting, frontend approach | Architecture diagram, data mapping sheet, redirect strategy | Technical review passed |
| 3. Build | Theme, extensions or apps, integrations, admin setup | Working staging store | Feature-complete on staging |
| 4. Data migration | Scripted import, repeated test runs, delta plan | Repeatable migration with reconciliation reports | Two clean rehearsals |
| 5. QA and UAT | Functional, payment, tax, performance, accessibility, SEO checks | Signed UAT, performance results, redirect test log | No open critical defects |
| 6. Cutover | Content freeze, final delta, DNS, redirects live | Go-live runbook executed, rollback ready | Smoke tests pass on production |
| 7. Hypercare | Monitoring, fixes, Search Console checks | Daily issue log, traffic and revenue tracking | Metrics back to baseline |
Phase 1: discovery
Write requirements as outcomes ("B2B buyers see negotiated prices after login"), not features ("needs a pricing module"). Then inventory everything the current store does, including the quiet jobs: scheduled exports, feeds to marketplaces, email triggers, tax calculations, cron tasks. Missing a quiet job is the most common cause of post-launch surprises.
Capture a baseline at the same time: 12 months of traffic and revenue by landing page, top organic queries, conversion rate by device, and Core Web Vitals field data. Without a baseline you cannot tell whether the new site is doing better or worse.
Choosing the destination. Shortlist two or three platforms against your written requirements, not feature lists. Ask each vendor or implementation partner to demonstrate your three hardest requirements with your own sample data, such as a B2B price list, a complex configurable product and an ERP order export. Compare total cost over several years: licence or subscription, transaction fees, hosting, apps or extensions, and the internal team needed to run it.
Roles to fill. Even with an agency, someone inside the business must own decisions. Name a project owner, a merchandising lead for catalog and content, a finance contact for tax and payments, and a technical owner for integrations. Unowned decisions are the most common reason phases slip.
Phase 2: architecture
Decide the data model and integration pattern before design starts. Key choices: where product data is mastered (ERP, PIM or the platform), how orders flow to fulfilment, whether the frontend is native or headless, and which URLs will change. Changing URLs is not forbidden, but every change needs a redirect and costs some short-term ranking stability.
Phase 3: build
Build integrations early and against real data. A storefront that looks finished but cannot receive stock levels is not close to done. Keep a running list of customizations so the next upgrade is not a surprise.
Phase 4: data migration
Treat migration as software. Write scripts, run them repeatedly on fresh exports, and reconcile counts and totals every time: number of products, active customers, orders per year, gift card balances, store credit. Plan how customer passwords move; some platforms do not export them, which means a password-reset campaign at launch. Platform-specific details are in our guides to Magento 1 to Magento 2 migration and moving from Shopify to Adobe Commerce.
Phase 5: QA and user acceptance
Test the money paths first: add to cart, checkout with every payment method, refunds, tax by region, shipping rules, promotions, and order export. Then test performance under load and check accessibility. Crawl the staging site and the redirect map before launch, not after.
Phase 6: cutover
Choose a low-traffic window, freeze content and catalog edits on the old platform, run the final delta migration, switch DNS, and enable redirects. Keep the old platform available read-only for reference. Decide in advance what would trigger a rollback, and who decides.
Phase 7: hypercare
For the first weeks, review orders, errors, payment declines and search data daily. Google notes that rankings can fluctuate during a site move, and that medium-sized sites can take a few weeks or longer to settle.
How to protect sales and SEO during the move
Most lost revenue after a replatform comes from a handful of avoidable failures.
- Broken or missing redirects. Map every product, category, CMS and image URL that has traffic or links to its closest new equivalent with a permanent (301 or 308) redirect. Google advises keeping redirects for as long as possible, generally at least a year. Our ecommerce SEO migration checklist includes a redirect-map template.
- Lost on-page content. Category descriptions, product copy, title tags, structured data and internal links must migrate, not be rewritten from scratch at launch.
- Checkout regressions. A new checkout that adds a step or drops a saved payment method can cost more than any SEO dip. Test with real cards in production before announcing the launch.
- Tracking gaps. Re-implement analytics, conversion tags and server-side events before launch, and compare event counts with the old site during hypercare.
- Customer account friction. If passwords cannot move, tell customers before launch and make the reset flow obvious.
- Integration timing. Run ERP and warehouse integrations in parallel during rehearsals so stock and orders reconcile on day one.
Cost drivers to plan for
There is no honest average price for a replatform, but the drivers are predictable:
- Integrations: each system you connect, and whether it has a ready connector.
- Customization: custom pricing, checkout logic and B2B rules cost more than catalog size.
- Design scope: a new design system versus porting the current one.
- Data quality: messy attributes, duplicate customers and inconsistent SKUs add cleanup time.
- Licence model: open source, SaaS subscription with transaction fees, or enterprise licence.
- Internal time: your team's hours for decisions, content and testing, which are often underestimated.
A reliable estimate follows discovery, once integrations and data are known.
Frequently asked questions
How long does ecommerce replatforming take?
It depends on integrations, catalog complexity and design scope. Small catalogs with few integrations move much faster than B2B stores connected to an ERP. Fix the timeline after discovery, not before.
Will we lose SEO rankings?
Expect some fluctuation; Google says it is normal during a site move. Large or lasting losses usually trace back to missing redirects, changed content or blocked crawling, all of which you can test before launch.
Should we redesign at the same time?
Combining both is common and can save money, but it makes it harder to tell which change caused a dip. If risk tolerance is low, migrate first with a familiar design and redesign afterwards.
Can we migrate order history?
Usually yes, but decide how much. Many stores move all customers and a few years of orders, and archive the rest in a format the support team can still search.
Next step
If your scorecard points to a move, or to a Magento upgrade instead, Mistri can run the discovery and plan the migration. See our Magento migration services for how we approach data, redirects and cutover; a fixed quote follows that initial audit.
Sources
How to move a site with URL changes (Google Search Central); Redirects and Google Search (Google Search Central); Adobe Commerce system requirements (Adobe Experience League).
