PrestaShop to WooCommerce : why I migrated my entire fleet

Wednesday 22 April 2026.

The point of no return

If you read my analysis of PrestaShop 8’s botched modernization, you know the engine is sputtering. Today, I’ll explain why I decided to switch cars.

The trigger wasn’t a catastrophic bug or a module incompatibility that crashed a store in the middle of Black Friday. No. The breaking point was far more insidious: losing confidence in the project’s trajectory. When an e-commerce platform no longer knows whether it’s open-source software or a SaaS product in disguise, when its own contributors no longer know which version to number or how to document breaking changes, it’s time to look elsewhere.

Because my job isn’t debugging poorly digested Symfony abstractions at 11 p.m. on a Sunday night. My job is to build sales tools that work, that evolve, and that don’t drain my clients’ cash flow with absurd maintenance fees.

The thesis is simple: you can’t build your clients’ future on a platform that no longer knows where it’s headed. And after four years of patience waiting for the promise of a “modern PrestaShop,” I migrated my entire client fleet to WooCommerce. Not out of ideology. Out of pragmatism.

Here’s why.

1. The strategic blur: “Project” vs. “Edition”

I’m not going to revisit the technical details of version 8. That’s already covered in the previous article. Let’s talk instead about what really kills an open-source platform: governance ambiguity.

PrestaShop decided to split its ecosystem into two distinct entities:

PrestaShop Project: the “community” version, open source, free.
PrestaShop Edition: the “professional” version, with support, premium modules, and a priority roadmap.

On paper, it’s coherent. In practice, it’s a positioning nightmare for any provider who puts their professional reputation on the line.

The risk for agencies

When a client asks you which version to install, what do you tell them? The “Project” version that openly serves as a beta lab for features that might eventually land in “Edition”? Or the “Edition” version, stable for sure, but which makes you dependent on a vendor that can change its pricing terms overnight?

The problem isn’t the existence of a paid version. The problem is that nobody really knows which version is the reference for a serious e-commerce project in 2026. Two numbering schemes. Two release cycles. Two philosophies.

A fragmenting module ecosystem

And what about the module developers in all this? Do you really think they’re going to maintain two distinct versions of every module to cover both branches? No. They’ll choose. And guess which one? The one that makes money: Edition.

The result: if you stay on “Project,” you end up with a module ecosystem that gradually withers. And if you switch to “Edition,” you accept becoming captive to a business model you don’t control.

It’s exactly this kind of strategic uncertainty that pushed me toward the exit.

And what about PrestaShop 9.1? Version 9.1 came out a few weeks ago (March 2026) with Hummingbird 2.0, PHP 8.5, and promises of improved stability. Fine. But the core problem remains unchanged: the accumulated technical debt, the governance blur between Project and Edition, and the Smarty/Twig coexistence. A new version doesn’t fix 10 years of questionable architectural decisions. It just kicks the problem down the road another year.

2. Maintenance fatigue (the hidden cost)

Let’s talk money. Let’s talk time. Let’s talk about what really matters to a client: opportunity cost.

The Hooks example: a symbol of the absurdity

You want to know why I cracked? Because on PrestaShop, displaying the same hook multiple times on a page is an obstacle course. A basic concept in modern web development, reusing a component, becomes a pointless technical battle because of a poorly designed hook system that dates back to PHP 5.

On WordPress/WooCommerce, you use do_action() as many times as you want. It’s obvious. It’s predictable. On PrestaShop, you find yourself patching the core or working around with third-party modules to bypass an architectural limitation that has no reason to exist.

Templating engines: Smarty AND Twig (yes, both)

And while we’re on the subject of architectural inconsistencies, let’s talk about templating engines.

PrestaShop decided to migrate from Smarty to Twig. So far, that’s understandable: Smarty is outdated, Twig is more modern and better integrated with Symfony. Except PrestaShop made the mind-boggling choice to keep both engines running in parallel. Why? Because:

The “Classic” theme (still shipped by default): It uses Smarty. PrestaShop can’t remove it without breaking thousands of existing stores that depend on it. So Smarty stays.

The “Hummingbird” theme (the new “modern” theme): It uses Twig. It’s the new reference, the one you’re supposed to use for serious projects.

Do you see the absurdity?

For a developer managing a fleet of sites, it’s a nightmare:

You have to maintain two different templating skill sets depending on the theme a given client uses.
You can’t share your custom components across stores if one runs on Classic and the other on Hummingbird.
The PrestaShop documentation freely mixes Smarty and Twig examples without always specifying which one applies to which version or theme.
Third-party modules often have to ship two sets of templates (.tpl for Smarty, .html.twig for Twig) to stay compatible with both ecosystems.

Comparison with WooCommerce: A single templating engine (native PHP in the theme’s .php files, or builders like Elementor/Gutenberg for pages). No schizophrenic coexistence. A single syntax to master.

This dual stack only serves to mask a deeper problem: PrestaShop won’t commit to a real break in compatibility that would hurt for 6 months but clean up the ecosystem for the next 10 years. The result: we drag the Smarty ball and chain along forever.

A metaphor: It’s like trying to build a house where the ground floor is brick (Smarty) and the upper floor is 3D-printed (Twig). It stays standing. But nobody knows what mortar to use between the two. And when it’s time to renovate, you have to bring in two different contractors who don’t talk to each other.

The real cost to the client

Let’s compare two scenarios factually:

Scenario A (PrestaShop): A client wants to change the layout of the product page.

1 hour to figure out which Twig template is being called (opaque cascade of Symfony overrides)
2 hours to debug why the hook isn’t showing up (a third-party module overrode the controller)
1 hour to test mobile compatibility (CSS conflicts between the legacy and modern back office)

Total: 4 hours, of which 3 hours are pure technical maintenance and 1 hour is real value.

Scenario B (WooCommerce): Same request.

Identify the right hook (woocommerce_before_add_to_cart_form)
Inject the code into the child theme
Test

Total: 1.5 hours, with the useful time focused on the feature.

The difference? The PrestaShop client pays to maintain what already exists. The WooCommerce client pays to generate business.

The “native power” argument collapses

PrestaShop defenders will object: “Yeah, but PrestaShop is more powerful out of the box for multi-language, multi-currency, B2B…”

Maybe. But at what cost? If that “native power” comes at the price of a clunky back office, recurring update bugs, and chronic technical debt, it’s worth nothing.

WooCommerce with the right plugins (WPML, Multi-Currency, WooCommerce Wholesale) does exactly the same thing, more reliably, with better documentation, and in a third of the configuration time.

3. Choosing the new ecosystem: Why WooCommerce?

Busting the myth: No, WooCommerce isn’t “just for small sites”

The PrestaShop purists’ first objection: “WooCommerce is for stores with 50 products. For serious work, you need real e-commerce.”

Wrong. Dead wrong. I have clients doing €200k/year in revenue with catalogs of 2,000+ SKUs on WooCommerce. The problem isn’t the stack. The problem is the architecture.

A poorly configured WooCommerce, with 40 plugins stepping on each other and a theme bloated with legacy jQuery, is slow. But a PrestaShop with 60 modules clobbering the same hooks and an unoptimized template is just as catastrophic.

The difference? The predictability of the ecosystem.

Predictability: a stable foundation

WordPress is 20 years old. WooCommerce is 15. The API is documented. The hooks are stable. Breaking changes are announced several versions in advance with clear migration guides.

When you develop a WooCommerce plugin in 2026, you can reasonably bet it will still work in 3 years without a major rewrite. Try saying the same about PrestaShop post-1.7.

This predictability has concrete economic value for my clients:

Fewer silent bugs after updates
Less time spent on corrective maintenance
Fewer “essential” paid modules to patch up gaps in the core

Agility: handing it over to the client

A PrestaShop client who wants to change some text on their homepage has to:

Log into the back office (and first, explain that there are two interfaces depending on the page…)
Navigate through labyrinthine menus
Understand the “block” logic of the built-in page builder (which changes from theme to theme)
Hope they don’t break the responsive layout

A WooCommerce/WordPress client:

Logs in
Edits the homepage like a Word document with Gutenberg or Elementor
Previews
Publishes

It’s this simplicity that means my clients no longer call me at 6 p.m. to “just change one sentence.”

4. The “1-Click” of dread

The permanent risk of updating

Every PrestaShop provider knows this scene. You’re in the back office. A notification tells you a minor update is available (something like 8.1.3 → 8.1.4). You know it fixes critical security flaws. You have to install it.

But you also know, from experience, that there’s statistically a 50% chance this “minor” update breaks:

A third-party module that didn’t keep up with PrestaShop’s roadmap
A custom template that was using a deprecated function with no warning
The cache system, which will require a manual purge via CLI
Or worse: a silent SQL conflict that won’t surface until 3 days later, when a client calls to report that their PDF invoices are blank

You click. You pray. And in 1 case out of 2, you end up spending your night restoring a 4 GB SQL backup over SSH while your client gets emails from furious customers who can’t complete their orders.

On WooCommerce? You click. It works. You test 2 or 3 pages. Done. Total time: 5 minutes.

Why is it still “hell” in 2026?

The problem no longer comes solely from badly written code or Symfony bugs (I already covered that in my article on PrestaShop 8). No, the problem comes from the very structure of the update process.

The PHP jump: Moving from PrestaShop 1.7 or 8 to PrestaShop 9 often requires a PHP version jump (from 8.1 to 8.4, for example). The “1-Click Upgrade” tool handles very poorly the moment the old version’s code tries to run on too recent a PHP version. The result: the infamous 500 error or blank page in the middle of the process. You’re stuck with a half-migrated store, functional on neither the old version nor the new one.

Post-migration cleanup: Even when the update “succeeds,” you often end up with:

Ghost SQL tables from the old cache system or from uninstalled modules still lingering in the database
Residual Smarty files that pollute the new Symfony/Twig engine and create template conflicts
Orphaned hooks that point to modules that no longer exist, causing inexplicable slowdowns on the front end

This debris requires manual cleanup in the database and in the files. Estimated time: 1 to 2 hours more.

“Blocking” modules: A single badly updated native module is enough to paralyze the entire back office after the upgrade. A typical example: psxdesign (PrestaShop’s graphic customization module), which, after a major update, can lock you out of the entire back office with a fatal PHP error. You then have to:

Connect via SSH
Manually disable the module in the database (UPDATE ps_module SET active = 0 WHERE name = 'psxdesign')
Restart the back office
Wait for PrestaShop to release a module update (delay: anywhere from 2 days to 2 weeks depending on severity)

The contrast with WooCommerce:

On WordPress/WooCommerce, an update is a non-event. Why?

Obsessive backward compatibility: WordPress treats backward compatibility almost religiously. Deprecated functions keep working for years, with clear warnings for developers. You have time to adapt your code. No abrupt break.

Native “recovery” mode: If a WooCommerce plugin (or any WordPress plugin) crashes after an update, WordPress automatically detects the problem and switches to recovery mode. This mode:

Isolates the offending plugin
Lets you access the back office to disable the plugin in one click
Doesn’t take down the whole store

You fix the problem in 2 minutes from the admin interface. No need for SSH, no need to manipulate the database in raw SQL, no need to panic at 2 a.m.

PHP version management: WordPress announces PHP requirements months in advance, and the major plugins (including WooCommerce) follow that roadmap in sync. When you update WordPress 6.8 → 6.9, you know it runs on PHP 8.1, 8.2, AND 8.3. No abrupt jump that breaks everything.

Better still: WooCommerce publishes public beta versions that test compatibility with upcoming PHP versions even before their stable release. So you can anticipate, test in staging, and deploy with peace of mind. PrestaShop, on the other hand, seems to chase compatibility only once the stable PHP version is already out. The result: last-minute bugs, emergency patches, and stressed-out providers.

The debt of updating

Let’s compare the update process for a minor version, factually:

PrestaShop (minor version 8.1.3 → 8.1.4):

Full backup: database + files (30 min with a 2 GB database and 15,000 files)
Staging deployment: duplicate the production environment to test (20 min)
Update in staging: run the “1-Click Upgrade” module (10 min if all goes well, 1 hour if it crashes)
Manual testing: verify that checkout, the back office, and critical modules work (30 min minimum)
Post-migration bug fixes: because there are always some (0 to 2 hours depending on severity)
Update in production: repeat steps 1-3 on the live server (40 min)
Post-deployment monitoring: watch the error logs for 24-48 hours

Total time: between 2.5 and 5 hours, depending on whether you’re lucky or not.

WooCommerce (minor version 9.1.2 → 9.1.3):

Automatic backup via plugin (UpdraftPlus or similar): 5 min
Click “Update” in the WordPress back office: 2 min
Quick test: checkout + back office: 5 min
Deployment complete

Total time: 12 minutes. And I’m being generous.

The difference? The predictability of the ecosystem. When WordPress ships a minor update, it doesn’t break the plugins. Because the API is stable. Because breaking changes are documented in advance. Because there’s real governance around backward compatibility.

The planned obsolescence of themes

And then there’s the coup de grâce: graphic debt.

Remember the section on Smarty/Twig. Now imagine you have a client with a PrestaShop 1.7.8 store running on a custom theme built in 2019 (so, Smarty). They want to migrate to PrestaShop 8.x to take advantage of the new features and the stronger security.

The problem: their custom theme is in Smarty. The new back office and the new modules are in Twig. What happens?

You have to rebuild the theme from scratch. Or close to it.

This isn’t a “migration.” It’s a complete redesign. With everything that entails:

Reworking the custom templates page by page
Rewriting the hooks in the new Twig syntax
Responsive testing on every device
Chasing visual regressions for days

Quote for the client: between €5,000 and €15,000, depending on the complexity of the original theme.

And there, the client looks at you wide-eyed: “But… I just want to update to stay current. Why do I have to pay for a theme all over again?”

The honest answer: Because PrestaShop changed templating engines without ensuring clean backward compatibility. Because the “modernization” is only real if you start over from a fresh install.

On WooCommerce? Themes have been in native PHP for 15 years. A theme built in 2015 still works today (with a few minor CSS tweaks for the new Gutenberg blocks). No redesign. No surprise quote.

The gilded cage: why people stay anyway

So why do so many merchants stay on PrestaShop despite all this?

Because they’re stuck.

A merchant with 10 years of order history, 50,000 customers in the database, and dozens of integrated business modules (accounting, ERP, marketplaces) can’t migrate on a whim. It’s a heavy operation that requires:

A full data extraction (orders, customers, products, history)
A clean API migration (like the one I built with StockSync)
A manual reimplementation of custom business rules (promotions, shipping calculations, specific workflows)
Training the teams on the new tool

Without the help of an expert who has mastered both ecosystems, it’s mission impossible.

That’s exactly why PrestaShop can afford to let its technical debt rot: its long-time users are captive. They know that leaving will cost them €20,000 minimum in services. So they stay. And they pay for corrective maintenance. Over and over again.

My migration work was precisely about breaking that gilded cage open for my clients. By developing API-first tools that extract the data cleanly without depending on PrestaShop’s internal structure, I was able to offer a viable way out.

But how many merchants are still stuck for lack of a provider who has mastered both stacks?

Conclusion: Looking ahead

Migration recap: client feedback

Since completing the full migration of my fleet to WooCommerce (finished in Q1 2025), the client feedback has been unanimous:

Performance: page load times cut in half on average (thanks to optimized WordPress hosting and the elimination of legacy PrestaShop modules).
Simplicity: client training cut from 3 hours to 1 hour. They get the hang of Gutenberg/Elementor in 20 minutes.
Maintenance cost: monthly invoices down 30-40% (fewer bugs, fewer fixes, fewer emergencies).

Not a single client has asked to go back.

Advice to fellow developers: don’t stay out of habit

If you’re reading this article, it may be because you feel that PrestaShop fatigue too. That vague sense that you spend more time putting out fires than building value.

My advice: try WooCommerce on a pilot project. Not on your biggest client. On a small project, where the stakes are limited, where you can experiment without risk.

You’ll see the difference for yourself between:

Spending 2 hours figuring out why a PrestaShop module breaks checkout after a minor update.
Spending 2 hours building a real WooCommerce feature that brings in revenue for your client.

Time is money. Yours. Your clients’. Stop wasting it on a platform that no longer respects you.

Closing line

PrestaShop may have won Symfony. But it lost its boots-on-the-ground ambassadors.

The ones who built free modules out of passion. The ones who answered on the forums at 10 p.m. to help a peer. The ones who fiercely defended the “French e-commerce solution” against WooCommerce or Shopify.

Today, those ambassadors are gone. Or on their way out. Because you don’t build a community on strategic ambiguity and chronic technical debt.

Me, I made my choice. And I don’t regret it.