PrestaShop update: what should be checked before getting a quote?

A reliable estimate for a PrestaShop update requires the full store version, server environment, theme, key modules, and a description of custom changes. The version number alone does not define the scope of work. Two stores on the same version may require completely different preparation if one uses standard features while the other has a modified checkout, warehouse integration, and custom pricing rules.

This guide helps you prepare an update inquiry and agree on acceptance criteria. It is not an instruction for running the updater without a prior backup and dependency check.

PrestaShop and PHP versions must form a supported combination

Record the full designation of the current and planned store version. Check the PHP version serving the website as well as the PHP used by CRON and console commands. Hosting may provide different versions for these execution methods. Changing the setting in the domain panel does not necessarily change the interpreter used by scheduled tasks.

According to documentation verified on September 13, 2026, PrestaShop 9.0 supports PHP 8.1–8.4, and PrestaShop 9.1 supports PHP 8.1–8.5. The recommended PHP versions also differ between these branches. This is an example of why the statement “supports PrestaShop 9” is insufficient when selecting the environment. Source: official PrestaShop 9 requirements.

A supported environment for the store engine itself does not yet confirm theme or module compatibility. Before upgrading PHP, also check their requirements, server extensions, memory limits, and the way integrations are executed. Do not start by changing PHP in production just because the newer number looks more favorable.

Inventory: start with critical functions

A list of all modules is useful, but above all the contractor should know which functions sustain daily sales. Indicate payments, shipping, pickup points, invoicing, warehouse, price and stock imports, reservations, and special B2B rules. Add information on who maintains each integration.

At the initial contact stage, technical information and a process description are sufficient. Do not enter passwords, API keys, or customer data into a publicly accessible document. If access to a copy is needed, agree on the method of transfer and the scope of permissions.

What stays, what do we update, and what do we replace?

Each important element should receive a decision and its justification. “Stays” means confirmed usefulness in the planned configuration. “To be checked” is a valid status before analysis; false certainty makes estimation and later acceptance more difficult.

Do not assess a module solely by whether it can be installed. Installation does not confirm discount calculation, pickup point saving, or completion of communication with the warehouse. Likewise, a correct homepage is not proof of a successful store update.

Custom changes: the biggest risk may be invisible in the panel

Ask the people maintaining the store about modifications that have accumulated over the years: additional fields, unusual order statuses, price changes, carrier exclusions, or special exports. Some of them may exist outside the modules visible in the panel.

A short behavior description is useful: “for this customer group the price is calculated like this,” “these products exclude this carrier,” “after this status we send a document to the system.” From such a description, an acceptance test can be prepared. The override file name alone does not explain its business significance.

Recreating a missing function may require separate work. It should be identified within the scope or explicitly marked as a dependency to be clarified, instead of appearing only after the store is switched.

Test copy and acceptance criteria

The update is first carried out on a copy with controlled integrations. Preparing the copy also includes access protection, stopping production dispatches, and separating external service configurations. The copy should enable process testing, not unknowingly replicate the operation of the production store.

The official back-office update guide describes how to use the update tool. The acceptance scope should additionally reflect the store’s functions; the reference point is the post-update checklist.

• Compare selected products, combinations, prices, and stock levels.
• Check the customer account, cart, addresses, and important shipping and payment methods.
• Verify the order result in the panel and in the systems it should reach.
• Run controlled tests of imports, exports, and CRON tasks.
• Compare important URLs, canonicals, redirects, language versions, and sitemaps.
• Record errors, decisions, and acceptance conditions, not just a general “tests completed”.

You can find a more detailed purchase control checklist in the guide about changing the checkout. When working on URLs, also use the existing text about preserving old links and redirects.

The switching and rollback plan must account for new orders

Before the work begins, determine the moment for creating the final copy of files and database, the method for limiting data changes, and the order of stopping and resuming integrations. Appoint the person responsible for deciding to launch the store and the conditions under which you return to the previous version.

Restoring a copy from before the update may remove orders or changes saved later from the current database. Therefore, a backup without an agreed restoration point is not a complete contingency plan. You must also account for payments that may be confirmed with a delay and data sent to external systems.

The rules for preparing a copy are discussed in the PrestaShop backup documentation. For a specific store, additionally define who verified the possibility of restoration and how changes made during the work will be reconciled. Do not assume a zero-downtime update in advance.

What does the estimate include?

The estimate may include analysis and inventory, copy preparation, the actual update, code and theme adaptation, testing, switching, and post-launch support. Licenses, paid updates of external modules, and functions requiring recreation should be indicated separately.

Ask for a clear scope, dependencies, and completion criteria. A fixed price makes sense for identified work; with unknown modifications, an analysis stage may be useful first. There is no single fair amount for every store labeled “PrestaShop 1.7” or “PrestaShop 8”.

Prepare the store version, theme name, and list of key integrations. On this basis, you can start planning the PrestaShop store update, define the necessary checks, and prepare a scope that can be billed.

Substantive verification: September 13, 2026. Version requirements were checked in the PrestaShop documentation. The decision matrix is an example; the target path and integration compatibility are determined for a specific store.