Replatforming an online store

Replatforming an existing store moves its selling operation and its pages. Define what must work when the new platform opens: customers must find and buy the intended products; staff must identify payments, fulfil orders and find earlier purchases. Plan data transfer, URL changes, cutover and recovery around those outcomes.

Set the opening requirements

Record why the current platform is being replaced and which requirements the proposed one must meet. Keep visual preferences separate from anything that affects whether an order can be accepted or supplied.

Choose representative cases from the existing store: a simple item, a stocked variant, an unavailable item, an order needing correction and a customer asking about an earlier purchase. For each, write down the expected customer view, staff action and resulting record. Use the AUD prices and Australian delivery areas the business intends to support.

Replatforming readiness checklist

Align stakeholders on operating assumptions

Confirm with the teams that run the store how each function will operate after the move and who owns it. Yotpo’s replatforming guidance recommends aligning stakeholders, resolving questions and setting expectations before work begins.

List business functions that depend on the current platform, including accounting and customer service. The Maze Group’s Martina England notes that organisations may have built these functions around how their previous ecommerce platform operated, so confirm how they will work after the move.

Plan each data transfer

Products, inventory, images, customer profiles and order history may each need a different export and import route. Tools differ in the record types they cover, so confirm the routes available at both ends of the proposed move rather than assuming they are equivalent.

Decide which history needs to appear in the new admin and which can remain in a controlled, searchable archive. Preserve a way to match old and new identifiers so that a past purchase can still be traced to its source record. The detailed field mapping and test-import steps belong to the supporting article on data transfer.

Plan old pages and new destinations

Plan how the move will handle changed URLs so customers and search engines can reach the appropriate pages. Detailed URL planning and redirect tasks belong to the supporting article on URL changes.

Sequence changes to limit uncertainty

Avoid combining the platform move with unrelated changes where possible. Google recommends making site changes one at a time; if a new domain, content management system and layout are all planned, separate those changes so their effects can be assessed.

For a large site, Google suggests considering a move of a technically separable section first, then using its traffic and search-indexing effects to inform the wider move. Choose a section that changes infrequently and is not strongly affected by unpredictable events. A trial section can reveal issues, but may not represent the entire move.

Rehearse the cutover

Set an order intake boundary: identify which system may accept new orders, when the final source export will occur and how orders created during the change will be found. Name the people who can change routing, monitor payments and orders, and pause a faulty selling path.

Run the agreed customer and staff cases in the proposed configuration, including an unsuccessful payment, a delivery exception and an order correction or refund. Record the expected and observed results.

Google advises testing a new site and its redirects, then monitoring old and new URLs. Search visibility can fluctuate during recrawling, so a short-term ranking change alone is a poor rollback trigger.

Choose a cutover window

If the store has predictable quiet periods, schedule the move when traffic is lower, such as a recurring weekday dip or a seasonal lull. Google says this can reduce the number of people affected if problems arise and leave more server resources available for Googlebot.

Use the window to carry out the agreed cutover checks, not to introduce extra changes. Confirm that the people responsible for routing, orders and payments are available throughout the move, and that the decision owner can act if an essential selling path fails.

Decide when to open or recover

Open only the product, checkout and delivery paths whose essential cases have acceptable results and owners. For the first live orders, compare the commerce order with payment and fulfilment records. If an essential path fails, decide whether to pause that path, repair the new store or return traffic to the old one.

Returning traffic is viable only if the old store can still take the intended orders and the team can account for orders already accepted on the new platform. Record those conditions before cutover.