It happens more than people expect. You take on a client through a referral, or an acquisition, or you win a retainer and only later find out their store runs on PrestaShop — and nobody on your team has ever opened one. Now there’s a platform on your books that your WooCommerce and WordPress people look at sideways.
It’s a common spot, and it’s less dangerous than it feels. As long as you don’t guess.
PrestaShop is not “WordPress but different”
The instinct is to treat it like any other CMS and poke at it the way you would a WooCommerce site. Don’t. PrestaShop has its own module system, its own override mechanism, its own upgrade path, and its own ways of breaking. A developer applying WooCommerce reflexes to a PrestaShop store is exactly how a small ticket turns into an afternoon of downtime.
First rule: don’t touch production
Before anyone changes anything, get a staging copy. You want to find out what you’ve inherited somewhere it can’t cost your client an order. This one habit prevents most of the horror stories.
Size up what you’ve actually got
Five things tell you whether this is a tidy job or a sleeping problem:
- The version, and how far behind it is. A store two major versions back is a different animal from a recent one.
- Custom modules and overrides. Has someone modified core? If so, updates will fight them.
- Payment and shipping integrations. These are where an upgrade quietly breaks the checkout.
- The theme — stock, customised, or a bespoke build nobody documented.
- Whether anyone’s been maintaining it at all. An abandoned store carries a stack of out-of-date modules, and out-of-date modules are how stores get hacked.
The three things that bite
Upgrades. PrestaShop major upgrades are not a button. They break modules, and they break overrides. Test them on staging, module by module, or don’t do them yet.
Overrides. Somebody, at some point, hacked core to get a feature shipped. Find that before you update, because the update will erase it and take the feature with it.
Abandoned modules. The ones nobody uses but nobody removed. They’re the attack surface. When a PrestaShop store gets compromised, this is usually the door.
What’s safe for a generalist, and what isn’t
Products, content, basic configuration, adding a page — your team can handle that fine. Where you want someone who’s actually lived in PrestaShop: core updates, module conflicts, checkout and payment logic, performance on a store that’s already slow, and anything on an install that’s limping. That’s the work where guessing gets expensive.
And here’s the honest part: there aren’t many people to call. PrestaShop is rare enough in the US that “find someone who knows it” becomes its own project. That scarcity is real, and it’s the whole reason an inherited PrestaShop client feels like a bigger problem than it is.
If you’ve got one and you’d rather not have your team learn PrestaShop’s internals on your client’s live store, that’s exactly the kind of brief I take — white-label, behind your brand, your client none the wiser. Here’s how I work, and before you send anyone a brief it’s worth reading the questions to ask a white-label developer first.