How to plan an e-commerce migration.

After years of accumulated frustration caused by having a B2B operation running on software designed for consumer retail, which causes slow checkouts, poor performance, and an operations team compensating for all of it with spreadsheets and manual workarounds, most businesses conclude it is time to move on to a different e-commerce platform. By the time we're brought in, the brief has been narrowed down to either migration or a full rebuild. It's a reasonable path, but there's a more useful, fundamental conversation to be had first.

A decade of experience has taught us that such a technological choice is only as good as the understanding behind it: how the business actually operates day to day, and where it intends to grow. Businesses that jump straight on to questioning which platform to choose next usually end up rebuilding old problems over newer software.

The underlying problem

Blaming an outdated platform is easy, and often fair. However, the harder and more valuable exercise is describing where the business needs to be in the next five years and what its systems will have to support along the way, because without a full picture, every technology decision gets made reactively. Migrate or stay, build or buy, which market to enter next: each question gets answered on its own, under pressure, disconnected from the others. Each can look sensible in isolation, but together they accumulate into technical, financial and operational debt.

This is why we start with an audit. It maps what the business is actually running on: the systems in place, the data moving between them, and the dependencies nobody wrote down but everyone quietly works around. Only once that picture exists do we turn to the plan, which sets out where the business needs to get to, which digital capabilities will take it there, in what order, and with what investment. It doubles as a framework for every technology decision that follows, and it's built to be revised as the business grows and the market shifts.

Building an e-commerce migration plan

Spoiler alert: it is only as good as the decisions it supports. Our e-commerce migration plans are built around the following questions: what to build on, what to connect, where to sell, what to automate, who runs it all, and how to know it's working.

Platform architecture

Every store ends up on the architecture its operation justifies, and these are the questions that decide it: whether the store runs on native themes or a custom front-end, where marketing content should live, which parts of the experience deserve bespoke development, and how deeply the platform ties into the systems around it.

Hey Harper and Coffee King show how differently those questions can resolve, even on the same platform. Hey Harper's store ran on Shopify templates, and as apps accumulated it became heavy, clumsy and slow, so we kept Shopify as the commerce engine and dropped its theme entirely, designing and rebuilding the front-end with Storyblok as the content management system. The result is the same platform with an entirely different architecture, which lifted sales by 59% and conversion by 17%.

Coffee King arrived with the opposite problem: several stores fragmenting data and management across markets, and wholesale buyers sharing an undifferentiated experience with consumers. There the answer was to go deeper into Shopify, consolidating everything into a single store serving both audiences, without so much as an upgrade to Shopify Plus. Two months after launch, conversion was up 29% and average order value up 38%.

A good plan makes those trade-offs of cost, speed and flexibility explicit before anyone commits to a rebuild, and it stays grounded about the full range of outcomes, including the one where the right move is keeping the platform you have and refactoring it properly.

Why and when we choose Payload or Storyblok.

A CMS shapes how content teams work, how developers build, how much you'll pay years from now, and how easy it will be to change course when a product outgrows its original assumptions.

Read article

Integrations

Every system the store orchestrates is a risk surface. The ERP, the system of record for stock, pricing and commercial conditions, has to agree with the store at all times; the CRM holds order and customer history; marketing automation wants clean data; and carriers, invoicing and picking all need to know what happens next. Most of this stays invisible until it fails, and it fails in expensive ways: stock that oversells because the sync runs hourly, a campaign that fires on stale data, an order that stalls between two systems while the customer refreshes the tracking page. Knowing where these failures tend to hide is what lets a plan decide, before anything is built, which risks the business can live with and which it cannot. Integration priorities follow business impact first and technical convenience second, which sounds obvious, and yet is routinely ignored.

Markets and geographies

Most stores go international the hard way: one market at a time, each new country patched onto a platform designed for the first one. It works until it doesn't. Catalogues split per market, currencies multiply, every country arrives with its own tax rules and fulfilment quirks, and before long a simple price change takes three people and a spreadsheet. Hey Harper runs separate storefronts for the EU, US and UK, which means every design and platform decision has to hold across all three, and that only works because the structure was settled early. This is the sort of thing a plan decides while changing your mind still costs nothing.

Automation and AI

Every roadmap now arrives with an AI line somewhere in it, often written before anyone has decided what the technology is for, and that ordering is exactly backwards. Our position is a simple test: AI belongs in a plan when it impacts a number the business already tracks. Forecasting stock replenishment clears it easily, because the return shows up in capital freed from the warehouse, and the same goes for automating the repetitive end of customer support, where the saving is measured in hours the team gets back for other problems.

AI is also changing the other side of the equation: how customers find stores in the first place. That shift deserves its own article, so we wrote one.

How AI search is changing business recommendations.

Assistants now answer the questions your customers used to Google. Here's what that means for your business.

Learn more

Operations, people and governance

Stores fail for organisational reasons more often than technical ones. An e-commerce migration plan therefore covers the capabilities the internal team needs to develop, which decisions should stay in-house and which are better delegated to partners, and how the roadmap will be governed so it survives contact with a busy year. Operational load belongs in this conversation too, because a small team burning hours on manual work has no capacity left for growth. When we rebuilt mishmash's store, part of the brief was precisely that: content management moved to a block-based setup the team now runs without developers, and invoicing became automated, freeing their time for more impactful work.

Measurement

The plan decides how the business will measure itself: which KPIs matter for each area, from conversion and average order value to load times and uptime, which tools provide them, and how the store gets instrumented from day one so the data exists when a decision needs it. Instrumentation is the easy half; the harder one is building the habit of letting those numbers settle arguments, and it's the half that changes how a business runs. When Hey Harper's rebuild went live behind a two-week A/B test against the old store, it was their Product Manager who called time on it:

That is a measurement culture doing its job: a number, read early, ending a conversation that would otherwise have run for weeks.

How we work

An e-commerce migration plan comes together in two stages.

The first is an immersion workshop: a few days on site with the client's teams, working through the operation one group at a time. We start with leadership on ambition and priority markets, then sit with the commercial and logistics teams to document how orders flow and where the manual workarounds live, before auditing the technical stack with IT and gathering what each department needs the future platform to do. Sessions run sequentially, a few hours per group, so nobody loses precious time. The result is a shared, documented picture of the operation, and alignment on where to start.

The second stage is the plan definition. Over the following weeks we turn those findings into the transformation plan itself: projects sequenced by dependency and priority, each with effort and investment estimated, and quick wins separated from the foundational work that has to come first. The same document sets decision criteria for the technology and vendor choices ahead, so those conversations start from agreed ground. This happens remotely, with regular check-ins along the way, because the plan has to reflect the reality of the business, beyond what we previously observed.

The final deliverable is a strategic document: an executive presentation backed by technical annexes with detail per area. It belongs to the client and can be executed by anyone, including teams that are not us. Our expectation is that the process builds enough confidence to carry on together into execution. The plan doesn't depend on it; it stands on its own, whoever builds what it describes.

How we redesigned our design process with AI prototyping.

Our design process, reshaped from the first week onwards.

Learn more

The economics of clarity

A rebuild is a meaningful investment, and the honest way to judge it is against what the current store costs in lost conversion and in ideas that don’t get a chance to be implemented. Hey Harper's rebuild generated around €3 million in additional revenue, comparing March 2024 to March 2023 and repaid itself within the first month; the mishmash rebuild took four, alongside a 34% lift in conversion and sales that more than doubled year on year.

We're wary of promising numbers like these as a baseline. However, they prove that when a platform is visibly limiting the user experience, even a conservative improvement in usability (and therefore conversion) is worth a multiple of the project's cost every year, and the e-commerce transformation plan, a fraction of that cost again, is what stops the larger investment being aimed at the wrong problem.

Which brings us back to this: the businesses that ask us about a platform migration are usually right that something has to change; what exactly, and in what order, is the part worth slowing down for. A rebuild succeeds in the order it happens, from clarity about where the business is going, to a plan for what its systems must support, and only then to the technology framework itself. Get that order right and choosing which platform to build upon becomes one of the easier decisions on the roadmap.