Shop migration without losing rankings: 43,943 orders, zero discrepancies
The most common fear of anyone running a working shop: „we will move it and lose our Google traffic”. That fear is justified — but not because migrations damage rankings by nature. What does the damage is everything people forget to bring along.
What actually moves
When a client says „let us move the shop”, they usually mean products and orders. That is perhaps a third of the job. A shop that has been running for a few years has built a layer of things around itself that do not look like data — and that decide whether the traffic survives the move.
In the last large migration we ran — a fuel retailer trading on three markets — we moved a complete set from production into the new architecture:
Orders and customers are the obvious part. The interesting entries are the other two, because those are what decide your position in search and the trust a visitor arrives with on a product page.
Redirects: 738 addresses nobody remembers
Every address that once served something has a history in Google. Some carry links from other sites, some sit in customers' bookmarks, some live on in old newsletters. If that address returns „not found” after the migration, the whole history is gone — not gradually, but overnight.
In this shop there were 738 of them. Not addresses of current products — those travel with the catalogue. These were leftovers from earlier rebuilds: old categories, discontinued products, addresses from a time when the shop had a different structure. Somebody once set up redirects for them and forgot, because they had worked quietly for years.
A simple test before any migration: export the list of redirects your shop has today. If the answer comes back as „do we have any?”, then you do — and nobody has counted them.
Moving those redirects is not creative work; it is a box to tick. But if it is not on the list, nobody will do it, because nothing looks missing. The shop looks fine after the move, traffic slides for three months, and everyone wonders why.
Reviews: 375 write-ups that are easy to lose
Product reviews usually live in a different table from products and migrate separately. Very often they do not migrate at all, because somebody under deadline pressure decides: „we will add reviews later, customers will write new ones”. They will not.
We moved 375 reviews along with 1,825 individual ratings, because every review in this shop scored five separate dimensions. The technical trap sat where nobody expects it: reviews needed a row linking them to the store with identifier zero. Without that row the data was in the database, but the admin panel showed an empty list — which looks exactly like data loss, even though nothing was lost.
I mention it because it is the typical shape of migration problems: nothing explodes, everything looks done, and one row is missing from a helper table.
Three countries, three currencies, one engine
This shop sells in Poland, Austria and Germany — in three currencies, with three tax rates and prices shown including tax, because its buyers are private customers. On top of that sits pricing that depends on the manufacturer and the delivery format: pallet, full truck, bulk bag.
With that structure, migration is not about copying prices across. It is about making sure that after the move the same person, arriving from the same country, sees the same price as before. That sounds trivial until you count how many places in a shop's code can modify that price.
We left the old pricing fields in the database even though the new mechanism ignores them. The reason is unglamorous: at the moment of migration somebody may have a basket half-way through checkout. Deleting the old data would break precisely the orders that are in mid-flight — the ones you least want to lose.
How to verify the migration worked
The worst moment to discover a problem is three weeks after the switch, when traffic is down and nobody knows which of fifty changes caused it. That is why verification cannot mean clicking around the shop.
Compare the whole list of addresses
Before the switch you build a list of every address the old shop answered on — from the sitemap, from the admin panel, from Google's reports. After the switch every one of them is requested by machine and the response compared. Not „does the page open”, but: does it answer the same way it did before, and if it redirects, does it land in the same place.
With 738 redirects that is a few minutes of machine time and the only way to be sure. Clicking ten random addresses gives you the illusion of control — if five per cent is broken, chances are none of those ten will catch it.
Match the totals, not just the presence of data
After the migration you compare sums: number of orders, total value, number of customers, number of reviews. Not to check whether the data is there — it almost always is. To catch the case where 43,900 of 43,943 orders came across, because forty-three had something unusual in their structure and quietly dropped out.
That difference is invisible in any admin panel. It shows up only when somebody compares two numbers from two systems. If the migration plan has no line reading „compare control totals”, nobody will do it.
The numbering your finance team will ask about
Orders and invoices carry continuous numbering, and after a migration it must not only be preserved but also continue from the right place. The classic failure: historical data moves across correctly, the counter for new documents starts at one, and the first order after the switch gets a number that already exists in the accounts.
The problem that is not about data
A separate class of migration problems has nothing to do with data and everything to do with the environment the shop runs in. Two examples from this project, both expensive to diagnose and trivial to fix:
A server in a different state from the repository. Somebody enabled a module directly on the server, a configuration file changed outside version control, and the next deployment wiped it. Since then every deployment starts by checking that the server holds nothing the repository does not.
Changes that do not take effect although they were uploaded. The shop caches compiled code and a plain restart does not clear it. The symptom is misleading: you upload a fix, check, nothing changes, so you upload it again. The answer is to delete the generated code and recompile — one step that has to live permanently in the deployment procedure, because otherwise somebody loses half a day to it every few months.
This is the argument for having the migration run by somebody who knows the specific platform from production rather than from documentation. Anybody can move the data; the difference is how long it takes to diagnose situations like these.
When to switch
Switching traffic to the new version is the one moment in this project you cannot undo painlessly. Three things worth settling first:
- What happens to orders in flight. Somebody has a basket open right now or is half-way through payment. The plan has to let those finish — which is why in this migration we left the old pricing fields in place.
- Who can still reach the old version. For the first few days the old installation should stay reachable for your team, so that something can be compared when a customer calls about a pre-migration order.
- Exactly when. Not Friday afternoon. Not in peak season. In this shop the heating season starts in late summer — switching in August would have been an expensive decision regardless of how well prepared it was.
The list worth having before you talk to a supplier
- How many redirects do you have? Not „do you”, but „how many”. The number takes minutes to export.
- Where are the reviews and in how many tables? If you score several dimensions, there is far more data than the product page suggests.
- What happens to orders in flight? That is: does the plan account for somebody having a basket open.
- Is order and invoice numbering preserved? It is a question from your accountant, but it has to be asked of the supplier, before the work starts.
- Who checks that old addresses still answer? By machine, across the whole list, not by clicking three at random.
If a supplier answers those five specifically, they have probably done this before. If the answer is „the platform handles it”, ask which part of the platform exactly, and what happens when it does not.