PrestaShop 8 a fine supporto: conviene migrare alla 9?

Che cosa significa davvero «supporto esteso»

Da luglio 2025 PrestaShop 8 è passato al supporto esteso. Non è la fine del supporto, ma non è più un mantenimento completo: il ramo 8.x riceve soltanto le correzioni dei bug critici, le patch di sicurezza e gli adeguamenti indispensabili degli hook. Le nuove funzionalità vanno esclusivamente sulla versione 9. La fine effettiva del supporto arriverà con l'uscita di PrestaShop 10.

In altre parole, la domanda «PrestaShop 8 è a fine supporto, devo migrare?» non riguarda un guasto imminente. Riguarda il debito tecnico che si accumula.

I tre fatti tecnici che pesano davvero

PHP. PrestaShop 8 si ferma a PHP 8.1, il cui supporto di sicurezza ufficiale è terminato. PrestaShop 9 accetta da PHP 8.1 a 8.4. Prima o poi il suo hosting provider ritirerà PHP 8.1 dal parco server, e la scelta non sarà più sua.

Symfony. PrestaShop 8 si basa su Symfony 4.4, a fine vita e senza backport di sicurezza. PrestaShop 9 è passato a Symfony 6.4 LTS, mantenuto in correzioni fino a fine 2026 e in sicurezza fino a fine 2027. Il team PrestaShop ha dichiarato esplicitamente che per il ramo 8.x non è previsto alcun backport.

Node.js. La compilazione dei temi in versione 9 richiede Node 20 o superiore. È il dettaglio che coglie di sorpresa le agenzie che lavorano ancora con un ambiente di build datato.

Che cosa si rompe davvero passando alla 9

La migrazione dalla 8 alla 9 non è un semplice cambio di versione. Ecco le rotture che generano il grosso del lavoro:

• Librerie rimosse dal core: Swift Mailer sostituito da Symfony Mailer, Guzzle da Symfony HTTP Client, League Tactician da Symfony Messenger. Qualsiasi modulo che dichiara use GuzzleHttp\... produce un errore fatale.
• Controller di amministrazione: FrameworkBundleAdminController è deprecato a favore di PrestaShopAdminController. I controller vanno dichiarati come servizi con dependency injection.
• Bundle eliminati: sensio/framework-extra-bundle sparisce, quindi le annotazioni di rotta e di template smettono di funzionare.
• Autenticazione del back office interamente portata su Symfony: i moduli SSO o di autenticazione a due fattori sviluppati in casa che si appoggiavano al vecchio cookie smettono di funzionare.
• Tema: Hummingbird diventa il tema predefinito. Abbandona Bootstrap e rompe le personalizzazioni scritte per Classic. Classic resta comunque distribuito, il che permette di prendere tempo.

La griglia di decisione

Resti sulla 8 per ora se il negozio è stabile, il suo hosting continua a offrire PHP 8.1, dipende da moduli di terze parti il cui editore non ha ancora pubblicato una versione compatibile con la 9 ed è in piena stagione di vendite. In questo caso applichi con rigore ogni patch di sicurezza 8.2.x.

Pianifichi la migrazione entro 6-12 mesi se il negozio è un asset centrale, se sviluppa nuove funzionalità con regolarità o se il suo tema è pesantemente personalizzato. Più aspetta, più il divario fra il suo codice e il core si allarga.

Valuti un rifacimento invece di una migrazione se il tema è anteriore al 2020, se ha accumulato più di dieci override o se più della metà dei moduli di terze parti non è più mantenuta. In questo scenario migrare costa spesso più che ricostruire da zero, e il risultato è peggiore.

Come stimare i costi in modo onesto

L'audit preliminare è la fase più redditizia dell'intero progetto. Consiste nel rispondere a quattro domande:

1. Quanti moduli di terze parti, e quanti hanno già una versione compatibile con la 9?
2. Quanti override in override/, e servono ancora?
3. Quanti template sovrascritti nel tema, e quanto si discostano dal tema padre?
4. Quanto codice su misura è stato sviluppato?

Un audit fatto bene richiede una o due giornate e trasforma un preventivo approssimativo in un piano di lavoro affidabile. Permette anche di scoprire che certi override rispondono a un'esigenza abbandonata da tempo, e che la migrazione sarà più leggera del previsto.

Non migri mai senza un piano di rollback

Tre precauzioni non negoziabili:

• un ambiente di staging identico alla produzione, su cui far girare la migrazione completa prima di qualsiasi intervento sul sito reale;
• un piano di collaudo scritto che copra il checkout, i pagamenti, i corrieri, le email transazionali e le esportazioni contabili;
• una finestra di passaggio con un backup ripristinabile e un criterio di fallimento deciso in anticipo.

Se l'aggiornamento è già partito e si è bloccato, il nostro articolo sull'Update Assistant affronta gli errori più comuni. E se parte da una versione più vecchia, il percorso è diverso: veda la migrazione da PrestaShop 1.6.

Far analizzare il suo negozio

Realizziamo l'audit di compatibilità, quantifichiamo la migrazione e la eseguiamo con un piano di rollback. Scopra il nostro approccio nella pagina migrazione PrestaShop.