From time to time the same phone comes back to me: ‘I heard that my PrestaShop will stop working, do I need to do something about it?’. The answer is shorter than most people think. The store won’t go out overnight. But the clock is actually ticking, and it’s best to move when you have a calm head, rather than panicking after the first major security issue.
In this text, I break down the whole case into simple factors: what exactly does the end of PrestaShop 8 mean, why you should plan ahead for the transition to PrestaShop 9, and how to implement it so that sales don’t stop for a moment. No fear, no marketing cotton wool. Just like I do it myself in production stores.
Table of contents
- What does ‘the end of PrestaShop 8’ really mean?
- Why it’s better to move Now rather than at the last minute
- What really changes in PrestaShop 9
- Highest risk: Modules and theme
- Server Requirements: PHP and database
- Step-by-step migration plan
- How long does it last and what does the cost depend on?
- Errors that result in a store downtime
- Frequently Asked Questions
- Resume
What does ‘the end of PrestaShop 8’ really mean?
Let’s start with a fact that calms half the conversations. End of support is not the same as end of action. PrestaShop 8 will still download, accept orders, and issue invoices long after it stops receiving official fixes. But it’s these patches that are at stake.
The PrestaShop team has announced that the 8.x branch will receive security patches until at least early 2027. After that, the holes you find will no longer be fixed in the kernel. And I know very well in practice what it looks like: it is in such unsupported versions that bots are most likely to look for loopholes, because they know that no one else will close them. I’ve seen stores hijacked by abandoned override files and changed admin accounts precisely because someone was putting off updating ‘for later’.
The second element is the ecosystem. Developers of modules and themes go where there is a market, that is, to the top nine. The longer you sit on the top eight, the more often you will hear ‘this version of the module is no longer being developed’. The direction is clear: the future of PrestaShop is happening on version 9.
Why it’s better to move Now rather than at the last minute
Migration under pressure is the worst-case scenario. When you do this because you’ have to for yesterday’, you cut corners: skip tests, agree to the first best module replacement, push live changes in the middle of the week. And then something breaks in the shopping cart or in payments.
When you plan to upgrade PrestaShop in advance, you have the comfort that you can’t buy later: time for a good test environment, quiet testing of each module, and choosing a deployment window at night or on weekends when traffic is least. The difference between one approach and the other is usually the difference between ‘the customer didn’t even notice ‘and’we lost half a day of sales’.
There is also a purely technical argument. The older the version you take off with, the harder the jump will be. The transition from a fresh eight to a nine is much gentler than dragging a store with a backlog a few years ago. Each month of delay is an additional debt that will still have to be repaid, only more expensive.
What really changes in PrestaShop 9
Nine is the most profound redesign of the platform since the transition from 1.7 to 8.From the point of view of the store owner, four things are most important.
A more modern foundation. The entire back office is now running on Symfony 6.4 LTS, and the code is cleaner and easier to maintain. In practice, this means a faster panel and less strange behavior when expanding. In typical stores, the combination of new PHP and these optimizations results in noticeably shorter response times.
New Hummingbird theme. Starting with version 9.1, the default theme is Hummingbird 2.0. It is lightweight, mobile first and strictly monitors accessibility, which is important in the context of EU requirements (the European Accessibility Law is valid from June 2025). If you have a heavily redesigned custom theme for Classic, then this is exactly the point that needs attention, I’ll return to it below.
New API. Nine introduces a fresh admin API built for modern integration. If you work in a store with an ERP system, a store, or an external application, this is the direction in which all this happens. You just need to keep in mind that endpoint coverage is gradually increasing, so part of the integration may still use a legacy Webservice.
Better update support. The Update Assistant tool (formerly 1-Click Upgrade) is much safer than what you remember from the G8. It has a console mode, a pre-update check, and a built-in rollback. This is what underlies the migration process itself.
Highest risk: Modules and theme
Let me be blunt: in nine out of ten projects, the problem is not in the PrestaShop core, but in what was added on it. The kernel migrates predictably. Your store reverts a specific payment module, redesigned delivery, or rewritten theme.
What does PrestaShop 9 module compatibility look like today? In mid-2026, the official PrestaShop modules are more than 95 percent compliant with nine. Among the top external modules from the marketplace, approximately 70 to 80 percent went to the top nine. It looks the worst with its own modules and those from small, already forgotten creators, it really happens differently here.
When planning a migration to PrestaShop 9, check your marketplace modules as well. The TikTok Shop integration is built for 8.x and 9.x, so it will not block the upgrade.
So the first real work in a migration is not clicking ‘update’, but taking inventory. You output each active module and make one of four decisions with each one:
- there is a version for 9, we are updating it;
- there is no version for 9, but there is a reasonable replacement, we replace;
- there is no version or replacement, but the function is critical, we are adding or redoing it;
- the function is no longer needed, we are throwing away and, by the way, reducing the store.
The last point is underestimated. Migration is a great time to get rid of the ballast. Almost every store I take in is dragging along a few modules that no one has used in years, which continue to slow down and complicate the whole thing.
The topic is a separate story. If you use a Classic-based theme, in most cases it can be migrated with minor changes. You won’t get the same Hummingbird benefits as WebP or Bootstrap 5 support. If, on the other hand, you have a heavily modified theme with a lot of rewrites of back office templates, be prepared for more work. This is usually the most time-consuming part of the entire puzzle.
Server Requirements: PHP and database
There is a trap here that many people who try to migrate on their own fall into. PrestaShop 9 requires PHP versions 8.1-8.4, while production requires 8.3. If your hosting service runs on older PHP, updating the store itself won’t do anything, because the nine just won’t budge.
So before you click on Prestashop, check your environment: PHP version, memory limits, MySQL or MariaDB version and configuration. A common scenario in real life is a store that is ready for migration on paper, but shared hosting does not allow you to switch PHP to the required version or suffocates it with restrictions. Then the migration boils down to moving to a neater server anyway, so it’s better to be aware of this at startup, rather than in the middle of a deployment.
If the store is already regularly slowing down during peak hours today, consider migration as a natural moment to organize your infrastructure. A well-chosen PrestaShop server, with meaningful OPcache, Redis cache, and basic configuration, can do more for performance than just changing the version.
Step-by-step migration plan
And now for the specific procedure that I follow in the production halls. Golden rule: We never update in the live store. All work is done on a copy.
1. Full backup. Database and files included. This is your safety net and the point to which you will return if something goes wrong. We won’t start without it.
2. Test environment (staging). A copy of the store is cut off from customers, where you can safely experiment. This is where the entire migration will happen before anyone else sees the changes.
3. Checking the server. You install PHP on the required version, check the database and restrictions. The environment must meet the requirements of nine before you can start updating the store itself.
4. Inventory and module decisions. This list with four solutions, which I wrote about above. It’s best to go through it before the update to know what’s waiting for you.
5. Update with Update Assistant. You run the tool on a copy, use the pre-update check, and see what it complains about. If something goes wrong, you have a rollback. That’s why it’s done on stage, not in production.
6. Critical path tests. And it’s not ‘click, click, looks normal’, just a real transition: viewing categories, filtering, adding to cart, full verification with a real payment and delivery method, invoicing, refund processing. To do this, compare the speed and structured data with what it was before.
7. Deploy in a low-traffic window. When staging is running, you push changes to production at night or over the weekend with a backup ready for immediate recovery. A well-planned deployment usually involves several tens of minutes of unavailability, rather than an entire day.
There is one more piece of advice that I repeat to everyone: when you first release a new version, you should wait for the first or second patch in the Series, and not rush to zero-day production. Early errors and module compatibility issues usually occur when washing during the first few weeks.
How long does it last and what does the cost depend on?
There is no single answer, because PrestaShop store migration is not an off-the-shelf product. But you can provide reasonable forks to help you evaluate your own case.
A simple store, several standard modules, and a theme with no major changes: usually a few business days. An average store with its own theme and a dozen or twenty modules: really from two to four weeks. A large, complex project with many integrations and a heavily redesigned front: from month to month.
What really drives value? Not the number of products, but the complexity. The more native code, overrides, and integration with external systems you have, the more hours you need to test and fix. That’s why a fair migration assessment always starts with a store visit, not a price tag with a spreadsheet.
Errors that result in a store downtime
I’ve compiled the ones I see most often, because they’re easier to avoid when you know about them.
- Update on the live store. A classic and at the same time the most expensive mistake. One unexpected conflict, and the buyer gets to the white page during purchases.
- There is no new backup. A week-old copy is not a migration backup. This should be done immediately before the operation, along with the database.
- Skipping payment and delivery. Most often, it is payment modules and carriers that break down. If you don’t click on it on stage, you’ll learn about the problem from the frustrated customer.
- Ignoring SEO. Migration can move the address structure, canonical, hreflang, or structured data. If you don’t take care of this, Google positions may drop after deployment. SEO verification should be part of the plan, not an after-the-fact rescue operation.
- Bad server. An attempt to put nine on Wednesday with the old PHP ends up with the store not getting up at all. This is the first thing to check, not the last.
Frequently Asked Questions
My store on PrestaShop 8 will stop working in 2027?
It won’t stop working with the machine. On the contrary, it will lose official support and security patches, making it an easy target over time. Hence, migration is a matter of a reasonable timeframe, not a forced shutdown.
Can I update the store with one click?
Update Assistant can indeed handle the process pretty much automatically and has a rollback. But in a real module and theme store, the tool itself is just one of seven steps. The rest is tests and decisions that no button will make for you.
Will I lose data or orders?
If properly backed up and transferred to a copy, the risk of data loss is close to zero. The whole trick is that you only start production when the test version is working properly.
Wait for the next version or migrate now?
If the store is going to move or actively develop, it makes sense to rely on the current stable branch of nine and have the architecture ready for future updates. Waiting indefinitely for the ‘perfect moment’ usually means simply putting off technical debt.
Resume
The end of PrestaShop 8 support is not a cause for panic, but it is a concrete signal: plan your migration on your own terms while you have time to do so. Made head first, on a test environment, with a decent inventory of modules and a proven server, upgrading to PrestaShop 9 can be completely invisible to customers. Made in a hurry in a live store, it can cost a day of selling and a lot of nerves.
If you don’t want to go through this yourself, I can look into your store, check out the modules, theme, and server, and then make a specific migration plan with a quote that matches the actual state, not the table. Call me before it becomes an emergency.’
