Ecommerce Replatforming Plan: Phase by Phase

An ecommerce replatforming plan is not a calendar. It is six phases, and each one has a single thing it must prove before the next begins. That is the whole trick: a phase ends when its evidence exists, not when its dates run out. Plans built on dates alone slip in the same place every time — the build starts because the schedule says so, on data that was never reconciled, and the cost surfaces two months later as rework. Below is the plan we work to on migrations, the gate that closes each phase, and the ones teams quietly skip.

What a replatforming plan is actually for

Most replatforming plans are schedules wearing a plan’s clothes: a list of workstreams with start and end dates. That is useful for resourcing and useless for control, because a schedule cannot tell you whether the work underneath it is sound. Replatforming touches the catalogue, the customer records, the order history, the URL structure and every integration hanging off the old system at once — so the real risk is not that a task runs late. It is that a task finishes wrong, and nobody notices until the dependent work is already built on top of it.

A plan’s job is to make “finished wrong” visible early. You do that by defining, for each phase, one piece of evidence that has to exist before anyone moves on. If you have already made the decision to move — the signs it’s time to replatform cover that part — this is the next document you need.

The six phases of an ecommerce replatforming plan

The phases below are sequential in their gates, not in their work. Several workstreams run concurrently inside them. What is strictly sequential is the evidence.

1. Discovery and inventory

Gate: a signed-off inventory — every indexed URL, every product and variant, every integration, and every piece of custom logic the current store depends on.

This is the phase teams compress most often, because it produces no visible progress. It is also the phase that decides whether your estimate is real. The inventory has to be exhaustive rather than representative: the tax rule that applies to one region only, the wholesale price list nobody documented, the CSV feed a fulfilment partner has been quietly consuming for years. None of those are hard to rebuild. All of them are expensive to discover in week nine.

2. Scope and platform decision

Gate: a written list of what you are not rebuilding.

Every migration inherits features that exist only because the old platform made them necessary, or because someone built them once and nobody has used them since. If you do not name those explicitly, they stay in scope by default and the old store becomes the specification. Write the exclusions down, have them agreed by the people who would miss them, and the build finally has a finish line. If the platform choice itself is still open, our platform fit quiz is a faster starting point than another comparison spreadsheet.

3. Data mapping and dry run

Gate: a trial import whose counts reconcile against the source.

Mapping is a design exercise before it is a technical one — deciding what each legacy field becomes on the new platform, and what happens to records that do not fit the destination’s model at all. Then you run the import for real, into a staging store, and count: products, variants, customers, orders, and the relationships between them. Reconciling means you can account for every difference, not that the numbers match. Some records legitimately will not carry across, and our breakdown of what doesn’t transfer in an e-commerce data migration covers the usual suspects. What you cannot have is a difference nobody can explain.

4. Build and integration

Gate: the storefront runs on real migrated data.

A demo built on seed products always looks good, because seed products are tidy. Real catalogues have descriptions that run for two thousand words, products with one image and forty variants, and titles that break a card layout on the second line. Wiring the build to the imported dataset early is the cheapest quality control available: it converts a whole class of bugs from launch-week emergencies into ordinary build tickets. Integrations get the same treatment — connect to real sandbox endpoints for payments, shipping and ERP rather than mocking them, so that the mismatch in field formats surfaces now rather than on the first live order.

5. QA, SEO and redirect sign-off

Gate: every indexed URL resolves, and someone outside the build team completes a real order end to end.

Two separate proofs, deliberately paired, because they fail for the same reason: people test the paths they built. Take the URL inventory from phase one and confirm that each entry either lands on a live equivalent or is being retired on purpose — the mechanics are in our guide to 301 redirects and migrating without losing SEO. Then hand the staging store to someone in customer service or operations and have them buy something, get it fulfilled, and get it refunded. They will use the store the way customers do, which is to say not the way it was designed.

6. Cutover and stabilisation

Gate: order-flow parity confirmed while rollback is still available.

Cutover is a sequence, not a switch: freeze content, run the final delta import, move DNS, verify, and keep the old environment warm until you are certain. The plan for that particular hour deserves its own document, and we set one out in the cutover plan. What the replatforming plan owns is the phase after it — the first weeks, when orders should be flowing on the new platform in the same shape as before and search engines are re-crawling the new URLs. Stabilisation is a phase with a gate, not a period of hoping. Until parity is confirmed, the project is not finished, and the rollback path stays open.

The gates teams skip, and what skipping costs

Nobody removes a gate deliberately. It goes missing under deadline pressure, in the form of a reasonable-sounding sentence — “we’ll catch the edge cases as we build”, “let’s import properly on the night”. The pattern is consistent enough to tabulate.

Read down the last column and the pattern is clear: skipping a gate never saves the time it appears to save. It moves the work to a later phase, where it costs more and has an audience.

What runs in parallel

Sequential gates do not mean sequential work, and a plan that runs five workstreams end to end will take far longer than it needs to. Data mapping can start the moment discovery has an inventory. Content and merchandising can be prepared while the build is under way. Redirect mapping should begin early, because it is derived from the same URL inventory phase one produced — leaving it until QA is what turns it into a rush job.

The one thing that should not overlap is QA and cutover. Compressing those two together is how a migration that went well for three months becomes a bad launch week.

Turning the plan into a checklist you can run

A plan at this altitude is a control structure, not a task list — you still need the granular version underneath it. Our Shopify migration checklist is the working document that sits beneath these phases, and if you want to see how the phases map onto an engagement, what ecommerce replatforming services include sets out the same structure from the delivery side.

However you record it, keep one rule: each phase names its evidence before the phase starts, not after. A gate defined retroactively is not a gate — it is a description of whatever happened to get done.

Frequently asked questions

How long should a replatforming plan take?

It is set by catalogue complexity and integration count far more than by store size, so any number quoted before discovery is a guess. That is precisely why the plan is built on gates: the duration is an output of the evidence you need to produce, not an input you commit to first. What you can decide up front is the order and the exit criteria.

Can we skip a phase to hit a deadline?

You can compress a phase, and often should. You cannot skip its evidence and still call the phase complete, because the next phase is built on the assumption that the evidence exists. If a date is immovable, cut scope in phase two — that is what the exclusions list is for. Cutting evidence instead just relocates the delay to launch week.

Who should own the plan on the client side?

Someone with the authority to approve the exclusions list. Most stalled migrations stall at phase two, because the only person who can say “no, we are not rebuilding that” is not in the room. Technical ownership can sit with the agency; the decision about what the business is prepared to lose cannot.

The short version

Six phases, six pieces of evidence. Inventory before scope, scope before mapping, a reconciled dry run before the build, real data before QA, and parity before you let go of the rollback. Replatforming projects rarely fail because a phase was hard. They fail because a phase was declared finished without anyone agreeing what finished meant.