The industry benchmark for the drop in organic traffic after a store migration is 15–30% in the first three months, with recovery to the original level over the following 6–12. For a store doing several to a dozen or so million złoty in annual turnover this is not a statistic — it is a quarter or two below plan, countable in lost margin.
In our migrations the average drop is less than 3%. That difference does not come from better tools or from magic — it comes from the order in which things are done. Below we show why migrations wipe out organic traffic, and the specific SEO-first process with which we keep the loss below 3%. At the end you will find a list of questions with which to check your own vendor before you sign a contract.
Why a migration wipes out organic traffic — six mechanisms
Organic traffic does not vanish on switchover day because of an abstract "change of platform". It vanishes because of six specific, technical mechanisms. Each of them can be avoided — provided you deal with it before the implementation, not after.
1. Old URLs start returning 404
Every platform builds addresses differently. What in PrestaShop was /123-product-name.html becomes /products/product-name in Shopify. If the old address does not get a 301 redirect to the new one, it returns a 404. After a few visits Google removes it from the index, and with it goes all the historical link equity — external and internal — that the page had built up over years. This is the single biggest cause of drops.
2. The redirects exist, but they are done badly
The mere presence of a 301 is not enough. Redirect chains (301 → 301 → 200), loops, or — the classic — redirecting all old addresses to the home page instead of to the corresponding subpage. Google treats the latter as a "soft 404" and passes no equity. The redirect map has to be one-to-one: a specific old URL to a specific new one with the same intent.
3. Metadata and structured data revert to defaults
The new platform generates its own title tags, meta descriptions and H1s — usually templated. Carefully crafted titles disappear, canonicals start pointing at the wrong addresses, and schema.org (Product, Offer, BreadcrumbList, Review) is not recreated. The effect: you lose rich results in the search listings — stars, prices, availability. The position may stay the same while CTR falls, because your result suddenly looks poorer than the competition.
4. Rendering and performance change
Migrating to headless or to a single-page application often moves rendering to the client side (JavaScript). If the content is not server-side rendered, Googlebot sees an empty page on its first pass. On top of that come Core Web Vitals: a slower TTFB and LCP are a real problem — a TTFB above 500 ms correlates with a 5–10% drop in conversion, and Google indexes slower pages less often.
5. Crawl budget is wasted
After the switchover Googlebot runs into thousands of redirects, 404 pages and duplicates. With a catalogue of tens of thousands of addresses, the bot burns its crawl budget revisiting junk instead of indexing new pages. The bigger the store, the longer new addresses wait for indexing — and a page that is not indexed generates no traffic.
6. Temporary index instability
Even a perfect migration triggers 2–6 weeks of "rearranging": Google crawls, renders and assesses the pages afresh. Positions fluctuate. The biggest risk at this stage is panic — the team starts changing things mid-flight, which resets the assessment process to zero. A good process does not eliminate this phase, but it shortens it and flattens its amplitude.
SEO-first means: SEO decides first, it does not repair last
Most agencies run a migration technically first. First the store is built, the data is moved, and SEO comes in at the end — as a repair layer, once the drop is already visible in Google Search Console. In that order the redirect map is created under pressure and after the fact, and metadata and schema are "to be added when there is a spare moment".
We reverse that order. Every sprint starts with an SEO decision, and only then a technical one. The URL structure of the new store is designed before the first line of front-end code exists — not discovered after go-live. It is one change in the process, but it is the one responsible for the difference between a drop of 15–30% and a drop below 3%.
SEO-first does not mean "freeze everything exactly as it was". Sometimes the old URL structure is bad and worth improving — a flat category hierarchy, duplicate parameters, addresses with IDs instead of keywords. The difference is that in an SEO-first approach every such change is a conscious decision with an assigned redirect, not an accidental side effect of the new platform. You change what you want to change, and you know exactly where every old address leads.
If a vendor treats SEO as a stage after go-live, a drop of 15–30% is not a risk — it is written into the plan. The only question is when you will see it.
The SEO-first process step by step
Below is the real sequence — the same one for a PrestaShop → Shopify Plus migration and for rewriting legacy PHP into Symfony. The length differs, the order does not.
Step 1 — Audit and SEO baseline (week 1–2)
A full audit of the current store: URL structure, indexable pages, internal linking, schema markup, Core Web Vitals. Plus a traffic baseline from Google Search Console and Ahrefs. The outcome is a document titled "What we preserve unconditionally" — a list of the 200–500 most important addresses in terms of traffic and conversion. Without that list a migration is run blind.
Step 2 — Information architecture and URL mapping (week 2–4)
We design the structure of the new store with one-to-one mapping for all indexed pages. The key detail: every URL is validated by an SEO specialist, not only by a developer. The redirect map is created right here — before implementation — and goes into regression tests, not into a "post-launch" backlog.
Step 3 — Development with SEO tests after every sprint (week 4–18)
Iterative development with validation on staging. After each two-week sprint we run automated SEO tests: correctness of the redirect mapping, presence of schema markup, Core Web Vitals, indexability. Plus a manual review by an SEO specialist. A regression caught on staging in week 8 costs an hour of work; the same regression caught in production after launch costs rankings.
Step 4 — Cutover in a low-traffic window (weekend)
The production migration happens in the lowest-traffic window — typically Sunday night — with a ready rollback plan and 24/7 monitoring for the first 72 hours. The switchover takes place without interrupting sales: customers keep buying throughout the process. Deploying changes on a Friday afternoon or during a sales peak is unnecessary risk that you eliminate simply by choosing the date.
Step 5 — 90 days of post-launch monitoring (included)
After the cutover begins the phase in which most of the traffic is either won or lost. For 90 days there are weekly organic traffic reports, 404 monitoring, verification of the indexing of new pages and alerts for Core Web Vitals regressions. We have adopted a threshold: a drop above 5% in the first 30 days is fixed at no extra cost. In practice, in around 95% of our migrations no post-launch fix was needed — because the problem was solved at the design stage, not while firefighting.
Parallel run or big-bang cutover?
Switching traffic from the old system to the new one can be done in two ways, and the choice between them has a direct impact on SEO risk.
Big-bang cutover is a one-off switchover of everything in a single window. Faster, cheaper and simpler — it works well with smaller catalogues and SaaS → SaaS migrations, where the old system is predictable and well documented. The risk is then low enough that maintaining two environments in parallel is not justified.
Parallel run means the old and the new system operate side by side for a while. It lets you validate data, redirects and performance on real production traffic before you cut off the old store. It is more expensive and more complex — you have to maintain two infrastructures and synchronise data between them that changes over time: stock levels, orders, customer accounts. But with legacy systems without documentation and a catalogue counted in tens of thousands of addresses, it is the only way to catch the dependencies nobody remembers any more before they hit production.
The rule is simple: the more unknowns there are in the old system and the bigger the catalogue, the more strongly it tips towards a parallel run. A bad recommendation costs in both directions — an unnecessary parallel run in a clean SaaS migration burns budget, and a big bang where a parallel run was needed burns traffic. This is exactly the decision you want to hear justified, not defaulted.
Proof: thousands of addresses and almost all rankings preserved
The hardest scenario we run is a legacy migration. Bogart Meble ran for twelve years on custom code in PHP 5.4 — with no documentation and database queries taking several seconds each. We rewrote the store to Symfony 6.4 using the Strangler Fig pattern, module by module, in around 16 weeks.
From an SEO perspective three decisions matter:
301 mapping for all URLs — one-to-one, preserving an identical semantic structure, rather than a bulk redirect to categories.
A two-week parallel run — the old and the new system ran side by side, which made it possible to validate data and redirects on production traffic before the final switchover.
The DNS switch outside peak hours, with ranking monitoring from the first hour after the cutover.
The result: almost all Google rankings preserved, the drop in organic traffic in the first month kept below our 3% threshold, with no downtime and no lost orders. As a bonus the LCP of the product page fell from several seconds to under one second, and conversion rose noticeably after three months — because a faster page sells better, regardless of rankings.
The second example shows that changing platform is not the enemy of traffic if it is mapped properly. Topeshop migrated from PrestaShop to Shopify Plus together with a marketplace integration and recorded +58% conversion. The same principle: first move one-to-one what already works in SEO, and only then add growth.
How to check your own vendor
You do not have to be an SEO expert to judge whether a vendor is running a migration safely. A few questions are enough, plus a comparison of the answers with what an SEO-first process looks like versus a typical "technical first" migration.
StageSEO-first migration"Technical first" migration301 redirect mapCreated in week 2–4, before the front endAfter go-live, once the drop is already visibleWho validates URLsAn SEO specialist, not only a developerNobody, or a developer "along the way"SEO testsAfter every sprint, automated and manualA glance before launchCutover dateLow-traffic window, rollback plan, 72 h of monitoring"We will deploy on Friday afternoon"Ranking monitoring90 days included, alert for a regression above 5%The client notices the drop in GSC themselvesTypical traffic dropBelow 3%15–30%, recovery in 6–12 months
One question weighs the most: when is the 301 redirect map created? If the answer is "we will deal with that after go-live" or "we will generate it automatically at the end" — you have your answer, regardless of the rest of the offer.
Summary
A migration does not lose traffic because of the change of platform — it loses it because of a missing redirect map, lost metadata and performance worse than before. All three can be avoided if SEO decides first rather than repairs last. The 15–30% benchmark describes migrations run technically; a drop below 3% is achievable when the URL structure, the redirects and the monitoring are planned before implementation, not after it.
If you are planning a migration and want to know how much traffic you are really risking, start with a store audit — that is what creates the "what we preserve unconditionally" list. See also what our store migration process looks like and our specific projects, and if you have questions about your own case, write to us.