Upgrading to PrestaShop 9 makes sense when the store needs a supported environment and its modules, theme and integrations are ready for the change. The version number alone isn’t enough to decide. First you need to check the compatibility of the whole store, do a trial run on a copy and work out how to roll back if a problem occurs.
What version 9 changes
Moving from 8 to 9 also affects the technologies the store runs on. PrestaShop 9.0 moved from Symfony 4.4 to Symfony 6.4. This change matters mainly to module authors and to people maintaining custom modifications. Code that uses older mechanisms may need adapting, even if the feature is meant to look identical to the customer. The scope of the changes is described in the PrestaShop 9.0 change documentation.
Check the server requirements for the specific release you plan to deploy. “Our hosting supports PrestaShop” is too general. You need a compatible PHP version, the right extensions, a database and enough resources to run imports and background tasks. The reference point is the official requirements table. Check separately the PHP serving the site and the PHP run by the task scheduler.
For a store owner, what matters is the result: being able to keep maintaining the system, the availability of the extensions you need and your sales processes working. Don’t assume the upgrade will by itself speed up the catalogue, fix search or simplify warehouse work. Such effects need a separate diagnosis and measurements before and after the change.
The biggest unknowns are often modules and the theme
In a standard installation, the scope of work is relatively easy to estimate. In a store developed over several years, the list of modules doesn’t yet tell you what really needs to be carried over. A payment module may have received a local patch, the theme may use a modified cart, and the ERP integration may reach straight into the database. Each such element has to be identified before quoting.
A vendor’s compatibility statement is a good start, but it applies to a specific version of their product. Check whether your licence covers access to that release and whether the update will keep your configuration. If someone has changed a module’s files, downloading a new package may wipe out those modifications. Custom code has to be compared with the original to decide which differences are still needed.
The theme needs a trial too. The home page may look fine while choosing a product combination, address validation or mobile payment stops working. With a bespoke theme you need the sources and instructions for building the files. With a ready-made theme, what matters is the availability of updates and the compatibility of the add-ons bundled with it.
How to check where you stand
Before discussing a date, prepare an inventory. For each extension, record its name, version, vendor, business function and the person responsible for maintaining it. Add information about the licence and any changes. A module nobody can describe needs checking: it may be redundant, but it may also be sending orders to the warehouse once a day.
- Establish the exact version of the store, PHP, database and theme.
- Collect a list of active modules, scheduled tasks and connections to external systems.
- Check overrides and direct changes to core files.
- Verify access to the code, backups and extension vendors’ accounts.
- Describe any unusual rules for prices, delivery, discounts and order handling.
The result should be a document that sorts elements into ready to move, needing a fix, needing a replacement or to be removed. For every unknown you need a way to resolve it. If the store has many overrides, a separate review of overrides in PrestaShop will help. Without this work, an “upgrade” may hide a rebuild of several important features.
When it’s worth postponing
Deploying just before your most important sales campaign increases the cost of any mistake. If there is no urgent security reason, it is wiser to prepare and test the change earlier and schedule the switchover outside the peak. A postponement should, however, have a specific date and conditions to be met by then.
The second reason is the incompatibility of a feature essential to sales. If the payment provider or the integration passing orders to the ERP doesn’t work, running the store on a new core achieves little. First you need a fix, a replacement or an agreed interim procedure. Don’t assume the vendor will be ready in time until you have a version you can test.
It is also worth combining work if the company is already preparing a theme change or a migration to another platform. Adapting a part that is about to be removed can be an unnecessary cost. The condition for such a decision is being able to keep the current store safely maintained until the next implementation.
When delay makes the store harder to maintain
Postponing an upgrade doesn’t stop other suppliers from changing. The host updates the environment, the payment provider changes its integration and the module vendor releases new versions. If the store needs more and more exceptions, every new feature first has to be adapted to old limitations. That effort should appear in the cost comparison.
Check the current support status of the release you use and its dependencies. The availability of security patches doesn’t follow from the store still taking orders. When a security issue appears, the decision on timing has to be based on its significance for the installation and the available safeguards, not only on the campaign calendar.
Compare two options over the same period: cleaning up and upgrading now, versus continued maintenance with a later move. In the second option, include compatibility fixes, extra testing and work that will have to be done again later. Such a comparison gives a better basis for a decision than the belief that a working store should never be touched.
How to prepare a safe upgrade
Start with a backup of the files and database, and a test restore. Then set up a separate test environment. Block access for outsiders and indexing, disable emails to customers, and switch payments and integrations to the appropriate test mode. A copy of production must not accidentally create real shipments or pass on duplicate orders.
On the copy, run the full upgrade and write down every extra step. Test the processes: guest and logged-in purchase, product combinations, discounts, delivery, payments, provider confirmations, emails and export to the ERP. Also check order cancellation and refunds. Ask a customer service employee to do their usual tasks, because not every exception is visible in the documentation.
Before the switchover, decide when writes will be paused, a fresh backup made and the new version launched. Agree who decides on a rollback and how payments coming in during that time will be reconciled. Returning to the old database after accepting new orders requires those orders to be secured and the data reconciled. Restoring the files alone doesn’t solve that problem.
Before approving the deployment, it is also worth agreeing how it will be signed off. Prepare a table with the test name, expected result, the person checking it and its status. If a case failed, describe its impact on sales. A minor visual difference and incorrect price calculation should not carry the same weight. Make the go-live decision based on this list, not on the tool’s message that the upgrade finished without errors. Keep the trial results with the project documentation so the next contractor knows what was actually verified and which limitations the company accepted.
Frequently asked questions
Can the store be upgraded without downtime?
Most of the preparation can be done while sales continue as normal. The switchover itself may require briefly pausing orders to keep the data consistent. A promise of zero downtime requires a specific technical solution and a rehearsal of the whole procedure.
What about modules the vendor no longer develops?
First check whether their function is still needed. If it is, you need to find a replacement or commission an adaptation of the code, taking the licence into account. In both cases, agree who will be responsible for fixes later.
Will the upgrade affect my Google rankings?
The version number itself guarantees neither an improvement nor a drop in visibility. Check URLs, content, canonical links, indexing and server responses before and after deployment. If you are also changing the URL structure, you need a separate redirect plan.
How long does a major version upgrade take?
The time depends mainly on the compatibility of extensions, the amount of custom code and the number of processes to test. A reliable date comes after the inventory and a trial on a copy. The time it takes to run the upgrade tool is only part of the work.
Where to start the decision
Ask your contractor for a list of obstacles, a test plan and a switchover procedure. Only on that basis should you approve the budget and the date. If you need help defining the scope, see store migrations and upgrades.