Molti negozi online costruiti tra il 2010 e il 2017 girano ancora su Magento 1. Il catalogo è curato, le estensioni fanno quello che servono, il personale conosce il pannello di amministrazione a memoria. Il problema è che Adobe ha pubblicato le ultime patch ufficiali per Magento 1 nel giugno 2020, e quasi sempre il negozio è rimasto anche su un PHP fuori supporto, perché il codice originale non è stato scritto per PHP 8.
Nel 2026 le strade realistiche sono due: migrare a Magento 2, cioè Adobe Commerce o Magento Open Source, oppure passare a OpenMage LTS, il fork comunitario che continua a sviluppare il codice di Magento 1. In questo articolo vediamo cosa comporta ciascuna, con i requisiti di PHP verificati sulle fonti ufficiali, i passaggi tecnici principali e i criteri per scegliere senza farsi guidare solo dall’urgenza.
Dove siamo a ottobre 2026
Il supporto di Magento 1, sia nell’edizione Open Source sia in quella Commerce, è terminato il 30 giugno 2020. Da allora Adobe non rilascia più correzioni di sicurezza per quel codice. Magento 2 ha invece un ciclo di vita pubblicato: ogni versione della serie 2.4 ha tre anni di supporto standard dalla data di disponibilità, e alcune versioni hanno un anno aggiuntivo di supporto esteso. Le date sono pubblicate nella politica sul ciclo di vita di Adobe Commerce.
Due dettagli contano per chi pianifica. Il primo: le date di Adobe si riferiscono ad Adobe Commerce, e chi usa Magento Open Source deve verificare quali correzioni sono disponibili per la propria versione. Il secondo: ogni versione di Magento 2 supporta solo pochi rami di PHP. La 2.4.8 richiede PHP 8.3 o 8.4, la 2.4.9, disponibile da maggio 2026, richiede PHP 8.5, secondo i requisiti di sistema pubblicati da Adobe. Migrare a Magento 2 significa quindi anche portare il server su un PHP moderno.
Perché restare su Magento 1 è un problema anche se funziona
Un e-commerce è il tipo di applicazione più esposto che un’azienda possa avere: è pubblico, accetta dati personali, gestisce pagamenti e ha un pannello di amministrazione raggiungibile da Internet. Su Magento 1 senza manutenzione si sommano tre livelli di rischio.
- Il codice di Magento: le vulnerabilità scoperte dopo giugno 2020 non hanno una correzione ufficiale;
- le estensioni: molti fornitori hanno smesso di aggiornare i moduli per Magento 1, compresi quelli di pagamento e spedizione;
- PHP e il sistema operativo: i negozi su Magento 1.9 girano spesso su PHP 5.6 o 7.x, rami senza patch ufficiali da anni, su server che a loro volta non si possono aggiornare.
A questo si aggiunge la conformità. Chi accetta pagamenti con carta deve rispettare PCI DSS, che chiede di gestire le vulnerabilità note e di applicare le patch critiche in tempi brevi. Un negozio su una piattaforma senza patch ufficiali, ospitato su un PHP fuori supporto, è difficile da giustificare in una verifica senza un piano documentato.
Strada uno: migrare a Magento 2
Magento 2 condivide con Magento 1 il nome e molti concetti, come prodotti configurabili, store view, regole di prezzo, ma è una piattaforma diversa. Cambiano l’architettura, il sistema dei moduli, la struttura del database, il modo in cui si scrivono temi ed estensioni. Per questo il passaggio è un progetto di replatforming e va trattato come tale.
I dati con il Data Migration Tool
Per i dati Adobe mette a disposizione il Data Migration Tool, che legge il database di Magento 1 e scrive in quello di Magento 2. Secondo la documentazione del progetto supporta come origine Magento Open Source dalla 1.6 alla 1.9 e Magento Commerce dalla 1.11 alla 1.14, e trasferisce prodotti, clienti, ordini, configurazione dei negozi e promozioni. La versione del tool deve coincidere esattamente con quella di Magento 2 installata. Il lavoro si svolge in tre fasi, nell’ordine indicato da Adobe:
# Installa il tool nella stessa versione di Magento 2 (qui 2.4.8)
composer require magento/data-migration-tool:2.4.8
# 1. Impostazioni: siti, negozi, configurazione di sistema
bin/magento migrate:settings /percorso/assoluto/config.xml
# 2. Dati: catalogo, clienti, ordini, promozioni
bin/magento migrate:data /percorso/assoluto/config.xml
# 3. Delta: ordini e modifiche arrivati su Magento 1 dopo la fase 2
bin/magento migrate:delta /percorso/assoluto/config.xmlLa fase di delta è quella che permette di lasciare il vecchio negozio aperto durante i test: il tool installa dei trigger sulle tabelle di Magento 1 e, a ogni esecuzione, trasferisce solo i record cambiati. Le immagini dei prodotti non passano dal database e vanno copiate a parte. Prima di lanciare la migrazione vanno fermati i cron di Magento 1, e i file di mappatura vanno adattati ai campi e alle tabelle aggiunti dalle estensioni, altrimenti il tool si ferma segnalando le differenze.
Tema, estensioni e integrazioni
Il Data Migration Tool non tocca il codice. Il tema di Magento 1 non funziona su Magento 2 e va ricostruito, partendo da un tema di base o da uno commerciale. Ogni estensione va sostituita con la versione per Magento 2, se esiste, o riscritta. Le personalizzazioni fatte nel core o nelle cartelle local vanno analizzate una per una per capire se servono ancora. Le integrazioni con gestionali, corrieri e marketplace vanno rifatte sulle API di Magento 2.
Il vantaggio è che, alla fine, il negozio è su una piattaforma con un fornitore, un calendario di patch e un ecosistema di estensioni attivo. Lo svantaggio è il costo: tempo di sviluppo, nuovi requisiti di infrastruttura come OpenSearch, e un periodo di adattamento per chi usa il pannello ogni giorno.
Strada due: passare a OpenMage LTS
OpenMage LTS è un progetto comunitario, non ufficiale, che ha preso il codice di Magento 1 e lo mantiene: integra correzioni di sicurezza e bug proposte dalla comunità e lo adegua alle versioni recenti di PHP. La serie 19.x era in gran parte compatibile con Magento 1.9.4, la serie 20.x, oggi quella principale, introduce cambiamenti che possono richiedere adeguamenti alle estensioni.
Secondo la documentazione dei requisiti, dalla versione 20.14 OpenMage richiede PHP 8.1 o superiore, con PHP 8.4 e 8.5 supportati ma con possibili avvisi nei log, e MySQL dalla 5.6 o MariaDB. Il progetto dichiara che la serie 20.x riceverà aggiornamenti fino a due anni dopo il rilascio della 21.x, che a ottobre 2026 è ancora in versione beta.
Cosa si guadagna e cosa no
Il guadagno principale è la continuità. Il database resta quello, il pannello resta quello, il tema e buona parte delle estensioni possono essere adattati invece che rifatti. Il negozio torna su un ramo di PHP supportato e su un codice che riceve ancora correzioni.
I limiti vanno messi in conto con la stessa onestà. OpenMage è mantenuto da volontari: non c’è un contratto, non ci sono tempi garantiti per le correzioni. L’ecosistema di estensioni commerciali per Magento 1 si è ridotto molto, e un modulo di pagamento non più aggiornato dal fornitore va adeguato da chi gestisce il negozio. Infine, il codice delle estensioni scritte per PHP 5 va comunque portato a PHP 8: OpenMage aggiorna il core e lascia il codice di terze parti a chi gestisce il negozio.
Come scegliere
Non esiste una scelta giusta in assoluto. Conta quanto il negozio è personalizzato, quanto vale per l’azienda, quanto a lungo deve durare e quali risorse ci sono per mantenerlo. La tabella riassume i criteri che usiamo nella prima analisi.
| Criterio | Porta verso Magento 2 | Porta verso OpenMage |
|---|---|---|
| Orizzonte | il negozio deve durare molti anni e crescere | serve stabilità per un periodo limitato o in attesa di un nuovo progetto |
| Estensioni | molte estensioni commerciali senza aggiornamenti per Magento 1 | poche estensioni, quasi tutte sviluppate in casa |
| Tema | il tema va comunque rifatto | il tema funziona e va solo adeguato |
| Supporto | serve un fornitore con un calendario di patch | c’è un team in grado di seguire il progetto comunitario |
| Budget e tempi | possibile un progetto di replatforming | servono tempi brevi e un investimento contenuto |
Una possibilità spesso sottovalutata è combinare le due strade: passare prima a OpenMage per portare il negozio su un PHP supportato in tempi brevi, e pianificare con calma la migrazione a Magento 2 o a un’altra piattaforma. Ha senso quando il replatforming richiede mesi e il negozio non può restare esposto nel frattempo. Ne parliamo in generale nell’articolo su backport o migrazione.
Proteggere il negozio durante la transizione
Qualunque strada si scelga, il lavoro richiede settimane o mesi, e il negozio attuale resta in produzione. In quel periodo va protetto con misure concrete.
- PHP: se il negozio gira su un ramo in End of Life, il backport delle patch di sicurezza sul pacchetto in uso chiude le vulnerabilità note senza toccare l’applicazione;
- pannello di amministrazione: un percorso non standard, l’accesso limitato per indirizzo IP o tramite VPN e l’autenticazione a due fattori riducono molto la superficie di attacco;
- integrità dei file: un controllo periodico sui file del negozio e sui blocchi CMS permette di accorgersi presto di codice iniettato nelle pagine di pagamento;
- estensioni inutilizzate: i moduli disattivati ma ancora presenti vanno rimossi, perché il loro codice resta raggiungibile;
- copie di sicurezza: database e file vanno salvati con regolarità e le copie vanno provate con un ripristino reale.
Le misure di protezione servono a guadagnare il tempo necessario per migrare.
Da dove partire
Prima di scegliere tra Magento 2 e OpenMage serve un inventario. Sono le stesse domande che poniamo noi all’inizio di ogni analisi:
- quale versione esatta di Magento 1 è installata e quali patch di sicurezza sono state applicate;
- su quale versione di PHP e su quale sistema operativo gira il negozio;
- quante estensioni sono installate, chi le ha sviluppate e se esiste una versione per Magento 2 o una compatibile con OpenMage;
- quali file del core sono stati modificati direttamente;
- quali integrazioni esterne dipendono dal negozio, come gestionale, corrieri, marketplace e fatturazione;
- quanti dati ci sono da trasferire e quali tabelle sono state aggiunte dalle estensioni.
Con queste risposte la decisione smette di essere una scommessa. Per gli aspetti che riguardano ordini, clienti e posizionamento nei motori di ricerca durante il passaggio, comuni a ogni piattaforma, rimandiamo all’articolo su come migrare un e-commerce su PHP legacy. Se vuoi un parere sul tuo negozio, contattaci indicando versione di Magento, di PHP e sistema operativo.
In breve
Magento 1 non riceve patch ufficiali dal 30 giugno 2020 e quasi sempre trascina con sé un PHP fuori supporto. La migrazione a Magento 2 porta il negozio su una piattaforma con date di supporto pubblicate e PHP 8.3, 8.4 o 8.5, ma richiede di rifare tema, estensioni e integrazioni, mentre il Data Migration Tool trasferisce dati e configurazione in tre fasi. OpenMage LTS mantiene il codice di Magento 1, richiede PHP 8.1 o superiore e permette di conservare database e gran parte del negozio, con il limite di un supporto comunitario senza garanzie. La scelta dipende da orizzonte, estensioni e risorse, e le due strade si possono combinare. Nel frattempo il negozio in produzione va protetto, a partire da PHP e dal pannello di amministrazione.
