PrestaShop maintenance contract: the guide to avoid signing anything unclear

Article summary

• What it is for: a PrestaShop maintenance contract protects your store against security vulnerabilities, outages and revenue losses caused by an unresolved bug.
• What it should include: updates (core + modules), backups with a guaranteed recovery time, monitoring, a quantified SLA and defined intervention hours.
• What to avoid: contracts with no written SLA, no guaranteed recovery time, no clear list of exclusions: and contracts that do not specify who owns the produced code.

---

Why a PrestaShop maintenance contract is essential

Many merchants sign a maintenance contract “to have someone to call”. That is the wrong way to frame it. A good contract is first and foremost a structured safety net: not just a phone number.

Here is why it is non-negotiable.

Security: vulnerabilities that can become expensive

PrestaShop is open source. Its vulnerabilities are public, referenced as CVEs (Common Vulnerabilities and Exposures, public identifiers for known security flaws), and accessible to anyone: including attackers.

In 2024-2025, several critical vulnerabilities were actively exploited. CVE-2024-34716, an XSS vulnerability through the contact form, made it possible to execute malicious code when an administrator opened a trapped file. CVE-2024-36680, an SQL injection through a third-party module, led to the compromise of more than 5,000 stores, later resold on the dark web.

The real problem is not usually the PrestaShop core itself. It is third-party modules: often developed without a security audit, sometimes abandoned by their publisher: that multiply entry points. In 2025, another critical vulnerability (CVE-2025-51586) could still bypass administrative authentication.

Without regular maintenance, your store silently accumulates known vulnerabilities. Automated attack scripts find them before you do.

Performance: what slows down an unmaintained store

An unmaintained store deteriorates gradually. It is rarely spectacular: and that is precisely the problem.

An outdated module makes SQL queries heavier. Cache is poorly configured after a partial update. Unoptimized images pile up. The result: loading time increases, conversion rate drops, and SEO visibility declines.

Without active monitoring, you do not see it coming. You notice it six months later while looking at Analytics.

Continuity: when a bug blocks orders

The most expensive scenario is a silent checkout bug. The customer arrives, adds to cart, clicks “pay”: and nothing happens. Or worse: the order is created in the back office, but payment does not go through.

Without a contract with a defined SLA, you wait. You send an email. You follow up. And during that time, you lose sales.

---

What a good contract must cover

Here is what I systematically check before validating a contract: whether it is mine or a fellow provider’s.

Updates (core, modules, theme)

The contract must specify which updates are included: PrestaShop core, native modules, third-party modules, theme.

These are not the same thing. Updating the core without checking module compatibility can break the store. Updating a payment module without testing the checkout flow is risky.

A good contract distinguishes:

• Minor updates / security patches: applied quickly, often included in the monthly package.
• Major updates (for example moving from PrestaShop 8 to 9, released in June 2025): these migrations are full projects, with a prior audit, a pre-production environment and complete testing. They are generally not included in a standard monthly package: see my dedicated guide on PrestaShop 1.7 to 8 migration to understand the scale of that kind of project.

Watch point: check whether the contract specifies if paid third-party module updates are included: and who pays for new licences if needed.

Backups: frequency and recovery

The clause I most often see missing from agency contracts is the guaranteed recovery time after an incident. Without it, “backup included” does not mean much.

A serious contract specifies:

• The backup frequency (daily minimum for an active store)
• The storage location (remote, outside the main server)
• The retention period (7 days minimum, ideally 30 days)
• The guaranteed recovery time in case of incident (4h? 24h? 48h?)

Without a contractual recovery time, the backup may exist: but it does not really protect you.

Monitoring and surveillance

Monitoring is what turns reactive maintenance into proactive maintenance.

A solid contract includes:

• Uptime monitoring (alert when the site goes down)
• Performance monitoring (loading time, server errors)
• Security watch (new CVEs affecting your PrestaShop version and your modules)

Guaranteed response time (SLA)

The SLA, or Service Level Agreement, turns a verbal promise into a measurable contractual obligation. It is the backbone of the contract.

A well-written SLA distinguishes at least two levels:

Level	Definition	Response time
Critical	Store unavailable, payment flow blocked	1h to 4h
Standard	Non-blocking functional bug, technical question	24h to 48h

Without a written SLA, “responsiveness” means nothing legally. I have seen contracts promise a “fast intervention” without any figure. That is useless in case of dispute.

Included intervention hours

How many development hours are included in the monthly package? For what exactly?

A clear contract specifies:

• The number of included hours per month
• What counts as an included intervention (bug fixes, updates) vs. out of scope (new features, redesign)
• Whether unused hours can be carried over or not

---

The 3 types of contracts: which one should you choose?

There is no universal model. It depends on your business volume, the stability of your store and your development needs.

Monthly package with included hours

The most common model for active SMB stores. You pay a fixed monthly amount in exchange for a number of hours and a defined set of services (updates, monitoring, backups, support).

• Full budget visibility
• Ongoing relationship with the provider
• Unused hours are often lost
• Can be oversized for a low-change store

Annual fixed-price contract

A variation of the monthly package, with a 12-month commitment in exchange for a reduced rate. Relevant if your store is stable and you have good visibility over your needs.

• Better negotiated rate
• Provider commitment over time
• Less flexibility if your needs change
• Termination can be costly

Time-and-materials, on demand

You buy a block of hours and use them when needed. No monthly commitment.

• Maximum flexibility
• Suitable for very stable stores or smaller budgets
• No responsiveness guarantee, because the provider is not “on standby” for you
• No proactive monitoring included by default
• Hourly cost is often higher than in a package

---

What I include in my maintenance contracts

I am not going to publish a price grid here: that is not the point. But I can be transparent about what I consider the non-negotiable minimum in every contract I offer.

Security updates applied within 48 hours after a critical CVE is published.

Daily backups stored outside the server, with a guaranteed recovery time written clearly.

24/7 uptime monitoring with immediate alerts.

Written SLA with two levels (critical / standard) and quantified delays.

Monthly report: actions completed, store status, recommendations.

Code ownership: any development done within the contract belongs to you. Always.

I work as a freelance PrestaShop maintenance specialist: which means one single point of contact, detailed knowledge of your store, and a responsiveness that larger structures struggle to guarantee.

---

The 5 clauses to check before signing

Take the contract. Look for these 5 points. If they are missing or vague, ask for clarification before signing.

1. Exclusions

Every contract has exclusions. What matters is that they are explicitly listed. The most common ones are third-party modules, hosting, and interventions following a client-side manipulation. If exclusions are not listed, any dispute becomes much harder to resolve.

2. Intervention times

As we saw above, without a quantified SLA, “responsiveness” means nothing. Check that the contract distinguishes at least two emergency levels with precise response times.

3. Code ownership

Who owns the code developed during the contract? If the contract does not specify it, the provider often retains rights, which can block your transition to another provider. Require a clear clause: the code produced during the contract belongs to you.

4. Termination conditions

What is the notice period? Are there penalties? What happens to accesses (FTP, back office, hosting) at the end of the contract? A good contract includes a transition period and the return of all accesses within a defined timeframe.

5. Hosting: included or not?

Some contracts include hosting, others do not. If hosting is included, check: who owns the server? If you terminate the maintenance contract, do you also lose hosting? Can you migrate your store freely?

---

Freelancer or agency for PrestaShop maintenance?

This is the question I hear most often. And I have a clear opinion: not because I am a freelancer, but because I have seen both models work, and fail, from up close.

Responsiveness and one single contact

With a freelancer, you have one person who knows your store inside out: its history, modules, specifics and fragile points. You do not have to explain the context again at every incident.

With an agency, you often have a project manager who forwards the issue to a developer who may never have touched your store. In a crisis: a blocking bug on a Friday evening: that communication chain costs time. Time means lost sales.

Pricing and flexibility

Agencies have heavier cost structures. That is reflected in pricing. A specialized PrestaShop freelancer can offer an equivalent level of expertise, often higher on your specific stack, at a more competitive cost.

Flexibility is also a real advantage: a freelancer can adjust the contract scope more easily than an agency with rigid processes.

My clear opinion

For an SMB/TPE PrestaShop store, a specialized freelancer is almost always the best choice. Not out of bias: out of operational logic.

I sincerely believe an agency cannot offer the same responsiveness as a dedicated freelancer on a critical incident: and I see the proof every week.

The direct relationship changes everything in an emergency. When your payment flow goes down on a Saturday morning, you want to reach someone who knows your store and can act within the hour: not open a ticket in an extranet and wait until Monday.

What I systematically observe: merchants who had a bad experience with an agency often come back to a freelancer for exactly that reason. Responsiveness and knowledge of the project.

That said, an agency can make sense if you have very broad needs (development, marketing, design) and prefer one provider for everything. In that case, check that maintenance is handled by a dedicated PrestaShop developer: not outsourced to a generalist.

---

My expert opinion

What is the worst situation you have seen on a store without a maintenance contract?

The worst situation is a store in trouble with no real responsiveness from the provider and commitments that are not kept. The merchant thinks they are covered, but nobody truly answers, problems pile up, reliability deteriorates and every follow-up becomes stressful. That is exactly what a clear contract should prevent.

How do you handle a critical CVE alert during a weekend?

With a properly framed maintenance contract, I am reachable by WhatsApp or SMS for real emergencies. If a critical CVE affects the store, I quickly check exposure, affected modules and the priority level, then I intervene or temporarily secure the store right away.

What would make you refuse to sign a maintenance contract with a client?

I refuse if the scope is not perfectly clear for both parties. A maintenance contract should prevent frustration, not create it: expectations, delays, exclusions, access rights and responsibilities must be explained openly and validated before work starts.

---

FAQ