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.

Artykuł Migrating a B2B wholesaler from PrestaShop 1.6 to 8 pochodzi z serwisu eCommerce Expert.

Why the manual test didn’t catch the error

I spent the first hour backing up the database and files, and the second comparing logs from three weeks. The problem affected one payment method, chosen by 78% of customers.

On Sunday night the payment module had updated itself automatically. The new version changed the format of the gateway’s response. The store didn’t recognise the confirmation and left the order with the status “awaiting payment”, even though the operator had taken the money.

The client had tested purchases using a traditional bank transfer. That method worked, so the test didn’t reveal the failure. The whole diagnosis took four hours.

The fix and handling orders in progress

Over the next two hours I added support for the new format while keeping compatibility with the old one. This let the store correctly process earlier orders as well. I recovered 214 orders that had been stuck for three days. Customers received a message, including those who had already bought the products in another store.

Why the report only came after three days

The store had monitoring for page availability, response time and disk space. It did not, however, track the number of orders. The site stayed available, so the working alerts didn’t signal any problem with sales.

I added an SMS alert comparing the number of orders over two hours with the average for the same time window over the previous four weeks. The alert fires when orders drop below 30% of that average. Setting up the monitoring took a day of work. The cost of three days of downtime was more than a hundred times higher.

What changed after the intervention

• The checkout process was working correctly six hours after the report.
• I recovered 214 orders held up by the payment error.
• Automatic module updates were replaced with a procedure for checking changes on a copy of the store.
• Monitoring now covers a drop in the number of orders, not just site availability.

Artykuł Payment failure after a module update pochodzi z serwisu eCommerce Expert.

The PrestaShop store had three B2B price list modules, bought at different times from different vendors. Each implemented part of the pricing rules but ignored what the others did. The price in the cart could differ from the amount on the invoice. Explaining a single discrepancy took a salesperson half a day.

Analysis before buying another module

The client wanted a quote for a fourth module that would combine the three existing ones. I proposed two weeks of diagnosis first. The description of the problem suggested that the whole way prices were calculated needed to be examined.

The analysis showed that the price depended on four variables: the customer, the product, previous purchases and the account balance. The modules applied these rules independently, working around the limitations of the store’s data model. Combining them did not produce a consistent result.

Comparing three solutions

I prepared three options with their cost, risk and expected payback period:

• A fourth module meant the smallest outlay, but I estimated its useful life at about a year.
• Rewriting the pricing rules inside PrestaShop required a bigger investment and maintaining a custom workaround of the architecture.
• A separate pricing service followed by a platform change was the most expensive, but it removed the source of the discrepancies.

We added the annual cost of salespeople’s time and held-up orders to the comparison. It exceeded the difference between the options. Once that amount was taken into account, the client decided to extract pricing and migrate later.

Prices first, then the whole store

In the first stage I moved price calculation into a service with an API. The existing store fetched the result over HTTP. This stage took eight weeks and solved the most urgent problem while keeping sales running.

Ultimately the store was moved to Sylius, where the pricing rules could be described directly in the domain model. The implementation took another five months. The switchover happened after six months of history showing the pricing service running without discrepancies.

Results after a year

• The number of differences between the cart price and the invoice fell from a dozen or so a month to zero.
• Adding a discount rule took one day instead of two or three weeks of waiting for the module vendor.
• File-based orders were handled directly by the store, without an external module.
• Tests covered 94% of the pricing logic, whose errors directly affected billing.

Why this scope was justified

The decision came down to the scale of the problem and the cost of dealing with it every day. With thirty customers I would have recommended staying on PrestaShop and cleaning up the modules. With 380, the cost comparison justified the change. A migration is worth considering once you have checked whether a cheaper solution would achieve the goal.

Artykuł B2B price lists for 380 customers: changing how prices are calculated pochodzi z serwisu eCommerce Expert.