Before you change platforms, ask better questions.

Name the problem the platform must solve

A migration is a response to a business need. Begin by describing that need without naming a platform. Is the current store hard to merchandise? Are integrations unreliable? Is the customer journey limited by architecture, or by decisions that could change within the current system?

Map what the business depends on

List the catalogue structure, content, URLs, payment methods, customer records and operational systems that need to survive the move. Identify the owner of each source of truth. The migration plan should explain what transfers directly, what needs transformation and what cannot be carried across.

Treat discovery as a deliverable

Ask for a documented view of requirements, risks, integration boundaries and acceptance criteria. This gives the team a way to compare implementation approaches and surface dependencies before they become late-stage surprises.

Rehearse the trading journey

Test realistic orders, not just page appearance. Cover product availability, discounts, fulfilment events, customer notifications and returns workflows where they are in scope. Agree how problems will be escalated and who decides whether launch can proceed.

Define what happens after launch

A launch plan needs ownership after the switch. Establish monitoring, a redirect review, a way to report operational problems and a prioritised backlog. Compare outcomes against a known baseline while accounting for changes in traffic, stock and seasonality.

A practical next step

Choose one part of your store and define the question you want to answer. The VIA77 Commerce Review provides a structured starting point for that conversation.