Ecommerce Replatforming: How to Keep Your Product URLs

The decision to change platforms is usually made for good reasons: the current setup no longer carries the growth, the integrations fall short, the admin burden keeps rising. We covered the variables that decision should rest on separately in our guide to choosing an ecommerce platform. Once the call is made, the project tends to run like a data migration — products are exported, the design is built, payments and shipping are connected, and the store goes live.

One item is missing from that list: addresses. The product, category and content URLs a store has accumulated over the years do not stay the same on the new platform by themselves. Every platform has its own URL pattern, and that pattern changes during the move. Any address whose counterpart has not been defined in writing quietly turns into an error page on launch day.

On a business website this work is small enough to manage by hand; in our piece on protecting rankings during a website redesign we walked through the inventory and the mapping table at that scale. On the store side the scale changes: thousands of product URLs, the category tree itself, filter URLs, sold-out products and product feeds that have to go through approval again after the move. What follows deals with a migration at that scale.

Product URLs are the first thing a migration loses

Over time a product page becomes an asset. It starts matching a query in search results, earns links from other sites, gets bookmarked by customers, is shared in emails and messages, and its listing in shopping channels is tied to that URL.

That accumulated value is written to the page's address, not to its text. Even if the same product sits on a better page in the new store, if the URL has changed, the value has not moved with it. The technical success of a migration is not measured by whether every product was transferred, but by whether every address has a defined counterpart.

It also pays to be honest about expectations. Even in a fully mapped switch, the first weeks show an uneven picture; index records are not refreshed all at once. Careful mapping shortens how deep that dip goes and how long it lasts; it does not remove it. A promise that puts a number on the recovery period presents something nobody can measure as if it had been measured.

The pre-migration inventory: five families of URLs

The inventory does not come out of a single source. A store has five families of URLs, and each one is extracted separately.

Product URLs. The live ones are not enough; products that have been unpublished but still receive visits also go on the list. This list should be pulled together with the product record, matched to its SKU.

Category URLs. Main categories, subcategories and any campaign categories built specifically for a promotion.

Filter and sort URLs. This family is not moved in full; you measure which ones actually receive visits and define a counterpart only for those.

Content URLs. Blog posts, guides, size charts, installation manuals. In stores these pages are usually forgotten, and they are often the pages with the most links from other sites.

Static and mandatory pages. The distance sales contract, return terms, delivery information, contact, about us.

These five lists are filled from four sources: the current sitemap, Search Console's performance and indexing reports, the server access logs and the list of external links pointing at the site. Once the four are merged and deduplicated, the resulting number surprises most teams.

Building the mapping table: from SKU to URL

This is the point where a store migration truly parts ways with a business website. Thousands of rows are not mapped by hand; the mapping is generated through a shared key.

That key is the SKU. From the old store you pull a "SKU → old URL" list, from the new store a "SKU → new URL" list, and the two are joined on the code. Rows that do not match are collected in a separate list; that list is where the real work is.

The precondition for this method is that SKUs are identical on both sides. If the code structure is being changed during the move, a translation table between old and new codes is built first. Treating the migration as a chance to overhaul the code structure is a common choice; its cost is an extra layer in the mapping.

Automatic matching does not work for category and content URLs; they need decisions by hand, but their number is limited to the hundreds. As on a business website, the table is kept in five columns: old URL, new URL, decision, rationale and the post-launch verification result.

A product with no counterpart: nearest category or sold-out page

The list of unmatched rows usually falls into three groups, and each group needs a different decision.

Products that were not moved to the new store but will keep being sold. These are a mistake: the transfer was left incomplete. The decision is not to redirect them but to finish the transfer first.

Products that will no longer be sold. There are two reasonable options here. If the product has a successor or a model that replaces it, the URL is redirected to that product. If it has no successor, it is redirected to the nearest category. Sending them in bulk to the home page is a poor choice in both cases: the visitor lands far from what they were looking for, and on top of that, mass redirects of this kind may not be treated as a permanent move on the index side.

Temporarily sold-out products. Their pages are kept and the stock status is stated honestly. Products that are not carried over as "currently out of stock" during the migration start from zero when they come back.

Sales volume should not be the only criterion when deciding. A page that sells little but earns external links, gets searched for often or is the one your support team keeps pointing customers to is worth moving.

If the category tree changes: one-to-many mapping

A migration is often seen as a chance to fix the category tree too, and that is reasonable. But making both changes at once stops the mapping from being one-to-one.

Three situations come up. A split: an old category has been divided in two in the new structure; the old URL is redirected to whichever of the two new ones is chosen as the primary counterpart. A merge: two old categories have become a single new one; both URLs go to the same target. A change in depth: the category has moved one level up or down; the URL changes, the content stays the same.

Every one of these decisions should be recorded with a written rationale. Six months later, when someone asks why a category was removed, that table is the only place that holds the answer.

One warning: changing the category tree at the same time as the migration makes it harder to tell where a drop in the following four weeks is coming from. If the scale is large, postponing the tree to a quiet period after the migration keeps the observation down to a single variable.

Moving order history, customer accounts and reviews

There is a group of data that is less visible than the URLs but felt more strongly on the customer side.

Order history. Customers expect to be able to see their past orders; returns and warranty processes also depend on it. If it cannot be moved, read-only access to the old system should at least be kept for a defined period.

Customer accounts. Accounts can be moved, but passwords usually cannot; this is a technical constraint. In that case customers should be told in advance, and clearly, that they will need to set a new password. When that notice is skipped, support load and the number of abandoned carts rise noticeably in the first days.

Product reviews. Reviews are a source both for shoppers and for automated systems that gather information about a product, and they build up over the years. If they can be moved, they should be; if not, they should at least be archived and stored together with the SKU of the product they belong to.

The personal data side. Every customer record that is moved is an act of personal data processing; which data is moved, where it is stored and when the copy in the old system will be deleted should be agreed in writing.

Launch day: an ordered checklist

The order of the checks is not arbitrary; if one of the early steps is skipped, the results of the later ones cannot be trusted.

1. Is it up. Does the domain point to the new store, is the certificate clean, and does only one of www and the bare domain behave as the primary address.

2. Is the door open. Is there a crawl block left over from the staging environment, has a tag that keeps templates out of the index been forgotten. The single forgotten line that costs a migration project the most hides here, and checking for it takes seconds.

3. URLs. Every old URL in the mapping table is requested; rows that do not reach a permanent redirect in a single hop are flagged, and two-step ones are flattened.

4. Purchasing. A real order is tested end to end: cart, shipping cost calculation, payment, confirmation email, invoice. The same test should be run separately as a guest checkout and with an account; the two flows can break in different places.

5. Counters. Is the analytics code running, is each checkout step being recorded as an event, have the goal definitions been refreshed for the new URL pattern.

6. Notification. The new sitemap is submitted to Search Console last. Opening a half-finished store to crawling delays the point at which its corrected version gets back in the queue.

Why product feeds go back through approval after a migration

This is the most frequently skipped consequence of a migration. Product listings in shopping channels and on marketplaces are tied to product URLs. When the URL changes, the channel has to evaluate those listings again.

Three things happen at once. The product links in the feed change; the channel checks the new URLs; and during that check, mismatches that had never been seen before can surface — because the new page template produces the price, the stock or the structured data differently.

The practical consequence is this: a rise in the number of disapproved products should be expected in the days after the move, and it should be written into the schedule as a planned work item. We went through the disapproval families and the order of fixes one by one in our article on disapproval reasons in product feeds.

Do not forget that image URLs change too. If images are served from a new address and the old addresses have been shut down, the channel cannot download the images and produces disapprovals.

The first four weeks: checking drops by URL and by product

Tracking a single indicator after the switch is misleading. Total visits or total revenue tell you that something has broken, but not what.

What you read is two breakdowns. By URL: from Search Console's performance report, you pull the URL lists for the periods before and after the migration and join them with the mapping table. Rows where neither the old nor the new URL appears in the list are examined; there is a break there.

By product: on the channel and marketplace side, you compare which products are live against the list from before the migration. This breakdown surfaces feed problems that do not show up on the URL side.

There is a third check as well: the server error logs. URLs producing error pages after the migration collect here, and old URLs the inventory never saw often turn up on this list. Looking at it regularly through the first four weeks is the fastest way to close the gaps in the inventory.

Two situations where postponing the migration is cheaper

Not every migration has to happen on the date it was planned for. In two situations, waiting is easier to defend.

If you are in the middle of your season. Migrating during the period when sales peak pushes both the cost of an error and the pressure to fix it to their highest point. When the same work is done in a quiet period, a mistake is an incident that can be fixed; in a busy period it is a loss.

If the catalog is disorganized. If there are duplicate product records, empty SKUs, undefined main categories and attributes buried in description text, that disorder is carried into the new store as it is, and fixing it there costs more. Tidying the catalog on the old platform and migrating afterwards reduces the total work in most cases.

Which tasks the migration covers on the setup side and which decisions stay with the business are written down on our store setup and migration service page; for sector-level visibility work, see our GEO solutions page for ecommerce. If you would like to map out your pre-migration URL inventory together, get in touch through our contact page.

Frequently Asked Questions

Do sales stop during the migration?

A planned switch does not require a full stop, but a short cutover window should be allowed for. The common practice is to get the new store fully ready at a separate address, run the end-to-end order tests there, and open only a short window at the moment of switching. How open orders, the connection with the payment provider and the shipping integration will behave in that window is decided in advance. The practical choice that keeps the risk lowest is to schedule the switch for the lowest-selling hour of the week and the day.

Do we have to map thousands of products by hand?

No; the only rows handled by hand are the ones that need a decision. Most product URLs are mapped automatically through the SKU: you pull a "SKU → old URL" list from the old store and a "SKU → new URL" list from the new one, and join the two lists on the code. The rows that need a manual decision are those whose code does not match, plus category and content URLs; their number usually stays within the hundreds. The precondition for this method is that SKUs are the same on both sides; if the code structure changes, a translation table is built first.

Can product reviews be moved to the new store?

In most cases they can, but how they are moved depends on where the reviews are stored. If the reviews live inside the store software itself, they are exported and imported into the new setup; if a separate review service is used, the move happens on that service's side and the product mapping is again done through the SKU. The point to watch is that each review is attached to the right product: a bulk import without SKU mapping leads to reviews appearing on the wrong products. For reviews that cannot be moved, keeping the old records and archiving them out of customers' view at least leaves a backup.

What happens if both the platform and the domain change at the same time?

You are moving two variables at once, and when something goes wrong it becomes unclear which of them caused it. The technical work follows the same logic; the difference is this: the redirect rules now live on the side where the old domain sits, so that domain's registration should not be allowed to lapse for a long time. A separate property is verified in Search Console for the new domain, and the change-of-address notice the platform offers is used. On the store side there is one more item: the payment provider, the shipping integration and the shopping channel accounts hold settings tied to the domain; all of them must be updated for the new domain, otherwise the order flow breaks the day after the move.

How long does it take to get back to previous performance after a migration?

It is not possible to give a timeline; anyone who does is talking as if they had measured something nobody can measure. Four things determine the outcome: the size of the catalog, how much the URL pattern has changed, how often the store is crawled and how completely the mapping table has been filled in. Rather than an estimate, it is more useful to track three indicators — the number of rows in the mapping table whose counterpart is still empty, the number of URLs landing in the server error logs, and the number of products going live again in shopping channels. These three point the direction weeks before the total revenue figure does.