Nel 2011 ho cominciato a lavorare su Magento 1, quindi permettetemi di partire da un’ammissione: quando è arrivata la data di end-of-life, il 30 giugno 2020, ero convinto che nove mesi dopo il tema sarebbe stato archiviato. Mi sbagliavo. A nove mesi da quel giorno, e a distanza di anni da quando l’addio era stato annunciato, continuo a trovare merchant che girano su Magento 1 in produzione. Alcuni per scelta, molti per inerzia. E la fotografia del campo è più interessante di quanto la parola “migrazione” lasci intendere.
Ho passato buona parte degli ultimi mesi tra progetti di re-platform già chiusi, altri in corsa e un paio di situazioni che definirei di pronto soccorso. Provo a raccontare cosa ho visto, senza retorica.
Chi ha migrato per tempo (e cosa ha fatto di diverso)
I merchant che sono arrivati alla scadenza con serenità hanno una cosa in comune: non hanno trattato la migrazione come un porting, ma come un progetto e-commerce nuovo. Chi si è mosso nel 2018-2019 ha avuto il lusso del tempo, e il tempo su un re-platform vale più del budget.
Un caso che porto spesso come esempio, ovviamente anonimo: un merchant fashion attorno ai 15M di GMV che ha iniziato il discovery quasi diciotto mesi prima del go-live. Non ha migrato “tutto”. Ha fatto pulizia del catalogo, ha buttato tre quarti delle third-party extension che si era portato dietro negli anni, ha rivisto il checkout invece di riprodurlo identico. Risultato: il progetto è costato di più nella fase di analisi e meno in quella di sviluppo, ed è andato online una volta sola. Questo è il punto che mi interessa.
Chi ha migrato bene ha anche accettato una verità scomoda: il data migration tool ufficiale sposta i dati, non le decisioni. Sposta ordini, clienti e catalogo, non ti dice quali categorie servono ancora o perché avevi dodici gruppi cliente. Quelle scelte restano tue, e vanno prese prima, non durante il deploy.
Chi è ancora su Magento 1 (e i rischi veri che corre)
Poi c’è chi è rimasto. Qui distinguo due categorie, perché fare di tutta l’erba un fascio è ingiusto.
La prima è fatta di merchant piccoli, con un negozio semplice e un fatturato che non giustifica una spesa a sei zeri. Li capisco. Ma “capirli” non vuol dire dire loro che va bene, perché i rischi sono concreti e non teorici.
- Security. Da fine giugno 2020 non arrivano più patch ufficiali. Ogni vulnerabilità scoperta dopo quella data resta aperta a meno di non affidarsi a fix di terze parti. Le campagne di skimming sui pagamenti (il cosiddetto Magecart) hanno colpito soprattutto store non aggiornati: non è un rischio ipotetico, è cronaca degli ultimi due anni.
- PCI-DSS. Girare software non più supportato mette in tensione la compliance. Un merchant che tratta carte su una piattaforma end-of-life ha un problema di conformità, non solo di sicurezza tecnica.
- Ecosistema che si spegne. Le extension che usavi non vengono più aggiornate, i fornitori di pagamento aggiornano le loro integrazioni solo sulle versioni recenti, e trovare uno sviluppatore che voglia mettere le mani su Magento 1 diventa ogni mese più difficile e più caro.
La seconda categoria è quella che mi preoccupa davvero: merchant strutturati, con volumi importanti, ancora su Magento 1 non per scelta ma perché il progetto di migrazione si è impantanato. Spesso è il sintomo di un problema organizzativo, non tecnico. E su questo torno tra poco.
Gli errori tipici delle migrazioni fatte di fretta
Le migrazioni partite tardi, sotto la pressione della scadenza, tendono a ripetere gli stessi errori. Li elenco perché sono prevedibili, e quindi evitabili.
- Il porting 1:1. “Rifacciamolo uguale, ma su Magento 2.” È l’istruzione più costosa che un merchant possa dare. Riproduci anche gli errori, ti porti dietro il technical debt, e paghi per ricostruire funzionalità che nel frattempo la piattaforma offre già di serie. Migrare uguale significa migrare due volte.
- Le extension trascinate senza inventario. Ho visto store che volevano riportare quaranta moduli di terze parti senza chiedersi se ne usassero ancora la metà. Ogni extension è un costo di licenza, di integrazione e di manutenzione futura. La migrazione è il momento buono per fare pulizia, non per accumulare.
- Il catalogo sporco. Migrare dati sporchi produce uno store nuovo con problemi vecchi. SKU duplicati, attributi orfani, immagini mancanti: se non li sistemi prima, te li ritrovi identici dall’altra parte.
- Sottovalutare l’infrastruttura. Magento 2.4 richiede Elasticsearch, PHP recenti, un approccio Composer-based. Chi arriva da Magento 1 spesso ragiona ancora con l’hosting di cinque anni fa e scopre in ritardo che l’ambiente va ripensato.
- Nessun code freeze, nessuna gestione del delta. Il vecchio store continua a vendere durante la migrazione. Ordini, clienti e stock cambiano ogni giorno. Chi non pianifica la sincronizzazione del delta finale si ritrova al go-live con dati disallineati e un fine settimana da incubo.
La mia opinione: come si affronta un re-platform senza rifarlo due volte
Vengo alla parte in cui espongo la mia posizione, che qualcuno non condividerà.
Un re-platform non è un progetto tecnico, è un progetto di prodotto travestito da progetto tecnico. Il codice è la parte facile. La parte difficile è decidere cosa tenere, cosa buttare e cosa fare diversamente, e queste decisioni non le prende lo sviluppatore: le prende chi conosce il business. Quando un merchant delega tutto al fornitore e sparisce fino al collaudo, il progetto va storto. Sempre.
La mia regola pratica, sintetizzabile in una riga: investire nel discovery quello che si è tentati di risparmiare, perché ogni euro non speso in analisi ne costa tre in sviluppo e dieci in rilavorazione. Un discovery serio significa mappare i processi reali, non quelli che credi di avere, e arrivare al kick-off con uno scope definito. Lo scope creep è la vera causa dei progetti rifatti due volte, non la piattaforma.
Terza cosa: non serve migrare tutto lo stesso giorno. Su store complessi preferisco un approccio a fasi, con un MVP che va online e una roadmap per il resto. Meglio un go-live più povero ma stabile che un big bang che tiene ostaggio l’azienda per un anno. Ho visto progetti “completi” restare bloccati in staging per mesi, mentre il vecchio Magento 1 continuava a incassare rischi.
Se dovessi riassumere: chi è rimasto indietro raramente lo è per motivi tecnici. Lo è per una decisione rimandata. La tecnologia dà le scadenze; la disciplina di progetto determina chi le rispetta.
Domande frequenti
Magento 1 è ancora sicuro da usare?
No. Dal 30 giugno 2020 Magento 1 non riceve più patch di sicurezza ufficiali. Ogni vulnerabilità scoperta dopo quella data resta esposta, con impatti diretti su sicurezza dei pagamenti e conformità PCI-DSS.
Migrare a Magento 2 significa rifare tutto il sito?
Di fatto sì: Magento 2 ha un’architettura diversa e non consente un aggiornamento in-place. Il codice e i temi vanno ricostruiti. Dati come ordini, clienti e catalogo si trasferiscono con il data migration tool ufficiale, ma le decisioni su cosa tenere restano da prendere.
Quanto dura in media una migrazione da Magento 1 a Magento 2?
Dipende dalla complessità, ma per uno store strutturato è realistico parlare di diversi mesi tra discovery, sviluppo e go-live. La fase più sottovalutata, e quella che fa la differenza, è l’analisi iniziale.
L’errore più comune in una migrazione fatta di fretta?
Il porting 1:1: ricostruire lo store identico al precedente. Riproduce il technical debt e obbliga a rifare il lavoro due volte. La migrazione va usata per fare pulizia, non per fotocopiare il passato.
Fabio Canovi — esperto di Magento e piattaforme e-commerce enterprise, tra i primi in Italia a certificarsi sulla piattaforma commerce enterprise di Magento. Lavoro su Magento dal 2011, progettando e gestendo store per merchant mid-market.