Upgrading to PrestaShop 9: What to Check Before Migrating Your Online Store
Your online store works.
Orders are coming in.
Payments are being processed.
Stock is updating.
Then a new major PrestaShop version appears.
The obvious question is:
If everything works, why change anything?
For a normal desktop or mobile application, the answer may seem simple: a new version is available, so install it.
An established ecommerce store is different.
After several years, a PrestaShop project usually develops an entire ecosystem around the core platform:
payment modules;
shipping providers;
warehouse integrations;
ERP or accounting systems;
CRM;
marketplaces;
analytics;
SEO modules;
custom checkout logic;
custom development;
a heavily modified theme.
Updating the CMS therefore does not mean simply replacing a few files.
It means changing the platform underneath a system that may be responsible for a significant part of the business.
With PrestaShop 9 and 9.1 now available, many store owners are facing exactly this decision.
The important question is not whether the latest version exists.
It is:
When does upgrading make sense, and how can the migration be performed without experimenting on a live store?
What changed in PrestaShop 9?
PrestaShop 9 is not simply a redesigned back office.
There are substantial architectural changes underneath.
One of the most important is the move to Symfony 6.4.
PrestaShop 8 was based on Symfony 4.4, so this is a significant technical jump. PrestaShop 9 also requires PHP 8.1 or newer and introduces a more modern foundation for ongoing development.
For shoppers, framework versions are invisible.
For developers and store owners, however, they matter.
A modern technical foundation makes it easier for the ecosystem to support current PHP versions, new modules, APIs and future integrations.
But major internal changes also mean that an old module or custom modification should never be assumed to work automatically.
What changed in PrestaShop 9.1?
PrestaShop 9.1 was released on 23 March 2026.
One of its most visible changes is Hummingbird 2.0, which became the default front-office theme for new installations. PrestaShop describes it as a modern, accessible and performance-oriented storefront architecture.
For European merchants, accessibility is especially relevant because Hummingbird has been developed with European Accessibility Act requirements in mind.
However, there is an important detail.
If an existing shop is upgraded from PrestaShop 9.0 to 9.1, its current theme remains in place.
Hummingbird does not automatically replace the existing storefront during an upgrade.
That is good news for existing projects.
It also means that theme compatibility still needs to be checked separately.
Do you need to upgrade immediately?
No.
The release of a new major version does not mean every merchant should migrate the same week.
For a commercial store, stability is more important than having the largest version number.
If the current shop:
runs reliably;
receives security updates;
uses a supported server environment;
supports the modules the business needs;
is not preventing further development;
then the migration can be planned rather than rushed.
But there is an opposite problem.
Some businesses keep the same ecommerce version for years because:
“It works, so do not touch it.”
Eventually that creates technical debt.
The old platform requires an old PHP version.
New modules stop supporting it.
Payment providers update their APIs.
Shipping integrations change.
Developers spend more time maintaining compatibility.
A migration that could have been manageable becomes a large rescue project.
The better question is therefore not:
“Do we need PrestaShop 9 today?”
It is:
“At what point will postponing the migration become more expensive than planning it properly?”
PrestaShop 8 stores should already be thinking ahead
This is particularly relevant for merchants still running PrestaShop 8.
In August 2026, PrestaShop described the 8.2.x branch as being in its extended support phase, receiving only security and critical fixes, while encouraging merchants to start planning migration to PrestaShop 9.
That does not mean a stable PrestaShop 8 shop suddenly becomes unusable.
It means the direction of the ecosystem is clear.
New development is moving towards PrestaShop 9.
For established businesses, that makes migration planning increasingly worthwhile.
Start by documenting your current store
Before discussing an upgrade, determine the actual starting point.
Moving from PrestaShop 9.0 to 9.1 is very different from migrating a heavily customised PrestaShop 1.7 installation.
The older the starting point, the more changes have accumulated between versions.
Record at least:
PrestaShop version;
PHP version;
database version;
active theme;
installed modules;
custom modules;
overrides;
external integrations;
scheduled jobs;
server configuration.
Think of this as the technical passport of the shop.
Without it, estimating migration complexity is mostly guesswork.
Check PHP compatibility
PrestaShop 9 no longer supports the older PHP versions used by many legacy stores.
For PrestaShop 9.1, official documentation lists support for PHP 8.1 through 8.5 and currently recommends PHP 8.5. PrestaShop 9.0 supports PHP 8.1–8.4, with PHP 8.4 recommended for that branch.
But there is an important distinction:
PrestaShop supporting a PHP version does not mean every installed module supports it.
The core may run perfectly on a newer PHP version while an old payment or shipping module fails.
The real compatibility matrix is therefore:
PrestaShop + theme + modules + custom code + PHP
All of these components need to work together.
Create a complete module inventory
This is one of the most important migration tasks.
An established shop can easily accumulate dozens of modules.
Not all of them are equally important.
Separate them into at least three groups.
Business-critical modules
Without these, the store cannot operate normally.
Examples include:
payment gateways;
checkout modules;
carriers;
VAT or invoicing integrations;
ERP connections;
warehouse synchronisation;
marketplace integrations.
Important modules
The store can still sell without them, but functionality or conversion may suffer.
Examples include:
faceted navigation;
SEO tools;
analytics;
loyalty programmes;
product recommendations;
merchandising tools.
Unused modules
Modules that were installed years ago but are no longer required.
A major migration is an excellent time to remove the third group.
The less abandoned code carried forward, the easier the store becomes to maintain.
“Compatible with PrestaShop 9” is not enough
Suppose a module vendor says:
Compatible with PrestaShop 9.
That is useful information.
It is not proof that the module works inside your exact shop.
A module can conflict with:
another module;
the active theme;
an override;
custom checkout code;
a particular PHP version;
a custom integration.
Real compatibility testing happens on a copy of the actual store.
Not on a marketplace listing.
Check payment modules particularly carefully
For a European ecommerce store, payment compatibility deserves special attention.
The store may use:
Visa and Mastercard;
PayPal;
Apple Pay;
Google Pay;
Klarna;
iDEAL;
Bancontact;
local bank payment systems;
country-specific payment providers.
If the payment module fails after migration, the storefront may look perfectly normal while revenue drops immediately.
Payment testing should therefore include more than seeing whether the payment option appears.
Create real test transactions where possible.
Verify:
successful payments;
failed payments;
cancelled payments;
refunds;
callbacks/webhooks;
order status updates;
currencies;
country restrictions.
The checkout is where technical compatibility becomes business-critical.
Delivery integrations need the same level of testing
European merchants often operate with several carriers at the same time.
A shop may combine:
home delivery;
parcel lockers;
pickup points;
postal services;
express carriers;
international shipping.
For cross-border stores, carrier rules may also change by country, postcode, weight or order value.
After migration, check:
shipping price calculation;
free-shipping rules;
delivery zones;
parcel-locker maps;
pickup-point selection;
estimated delivery dates;
carrier API communication;
shipment creation.
A problem does not always generate a visible error.
Sometimes one carrier simply disappears for customers in one country.
Those silent failures are among the most dangerous.
Check your theme separately
The theme is one of the most underestimated migration risks.
This is especially true for stores created several years ago and heavily customised since launch.
A theme can override core templates and affect:
product pages;
category pages;
search;
cart;
checkout;
customer accounts;
JavaScript behaviour.
After a major platform upgrade, a template may still render but behave incorrectly.
That is more dangerous than an obvious crash.
A blank page is discovered immediately.
A checkout button that fails only on Safari or a delivery selector that breaks only on mobile may remain unnoticed for days.
Testing therefore cannot end with:
“The homepage looks fine.”
Real buying journeys need to be completed.
Hummingbird does not mean your old theme disappears
This point is worth emphasising.
Hummingbird 2.0 becoming the default PrestaShop 9.1 theme does not mean existing stores are automatically converted to Hummingbird when upgraded.
Existing installations retain their current theme.
A move to Hummingbird should therefore be treated as a separate storefront project.
That may include:
design migration;
template redevelopment;
module compatibility testing;
accessibility review;
performance testing.
Combining a major core upgrade and complete theme replacement into one unplanned production change creates unnecessary risk.
Find overrides and custom development
PrestaShop allows developers to modify behaviour quite deeply.
Over the lifetime of a project, someone may have:
overridden a class;
changed a controller;
added a hook;
modified checkout;
altered pricing logic;
changed a template;
added custom JavaScript;
implemented additional order fields.
The problem appears when there is no documentation.
A new developer sees what looks like a standard shop.
Inside, however, there may be years of incremental customisation.
Before migration, these changes should be documented.
Ask:
What was modified?
Why?
Is it still needed?
Is there now a standard PrestaShop feature that replaces it?
Should the code be rewritten rather than migrated?
Sometimes the best migration decision is not to preserve old custom code at all.
Audit external integrations
Modern ecommerce rarely operates in isolation.
A European store may exchange data with:
ERP;
accounting software;
CRM;
warehouse systems;
fulfilment providers;
marketplaces;
payment platforms;
shipping carriers;
mobile applications;
product feeds;
analytics tools.
After an upgrade, verify data flows in both directions.
Silent integration failures are particularly dangerous.
For example:
Orders continue appearing on the website but stop entering the ERP.
Stock still synchronises, but prices no longer update.
Marketplace orders arrive, but shipment statuses do not return.
The storefront appears healthy.
The operational problem appears hours or days later.
Never start with the production store
This is the most important rule.
A commercial store should not be used as the environment where compatibility is discovered.
Create a staging copy.
The staging environment should be as close to production as reasonably possible:
same database structure;
same theme;
same modules;
same custom code;
similar PHP and server configuration.
Perform the migration there first.
If something fails, customers are unaffected.
Logs can be investigated.
Modules can be updated or replaced.
The process can be repeated until the migration becomes predictable.
The final production upgrade should be a rehearsed procedure, not the first attempt.
A backup is not simply a ZIP file
Before migration, create a complete backup.
At minimum this includes:
store files
and
database
PrestaShop itself repeatedly recommends backing up both files and database before performing updates.
But merely possessing a file called backup.zip is not enough.
The important question is:
Can the store actually be restored from it?
Archives can be corrupted.
Database dumps can be incomplete.
A backup may be several days old.
The best backup is one with a tested restoration procedure.
Test the real customer journey after upgrading
Testing should imitate normal customer behaviour.
Start with the storefront.
Check:
homepage;
category pages;
product pages;
search;
filters;
account login;
registration.
Then create an order.
Add a product to cart.
Change quantity.
Apply a promotion.
Log in.
Try guest checkout.
Select delivery.
Select payment.
Complete the order.
Then open the back office.
Check whether:
the order was created;
totals are correct;
taxes are correct;
shipping was stored correctly;
payment status is correct;
stock decreased;
emails were sent;
the order reached external systems.
That is a much more useful test than checking whether pages simply load.
Test multiple countries
For a European store, one successful checkout is not enough.
If the business sells across multiple countries, test several representative markets.
For example:
domestic order;
another EU country;
non-euro currency if supported;
country with a different payment method;
country using another carrier;
country with different tax logic.
Cross-border ecommerce introduces combinations that may not appear in the domestic scenario.
A migration can work perfectly for one country and fail for another.
Test mobile separately
Desktop and mobile should not be considered one test.
On a smartphone, entirely different issues can appear:
navigation no longer opens;
filters cover the screen;
the cart button disappears;
a modal cannot be closed;
parcel-locker maps break;
payment widgets overflow;
the keyboard blocks checkout fields.
At least the primary purchase journey should be completed on a real smartphone.
Browser emulation is useful.
It is not a full replacement for a real device.
Check SEO after the migration
A CMS upgrade can unexpectedly affect organic traffic.
After migration, review:
product URLs;
category URLs;
canonical tags;
robots.txt;
XML sitemap;
meta titles;
meta descriptions;
structured data;
pagination;
redirects;
HTTP status codes.
Existing URLs should not change without a good reason.
If a product previously lived at one address and receives a new URL after migration, search engines need to process that change again.
Across a catalogue containing tens of thousands of pages, an unnecessary URL change can become a significant SEO migration on its own.
A technical CMS upgrade should not accidentally become a full search migration.
Check multilingual SEO
European stores often run several languages.
That adds another checklist:
translated URLs;
hreflang;
canonicals;
language switchers;
translated metadata;
category relationships;
language-specific sitemaps where applicable.
A store can look correct in English while German or French pages quietly return wrong canonicals or missing metadata.
Test several languages after migration.
Not only the default one.
Review accessibility as part of the upgrade
Accessibility has become increasingly important for European ecommerce.
Hummingbird 2.0 was designed with accessibility and European Accessibility Act considerations in mind, which is one reason PrestaShop positions it as the modern foundation for new storefronts.
But upgrading PrestaShop alone does not automatically make a custom storefront compliant.
Accessibility depends on:
theme implementation;
templates;
navigation;
forms;
images;
contrast;
keyboard behaviour;
third-party modules.
If a redesign is planned around the migration, accessibility should be included in the project from the beginning rather than added afterwards.
Measure performance before and after
A newer PrestaShop version does not automatically guarantee a faster store.
Hummingbird was designed as a modern and performance-oriented storefront foundation.
But real performance depends on much more:
theme;
modules;
images;
database;
caching;
hosting;
external JavaScript;
analytics;
tracking tools.
Measure performance before migration.
Then measure again afterwards.
Without a baseline, there is no reliable way to know whether the change improved or damaged the store.
Do not migrate technical clutter automatically
A major upgrade is also an opportunity to clean up.
An old store may contain:
unused modules;
abandoned themes;
temporary files;
obsolete overrides;
forgotten cron jobs;
old tracking scripts;
integrations that are no longer used;
database tables from removed modules.
Not everything should be carried into the new environment.
A good migration does not always mean reproducing the old shop exactly.
Sometimes it means keeping the business functionality while removing years of technical debt.
Upgrade or rebuild?
For very old stores, another option should be considered.
Instead of upgrading through multiple generations of PrestaShop, it may sometimes be cleaner to create a fresh PrestaShop 9 installation and migrate the necessary data.
That can include:
products;
categories;
customers;
orders;
content;
SEO URLs;
relevant historical data.
Then required modules and integrations are installed or rebuilt on the new foundation.
This approach requires careful preparation.
But for a heavily modified legacy store, it can sometimes be more predictable than carrying a decade of old modules and overrides forward.
There is no universal answer.
The condition of the specific store determines the better approach.
When should an upgrade become a priority?
Several warning signs are useful.
The server must remain on an old PHP version
Modern libraries and hosting environments gradually move away from old PHP releases.
Eventually the entire infrastructure becomes constrained.
Important modules no longer support your PrestaShop version
At first it is one module.
Then several.
Soon every new feature requires a workaround.
Development becomes unnecessarily expensive
Developers spend increasing amounts of time maintaining compatibility rather than improving the business.
A redesign or major integration is already planned
If the business is about to invest in a new storefront, mobile app, ERP connection or major functionality, modernising the platform first may reduce duplicated work.
The current version is reaching maintenance-only support
This is already relevant for PrestaShop 8.2.x, which PrestaShop now describes as being in extended support with only security and critical fixes.
When should you avoid rushing the migration?
Even if an upgrade is technically justified, timing matters.
Avoid major production migrations:
just before Black Friday;
immediately before Christmas campaigns;
before a major product launch;
during a large advertising campaign;
without a tested backup;
without staging;
when nobody understands the existing integrations.
An online store has a business calendar.
Technical work should respect it.
A practical PrestaShop 9 migration plan
A controlled project normally looks something like this.
1. Audit the current store
Record the CMS version, PHP, hosting environment, theme, modules, overrides and integrations.
2. Check compatibility
Determine what can be updated, what needs replacement and what requires custom development.
3. Create and verify backups
Back up files and database and confirm there is a working restoration procedure.
4. Create staging
Build a test environment representing production.
5. Upgrade staging
Perform the migration and document every problem encountered.
6. Resolve compatibility issues
Update modules, replace abandoned extensions and fix custom code.
7. Test functionality
Check catalogue, search, accounts, cart, checkout, payments, delivery and external integrations.
8. Test countries and languages
Validate representative markets rather than only the default country.
9. Review SEO and performance
Compare URLs, metadata, structured data, indexing controls and speed against the pre-migration baseline.
10. Plan the production window
Define when the migration happens, who is responsible and how rollback works.
11. Upgrade production
Only after staging has produced a repeatable process.
12. Monitor real orders
Watch payments, carrier integrations, error logs, stock updates and external systems closely after launch.
The core principle is simple:
The production migration should repeat a procedure that has already succeeded elsewhere.
What does PrestaShop 9 actually give a merchant?
Most architectural changes will never be directly visible to customers.
That is normal.
The value of a modern platform is not only a collection of new buttons.
PrestaShop 9 provides a more current technical foundation, including Symfony 6.4 and support for modern PHP versions. PrestaShop 9.1 adds Hummingbird 2.0 as the new default theme for fresh installations.
For merchants, this matters because the platform is being positioned for continued development rather than long-term maintenance of legacy architecture.
That can make future:
integrations;
development;
module compatibility;
storefront improvements;
API work;
easier to manage.
But only when the migration itself is properly controlled.
How this connects to Ewonta
Ewonta stores are built on PrestaShop, so the merchant receives a full ecommerce platform rather than a closed website builder.
The store has its own catalogue, database, modules and the ability to evolve.
That flexibility is valuable.
But it also means that an established shop gradually becomes unique.
Payments, carriers, local market requirements, modules and custom integrations create a configuration that needs to be understood before a major upgrade.
This is where technical PrestaShop support becomes more important than simply installing the newest core package.
A migration should preserve the parts of the store that generate revenue while modernising the foundation underneath them.
The goal is not to upgrade a version number
The objective of migration is not to see 9.1 in the back office.
The objective is to keep the ecommerce platform:
maintainable;
secure;
compatible;
fast enough;
ready for further development.
For one business, migrating now may be the right decision.
Another may first need to replace an abandoned payment module.
A third may schedule the migration after peak season.
A very old store may be better rebuilt on a clean installation.
The worst strategy is usually the same:
Ignore platform maintenance for years until technical debt turns a planned migration into an emergency.
That is why a PrestaShop 9 migration should not begin with the Update button.
It should begin with an audit of the store.