Replatforming an Online Store Without Losing SEO or Orders

Ecommerce replatforming fails in three predictable ways. Search traffic drops because old addresses lead nowhere. Customers cannot log in or find their order history. Orders placed during the switch end up on the wrong system, or on neither. All three are planning failures, and all three are avoidable.

This is the sequence we follow when a retailer moves from one store platform to another: decide what moves, map the addresses, deal with accounts and payments, rehearse, then cut over inside a short freeze. It applies whichever platforms are at each end.

List what has to move, and what cannot

Start with an inventory of the data, because a few items on it cannot be copied and need a different plan.

Data	Does it move?	What to watch
Products, variants, images	Yes	Attribute names rarely match between platforms. Use the SKU as the key and check variant counts
Categories or collections	Yes	The address structure will differ, which feeds the redirect map
Customers and addresses	Yes	Passwords usually do not come along
Order history	Usually	Status names, tax lines and refunds need mapping. Decide whether order numbers are kept
Reviews	Often	Keep the original dates, ratings and product links
Gift cards and store credit	Sometimes	These are balances you owe customers. Reconcile them to the cent
Saved cards and subscriptions	Depends on the payment processor	See the payments section below
Pages, blog posts, existing redirects	Yes	Internal links inside the content point at old addresses

Do not forget the redirects the old store already has. Addresses that were retired three years ago may still be linked from other sites, and those rules need to exist on the new platform too.

Map every address before you build

Search engines know your store as a set of URLs. Most platforms impose their own patterns, so a product at /product/canvas-weekender/ may have to live at /products/canvas-weekender. Every old address needs a new home.

1. Collect the old addresses from three sources: a full crawl of the site, the pages that receive search traffic according to Search Console and analytics, and the pages other sites link to.
2. Build a mapping sheet with one row per old address and its closest new equivalent. A discontinued product goes to its replacement or its category.
3. Use permanent, server-side redirects (301) that go straight to the final address with no intermediate hops.
4. Do not send everything to the home page. Search engines treat a redirect to an unrelated page much like a missing page.
5. Carry over titles, meta descriptions, canonical tags and structured data, and update internal links so they do not rely on redirects.

On a server you control, the rules look like this in Apache:

Redirect 301 /product/canvas-weekender/ /products/canvas-weekender
RedirectMatch 301 ^/product-category/(.+)/$ /collections/$1

Hosted platforms have a redirect tool in the admin, and most accept the whole list as a file import. Google's guidance on site moves with URL changes recommends keeping redirects for at least a year, and warns that rankings can fluctuate for a while even when everything is done correctly. Our website migration SEO checklist goes further into tracking and content.

Customer accounts move, passwords usually do not

Platforms store passwords as one-way hashes, each in its own format. The new platform cannot read the old hashes back into passwords, and hosted platforms generally will not accept imported hashes at all. You have three options:

• Invite customers to set a new password. This is the standard route on hosted platforms. Warn customers in an email from the old store first, so the message from the new one does not look like phishing.
• Import the hashes and upgrade on first login. On a platform you control, such as WooCommerce or a custom build, a developer can make the login accept the old hash format once and then store the password in the new format.
• Offer sign-in by emailed link, which sidesteps the problem for customers who order twice a year.

Whichever you choose, order history has to be attached to the migrated account, or customer service will spend launch week looking up orders by hand.

Saved cards and subscriptions depend on the payment processor

Card details are held by the payment processor, not by either store. Each store keeps tokens that only mean something to that processor account.

If you keep the same processor and account, the tokens can often be reused. The work is mapping each customer on the new platform to the existing customer record at the processor.

If you change processor, the card data has to travel between the two processors directly. You request the transfer, the old processor sends the data securely to the new one, and you receive a file that maps old references to new ones. Stripe documents its side of this in its payment data migration guide. It can take from days to weeks, so start early. Never export or handle card numbers yourself, and ask both processors what your obligations are during the transfer.

For subscriptions, move the next payment date and amount with each one, and switch renewals off on the old platform before they are live on the new one. Two systems that can both bill the same customer is the most expensive mistake in this whole project.

Rehearse with real data

Run the complete import into a staging copy of the new store at least once before launch. Then check it like an accountant:

• Counts of products, variants, customers and orders match the source.
• Revenue per month matches for the last year or two.
• A sample of orders opens correctly, including one with a refund, one with a discount and one shipped abroad.
• Checkout, tax, shipping rates and order emails work for each payment method.
• Every connected system has been pointed at staging and tested: stock, accounting, email marketing, product feeds, analytics.
• A crawler has run the whole redirect list against staging and found no errors or chains.

Time the import. That number decides how long the freeze has to be.

Freeze, cut over, verify

1. A few days ahead, lower the DNS record's time to live so the switch takes effect quickly.
2. Announce a freeze on product and content edits in the old store from the final import until launch.
3. At the quietest hour, close the old checkout with a maintenance notice so no new orders land there.
4. Import the difference since the rehearsal: new orders, new customers, stock changes.
5. Point the domain at the new store and confirm the certificate and the redirects are live.
6. Place a real order with each payment method, then refund one.
7. Update the webhook addresses at the payment processor, the product feed addresses and the analytics tags.
8. Submit the new sitemap in Search Console.
9. Keep the old store reachable at a private address, read-only, for a few months of lookups.

Watch the first weeks closely

Read the 404 log every day for the first two weeks and add a redirect for each real address that appears. In Search Console, follow how quickly the new pages are indexed and whether crawl errors climb. Compare orders and sessions by channel with the same weekdays before the move. Do not cancel the old hosting until a full billing cycle, a returns cycle and a month-end have passed without anyone needing it.

Running it yourself, or with a migration team

A small catalog moving between two mainstream platforms can be handled in-house with the platforms' own import tools and a careful redirect sheet. Bring in help when there are subscriptions or saved cards, an ERP or warehouse system in the loop, tens of thousands of addresses to map, or order history that has to stay queryable. That combination is common in the eCommerce and retail projects we take on, and it is the core of our migration and modernization service. If the destination is still undecided, compare the options in WooCommerce, Shopify or a custom build. When it is WordPress, the work is a WordPress migration with a store attached.

Frequently asked questions

Will replatforming hurt my search rankings?

Some movement in the first weeks is normal while search engines process the new addresses. Lasting losses come from missing redirects, dropped content or a slower site. A complete redirect map and unchanged page content are the best protection.

Should we redesign the store at the same time?

Keep the two apart if you can. When layout, content and platform all change at once and sales dip, you cannot tell which change caused it. Launch on the new platform with the familiar structure, then redesign in steps.

Can we keep our existing order numbers?

Often, yes, but check early. Some platforms assign their own numbering and store the old number as a reference field. What matters is that customers and staff can still find an order by the number printed on the original invoice.

How long should the old store stay online after the move?

Keep a private, read-only copy for a few months. It answers disputes about old orders, supplies anything the import missed and gives you a reference when a redirect is questioned. Take a final full backup before you shut it down.