Organic traffic returned to its pre-migration level in 17 days
A wholesaler in the technical sector had been running PrestaShop 1.6 since 2014. It had 14,000 products in its catalogue and ten years of order history in the database. The store needed upgrading, but organic traffic accounted for 61% of sales. Moving it therefore had to take its existing visibility into account.
What had to be checked before the migration
Over the years 40 modules had been installed in the store. Seven had modified code, and three were no longer maintained by their makers. The environment ran on PHP 7.1 at the end of its support, which blocked further updates.
The client had previously talked to two agencies. Both proposed a new store and expected organic traffic to drop by around 40% in the first six months. With Google’s share of sales at that level, the loss would have been greater than the cost of the implementation.
Over a decade thousands of URLs had been created for categories, filters, manufacturers and campaigns. Some still brought in customers, even though the company no longer actively used those pages. They had to be found and accounted for in the new structure.
Inventory of URLs and modules
I spent the first two weeks on analysis, before writing any production code. I combined data from Search Console, the sitemaps and the server logs from the last twelve months. The list covered 11,800 unique URLs with at least one visit. For each one I defined a target page.
I also checked what each of the 40 modules did. 22 turned out to be unnecessary, including four that duplicated the same feature. This reduced the number of elements carried over to the new store.
Preparing the new version
For eleven weeks I prepared the store on PrestaShop 8.1 in a separate environment. I ran the migration script many times to find unusual cases in the data and check how they were handled. The last run before the switchover, on a fresh copy of production, took forty minutes.
The 301 redirect map covered all 11,800 URLs. An automated check after deployment verified the server responses, the number of redirect hops and the content of the target pages. It found 340 URLs leading to empty categories. I fixed them before submitting the new sitemap.
Results after the switchover
- The downtime needed to launch the new version was 22 minutes.
- The largest daily drop in organic traffic was 12% and occurred on the sixth day after the migration.
- After 17 days traffic returned to its pre-migration level.
- Category page generation time fell from 2.9 to 0.7 seconds.
- The store used 18 modules instead of the previous 40.
Why the preparation mattered
Understanding the old store took a large part of the work. The list of working features and URLs made it possible to plan the migration before implementation began. In this project it was precisely this preparation that helped limit the risk the earlier agencies had feared.