Changing Ecommerce Platform: Data, URLs and Go-Live Day

The first step is a list of everything the old system does. Products and categories are obvious, but the work a system does quietly is often forgotten: automated emails, tax calculations, delivery charge rules, discount logic, stock alerts and feeds to accounting.

Keep the inventory in three columns: carry over, rebuild, leave behind. Give every line an owner. Choose what to leave behind deliberately; carrying across years of accumulated features nobody uses will slow the new system from the start.

At this stage, make sure you can actually export data from the old platform. Some systems will not release certain data, such as customer passwords or the full order history. Learning that before the move changes the plan; learning it on the day causes damage.

Product data, categories, images and content pages move. Use the chance to clean up: missing descriptions, duplicate records and dead products should go before the move. Carry dirty data across and you get a dirty shop; carry clean data and the new system works well from day one.

Customer accounts and order history are the valuable but difficult part. Passwords often cannot be moved, so customers need a password reset route at first login, and announcing it by email beforehand reduces confusion. Moving customer data carries personal data responsibilities; take advice from a lawyer on this.

For order history there is a second option: rather than importing all of it, keep the old system open for a while as a read-only archive. For as long as accounting and returns need it, this is a cheap and safe solution.

• Moves: products, categories, images, content pages, customer records
• Rebuilt: payment, delivery, tax, email templates, discount rules
• Can stay in a read-only archive: old order history
• Left behind: unused plug-ins and dead products

When the platform changes, the format of product and category URLs often changes too. If each old address is not tied to its new one with a permanent redirect, you lose your place in search engines, links from other sites and your customers' bookmarks. This is the most neglected part of a migration and the most expensive to neglect.

Prepare the redirect table before the move: one column for the old address, one for the new. On the day, apply it, then check that the most visited addresses each land in the right place. To prepare the rules you can use our redirect rule generator, and to test the result our redirect checker.

Titles, descriptions and structured data should also be kept on the new site. For detail, see our article on avoiding SEO loss in a site redesign; a platform change is a redesign too.

Integrations are where a migration produces the most surprises. The payment provider, the courier, the accounting or ERP link, the marketplace feed and the email tool arrive on the new platform either as a ready connector, as custom work or not supported at all. Find out which at the decision stage; finding out after choosing the platform upsets budget and timetable.

Switching payment may need not just a technical link but a contract and approval process too. Add that time to the schedule at the start. On go-live day, placing a test order with a real payment lets you find the problem before a customer does.

For each integration, name an owner and a test: does stock fall when an order is placed, does a delivery label appear, is an invoice or accounting entry created?

Pick a calm day and hour for the switch; the middle of a campaign, a holiday or the busy season is not suitable. Freeze new product and content entry on the old system for a short while, so that one last data transfer closes the gap between the two.

First, try the new system a final time at a hidden address: product, basket, payment, order email, account login. Then point the address records at the new system, switch on the redirects and place a real order. Keep the route back to the old system open for a few days; being able to return if something goes wrong is the insurance of the move.

In the first days after go-live, watch orders, payment errors, error pages and customer messages closely. Most problems appear early, and if noticed early they are small to fix.

The commonest mistake is treating the migration as a design project. Months go on the new look while data, URLs and integrations are left to the final week. Build the timetable the other way round: data and connections first, appearance after.

The second is shutting down the old system too early. You may still need order history, invoices and return records; export everything, or keep the system read-only, before you lose access.

• Not preparing a redirect table
• Timing the switch for the busy season
• Leaving the fact that passwords cannot move until the last day
• Finding out about integration support only after choosing the platform
• Closing the old system without a test or a backup

If the problem is not the platform, moving will not solve it. A slow site usually comes from image size, too many plug-ins or server settings; weak conversion comes from the product page and checkout flow. A migration is costly and does not fix these by itself.

Wait, too, if the busy season is close, the team is small or nobody will own the move. Changing platform is a project management task and cannot be run as the side duty of an unrelated team. For the choice between a ready-made platform and custom software, see our article on that subject.