E-commerce Replatforming: What to Settle Before You Choose the New Platform

A replatform is usually sold on the new storefront: faster, cleaner, easier to run. It is usually lost on the things behind the storefront that nobody listed, because they were never visible. The URLs that carried the organic traffic. The pricing rule a former developer set up for one trade account. The nightly export the warehouse depended on.

This is the list we work through before a platform is chosen, in the order it matters.

1. Decide whether to move at all

The first honest question is whether the platform is the problem. Stores that feel slow and fragile are often carrying a long list of extensions, a database nobody has tuned and hosting chosen on price. None of that is fixed by a new platform, and all of it follows you if the habits behind it stay the same.

Replatform when the business needs something the platform genuinely cannot do, or when keeping it current costs more than moving. For an older Magento store, the second is increasingly the case: every 2026 security bulletin patches the 2.4.4 line and newer, and nothing older.

2. Write down what the current store actually does

Not what the specification said years ago. What it does today:

• Every extension, plugin or app, and what it does in business terms: “trade customers see contract prices”, not the module’s name.
• Every customisation a developer made, including the ones nobody remembers asking for.
• Every rule the store enforces: shipping by postcode, products that cannot ship together, minimum order values, tax handling.
• Every integration, in both directions, and how often it runs.

This list is the real specification for the new platform. It is almost always longer than anyone expects, and each item on it becomes an app, a setting or custom work on the other side.

3. Inventory the URLs Google actually has

The most common way a replatform destroys value is invisible on launch day: the new platform uses different URLs, the old ones start returning 404s, and years of rankings go with them. Shopify, for instance, forces /products/ and /collections/ into every product and category address.

Build the inventory from what search engines have indexed and what other sites link to, not just the current sitemap. Every URL needs a destination. Then check the redirects mechanically, before launch and again after. When we moved this site off WordPress, the build refused to deploy unless every legacy URL still resolved or redirected. A spreadsheet nobody re-runs is how redirects quietly rot.

4. Look at the data before you plan to move it

Products, variants, categories, customers and order history all move, but how cleanly depends on the state they are in. Inconsistent variants, attributes held in free text, three versions of the same product description: moving messy data to a new platform gives you the same mess somewhere more expensive.

Two platform facts to plan around early:

• Customer passwords usually do not transfer. Platforms hash passwords differently, so customers normally need to reset, or sign in with a one-time code where the new platform supports it. Plan the email before launch.
• Product structures differ. Shopify, for example, allows three options per product. A catalogue built around more attributes needs restructuring before it moves.

If the catalogue is the problem, cleaning it is a project in its own right, and sometimes a PIM is the answer.

5. Treat integrations as the timeline

ERP, POS, warehouse, freight, payments, accounting, marketing. These decide how long a replatform takes, and they are where estimates go wrong, because a quote based on catalogue size ignores them. For each one, settle which system owns which data, which direction it flows and how quickly it has to arrive. We wrote up what ERP integration actually costs separately.

6. If you sell B2B, write the rules down first

B2B stores are where replatforms go most badly wrong, because so much of the value is in rules rather than pages:

• Customer-specific pricing, contract prices and volume breaks, often held in the ERP.
• Company accounts with buyers, approvers and spending limits.
• Payment on account and credit terms.
• Quote history and reorder lists that buyers rely on every week.

Much of this was configured years ago by people who have since left, and none of it is visible from the storefront. It has to be written down, rebuilt and tested with real accounts before cutover. A trade buyer who sees the wrong price on launch day will ring your sales rep, not refresh the page. More on how we approach B2B e-commerce.

7. Choose the platform last

With the list, the URL inventory, the data and the integrations in hand, the platform choice mostly makes itself:

• Shopify or Shopify Plus when you would rather not run infrastructure, and your rules fit a hosted platform.
• Adobe Commerce or Magento Open Source when catalogue rules, B2B complexity or several storefronts from one catalogue need a platform you control.
• WooCommerce when content and commerce live together and you want to own the store outright.

The direction matters too. The move we are asked about most is Magento to Shopify, and WooCommerce to Shopify is common. Moving from Shopify to Adobe Commerce is rarer and more specific; we cover when it is right on our migration page.

8. Plan the cutover and the month after

A launch plan with a rollback position, then active monitoring once real traffic arrives: redirects, search performance, conversion, and the integrations running on real orders. Rankings dip during reindexing and recover; that is normal. Finding a broken redirect chain six weeks later is not. A replatform is judged on the month after go-live, not the day of it.

Where we fit

We work on both sides of most Australian replatforms. Two of our developers hold Adobe Commerce certifications and three are Shopify certified, and we run Adobe Commerce platforms in production. So our advice on whether to move, and where, is not tied to either. More on our e-commerce migration and replatforming work.