PrestaShop Solutions

Most PrestaShop work that lands on our desk falls into three buckets. The first is a 1.7 store that has stopped getting security updates and the merchant has finally been told by their hosting provider that the PHP version it runs on is end-of-life. They need to migrate to 8.x, but the previous developer left 200 module overrides and a theme that hooks into smarty templates that no longer exist in the new core. We've seen this enough times that we have a checklist for it.

The second is a faceted search that has melted under a real catalog. PrestaShop's category pages are fine until you cross 5,000 products with attributes, at which point the SQL JOIN chain that builds the layered navigation starts taking three to four seconds. Sometimes the answer is to rewrite the search to use Elasticsearch or Meilisearch, sometimes it's just adding the right composite indexes and tuning prestashop.search. We benchmark before recommending which way to go.

The third is multistore configuration that's gone wrong. EU merchants who run a .lv, .lt, .ee group from one PrestaShop install often discover that VAT rules, shipping carriers, and product translations are all entangled in a way that makes an apparently small change touch six other things. We come in to untangle that, usually by separating out tax rules per shop group and fixing the inheritance order in the back office.

Most PrestaShop projects we run are 8 to 14 weeks end to end, depending on catalog size and how much theme custom work is in scope. Week one is read-only: we get database access, take a snapshot, profile the slowest pages with Xdebug, and produce a written report of what's installed, what's been overridden, and what's actually broken versus what's just slow. The report is what we work from for the rest of the project.

Weeks two through four are the foundation. If it's a 1.7 to 8.x migration we set up the new install on a staging server, run the official upgrade module against a copy of production, and start porting overrides one module at a time. If it's a performance project we're tuning MySQL, adding the missing indexes, and rebuilding the theme's twig templates to drop the calls that are doing N+1 queries on category pages.

Weeks five through ten are the build itself: custom modules, theme work, payment integrations, and whatever data the client has been promising will be ready in week three. The last two to four weeks are real-traffic testing on staging with anonymized customer accounts, then a Sunday-morning cutover with a 24-hour rollback window. We keep the old store running on a legacy. subdomain for two weeks after launch in case anything in the analytics or accounting export needs verifying against the original.