PrestaShop 9.2 vs 9.1.5: Which Version Fits Your Next Step?

For a working PrestaShop 9.1.5 store, the decision is not simply whether 9.2 has more features. It is whether evaluating those features now will resolve a business problem, and which dependencies must be understood before a later production change.

On September 26, 2026, the official release list marks 9.1.5 as the latest stable release and 9.2.0-rc.1 as a pre-release. That makes production maintenance and 9.2 evaluation different activities. Official PrestaShop releases.

This comparison assumes you already operate or maintain the 9.1 branch. It is a decision aid, not an upgrade procedure or a general introduction to PrestaShop 9.

Once the release choice is clear, use the isolated RC1 staging workflow to turn the candidate evaluation into a controlled staging exercise.

Start with the job each version is doing

Your stable store processes real payments, customer communication and fulfillment. Its immediate requirement is reliable operation with supported dependencies. An RC environment answers a different question: can the next release support your workflows, and what needs adapting?

Do not make one environment serve both purposes. A trial that sends real shipping requests or marketing events is no longer merely exploratory. A production deployment made solely to inspect a new feature takes on consequences unrelated to the value of the experiment.

The 9.1.5 announcement includes maintenance and security work on the existing branch. Its description of 9.2 as beta reflects the date that announcement was written; the newer release index now identifies RC1. This is a reminder to compare dates rather than treating every official page as simultaneously current. 9.1.5 announcement.

Record the actual stable baseline you intend to preserve: core version, module versions, theme, active integrations and known local modifications. A comparison against an undocumented store is hard to interpret because apparent differences may come from the baseline rather than the new release.

Compare workflow opportunities, not feature counts

The following table translates the 9.2 direction into questions a store can answer. It does not imply that 9.1.5 lacks every similar outcome; modules and custom development may already provide it.

These new directions are introduced in the official 9.2 announcement sequence. Treat the table as an evaluation framework rather than a guarantee of compatibility. 9.2 beta feature announcement.

The distinction matters for budgeting. “The new release includes a checkout” describes availability. “Our delivery-date extension and payment module pass the new flow” describes evidence. Only the second can support a store-specific adoption decision.

Separate shared fixes from genuine release differences

A long changelog can exaggerate the apparent distance between two versions if every listed fix is counted as unique to one branch. Work may be backported. A later announcement can also repeat improvements already discussed during a beta.

When a particular fix motivates your decision, verify the relevant release or commit evidence for both baselines. Do not infer that a bug exists in 9.1.5 merely because a 9.2 changelog mentions it. Conversely, do not assume two similarly named fixes cover the same behavior.

A practical comparison record has four fields: the observed problem, the current store’s reproducible case, the upstream change that may address it, and the result of that case on the candidate. This avoids choosing a release based on an issue title alone.

For example, if a shipping integration fails after an address change, preserve the exact cart, countries, module versions and action sequence. A changelog entry about delivery state is a lead to investigate. It is not proof that your integration’s failure has been fixed.

Also distinguish a missing capability from a broken capability. If your existing module supports a business rule that the candidate flow does not expose, no amount of regression testing will establish parity. That gap requires a product or integration decision.

Three stores can reach different conclusions

A merchant approaching a seasonal campaign

Imagine a shop whose current checkout works and whose immediate challenge is a large promotional campaign. The useful action is to keep the stable environment maintained and time-box a separate candidate review. The campaign does not become safer because a newer interface exists.

Choose one or two critical scenarios for the first evaluation: the promotion’s voucher behavior and the payment methods customers use most. If those reveal dependencies needing work, record them for a later project. The evaluation has served its purpose without disrupting the campaign.

An agency maintaining a customized Back Office

An agency may have a stronger reason to investigate early even if merchants are not ready to adopt the next release. Finding extension breakage while the candidate is open for feedback leaves time to adapt and report it.

Here the benefit is preparation. Build a map from each customization to its page, form, grid or route dependency. Exercise the relevant candidate paths and estimate the adaptation effort. The decision can be “continue supporting production on 9.1.5 while qualifying the extension on 9.2 RC1.” That is a coherent technical plan.

A merchant dependent on a third-party checkout

A merchant paying for checkout customizations may want to evaluate the native alternative. Begin with a parity inventory: fields, carrier widgets, payment behavior, error recovery and customer-account rules.

If the existing checkout solves specialized business needs, the native option may still require development. If those needs are modest, a focused prototype could clarify whether the alternative is viable. Neither outcome follows from the word “native” alone.

These scenarios are illustrative. They do not report outcomes from customer stores or claim that one release has a measured commercial advantage.

Put dependency evidence ahead of assumptions

Ask vendors specific questions. “Does your module support PrestaShop 9?” is too broad for a new checkout or an experimental page path. Ask which core and module versions were exercised, which theme was used, and whether the feature relevant to your store was enabled.

A useful evidence hierarchy is a reproducible test result, a documented support statement with version boundaries, and an unresolved assumption. Keep those categories distinct in the comparison. Silence from a vendor is an open dependency, not a passing test.

For internal modules, use the same discipline. A package that installs successfully may still fail when saving a form, processing an asynchronous notification or executing a scheduled task. Choose acceptance cases from actual business operations.

Do not use the presence of an experimental interface as justification for a long-term support promise. The developer notes explicitly qualify parts of the 9.2 work. Pin the implementation used for evaluation and revisit the contract when the stable release is published. Version-specific developer notes.

Write the decision before scheduling the next step

A release decision should state what happens now, what evidence is missing and what would change the decision. For example:

Keep production on its maintained stable baseline. Evaluate the candidate checkout on a disposable installation. Revisit adoption after a stable 9.2 release is available and the payment, pickup and voucher scenarios pass with supported module versions.

That statement is more useful than “wait until it is ready,” because it names the readiness conditions. It also avoids committing to an invented release date.

Estimate work in separate categories: compatibility investigation, necessary code changes, staff workflow review, future deployment preparation and support handover. A small core-version difference does not guarantee a small project when several integrations change behavior together.

If the candidate solves no current problem and you do not maintain affected extensions, a short discovery review may be enough for now. If it introduces a capability central to your roadmap, invest in a deeper prototype. Keep the prototype’s results and limitations so the next review starts from evidence rather than memory.

A decision record also needs an expiry condition. Revisit it when the official stable release appears, when a critical dependency publishes support or when the business requirement changes. Without such a trigger, a sensible temporary decision can become an indefinite assumption that nobody owns.

Questions that should not decide the comparison alone

Is 9.2 newer? Yes, but release status and dependency readiness determine where it belongs. Newness does not establish production suitability.

Does a successful clean installation prove compatibility? It proves that one installation completed. It does not prove that your theme, integrations, business rules or historical data behave correctly.

Should we wait for a particular stable date? Use the official release announcement when it exists. A readiness plan should name conditions, not rely on an unverified date.

The practical choice today is usually two coordinated tracks: preserve dependable operation on the stable branch and investigate the 9.2 capabilities that matter to your store. A later production decision can then rely on a final release and store-specific evidence.

For the underlying platform context, see our safe PrestaShop 8-to-9 upgrade guide and apply the version-specific checks above to the installation you are evaluating.