Store relaunch: how to manage the live switchover

The new store has passed acceptance, but orders continue arriving in the old one. This is where the actual switchover begins. A live store relaunch needs a procedure that accounts for changing data. Otherwise, the imported dataset may be outdated before the new system becomes public.

What must be agreed before launch?

Before the date, we establish who approves publication, who performs technical steps and who checks orders afterwards. Each critical step needs an expected result. A calendar appointment does not assign those responsibilities.

Choose a window that fits both trading patterns and team availability. A quiet sales period offers little benefit if the payment provider, ERP partner or responsible staff cannot be reached. Allow time for observation afterwards. Support does not end when the address switches over.

How do final changes reach the new store?

A trial migration and the final dataset are different things. Orders, stock, accounts and potentially product information change between them. Agree which changes will be transferred, their source and the point at which transfer ends.

A short order pause or a prepared synchronisation process are possible approaches. Suitability depends on the store, data model and integrations. We would not promise an uninterrupted move before testing that process. The essential point is that each order has an unambiguous processing system.

What belongs in the go-live procedure?

Six checks make launch approval concrete:

• Data: record the time and scope of the final transfer.
• Orders: identify the system responsible for new transactions.
• Payment: verify payment status and association with an agreed test.
• Fulfilment: confirm that a test order reaches the intended workflow.
• Access: check important product pages and existing entry URLs.
• Decision: name the person authorised to approve, stop or postpone.

Each item needs an owner. Record failures with a specific case and business effect. A missing decorative detail differs from duplicate orders or incorrect prices. Agree that distinction before launch, rather than debating it during an incident.

Why is a backup not a complete fallback plan?

PrestaShop’s backup documentation provides a technical foundation for restoration. Business continuity introduces another question: what happens to orders already received by the new store?

Simply restoring the previous state can overlook those transactions. We therefore define how new orders, payments and stock changes will be preserved and reconciled before returning. Test the fallback and estimate its duration. Possessing a backup file does not prove that trading can resume in a controlled way.

What should merchants check immediately afterwards?

Follow a complete order journey: selection, basket, payment, confirmation and processing. Do not stop at the homepage. Confirm that staff can locate new orders and answer familiar support questions.

A possible stop condition is that paid orders fail to reach the ERP reliably. A display issue without an effect on selection or ordering might be addressed afterwards, depending on its extent. The responsible team decides against agreed criteria; a general guide cannot replace that business judgement.

How can sjmedia support the transition?

In PrestaShop projects, we plan data, storefront and connected workflows together. We value PrestaShop because the transition can be tailored to the particular installation and merchant processes. This creates the conditions for targeted implementation; testing remains essential.

SEO preparation is a separate part of the project. After launch, visibility monitoring complements operational checks. When speaking with us, start with the existing systems, important order journeys and possible launch windows. These provide the basis for a realistic procedure rather than an improvised launch day.