Ho iniziato a lavorare su Magento nel 2011. Da allora ho visto passare mode, refactoring, acquisizioni e almeno tre generazioni di “next big thing” nell’e-commerce. Ma il countdown che scade il 30 giugno 2020 è diverso da tutto il resto: è una data secca, oltre la quale Magento 1 smette di ricevere supporto ufficiale. Mancano circa sei settimane. E la mia posizione, dopo mesi passati a ripeterla nelle call con i merchant, è netta: chi è ancora su Magento 1 e sta ancora “valutando” non ha un problema tecnico, ha un problema di decisione.
Cosa succede davvero il 30 giugno 2020
Facciamo chiarezza, perché in giro circolano due letture opposte e sbagliate: chi pensa che il sito si spegnerà da solo (falso) e chi pensa che non cambi nulla (peggio). La verità sta in mezzo, ed è più scomoda di entrambe.
Dal 30 giugno 2020 Magento 1 non riceve più patch di sicurezza né correzioni ufficiali. Il tuo store continuerà a funzionare e a incassare ordini il 1° luglio esattamente come il 30 giugno. Il punto non è la disponibilità del sito: è che ogni nuova vulnerabilità scoperta da lì in avanti resterà aperta, senza una patch rilasciata da Magento. E le vulnerabilità su una piattaforma tanto diffusa vengono scoperte in continuazione.
C’è poi un secondo tema che i merchant sottovalutano sistematicamente: la compliance PCI DSS. Uno standard che, in sintesi, richiede di mantenere i sistemi aggiornati e privi di vulnerabilità note. Una piattaforma che non riceve più patch di sicurezza rende molto difficile — nei fatti impossibile — dimostrare quel requisito. Se gestisci pagamenti con carta, e cioè se sei un e-commerce, questo non è un dettaglio da rimandare al prossimo quarter: è un rischio che scarichi direttamente sul tuo business e, in caso di data breach, sulla tua responsabilità.
Lo dico senza giri di parole: restare su Magento 1 dopo il 30 giugno 2020 significa gestire uno store con vulnerabilità note e senza copertura ufficiale. Si può fare — con patch di terze parti, con hardening, con un WAF davanti — ma è una gestione del rischio, non una soluzione. E ha una data di scadenza anche quella.
Perché Magento 2 non è un upgrade: è un re-platform
Qui casca il progetto della maggior parte dei merchant con cui parlo. La parola “migrazione” evoca un pulsante, una notte di manutenzione, un backup e via. Con Magento 1 → Magento 2 non funziona così, e chi te lo racconta in quei termini ti sta preparando un fallimento.
Magento 2 è stato riscritto. Architettura diversa, code base diversa, filosofia diversa. In pratica significa tre cantieri, non uno.
1. Il tema (frontend)
Il tuo tema Magento 1 non si porta dietro. Il sistema di templating è cambiato, il frontend gira su una stack diversa. Il tema va rifatto. Questo, paradossalmente, è spesso una buona notizia: è l’occasione per ripulire anni di personalizzazioni stratificate e ripensare le performance. Ma va messo a budget come sviluppo, non come porting.
2. Le estensioni (moduli)
Ogni modulo di terze parti installato su Magento 1 va sostituito con la versione Magento 2, quando esiste. E non sempre esiste. Ho visto merchant scoprire a metà progetto che l’estensione custom su cui girava la loro logica di sconti, o l’integrazione con il gestionale, semplicemente non aveva un equivalente pronto. In quei casi si sviluppa da zero. Il primo lavoro serio di una migrazione, prima ancora di scrivere una riga di codice, è l’inventario delle estensioni: cosa uso davvero, cosa ha un corrispettivo, cosa va riscritto, cosa posso finalmente buttare.
3. I dati
Prodotti, clienti, ordini, categorie: si migrano con il Data Migration Tool ufficiale, ma non è un dump-and-restore. Struttura del database diversa, mapping da verificare, dati sporchi accumulati negli anni che vengono a galla proprio nel momento peggiore. La migrazione dati è la parte più “tecnica” e apparentemente più automatizzabile, ma è anche quella dove un controllo superficiale ti fa scoprire in produzione che gli storici ordini o gli attributi custom si sono persi per strada.
Il riassunto onesto è questo: una migrazione da Magento 1 a Magento 2 è un progetto di re-platform, con analisi, sviluppo e testing, non un aggiornamento di versione. Chi la tratta come una patch la paga due volte.
Come la affronto io
Non esiste il bottone magico, ma esiste un metodo che riduce i disastri. Quello che applico, in ordine, è:
- Audit dell’esistente. Traffico, catalogo, estensioni realmente in uso, integrazioni, personalizzazioni. Serve a distinguere ciò che è business-critical da ciò che ci trasciniamo dietro per abitudine.
- Decisione sull’edition e sull’hosting. Magento 2 Open Source o Commerce, on-premise o cloud: dipende dai volumi e dalle esigenze, non dalle mode.
- Ricostruzione del tema con un occhio alle performance, non come clone pixel-perfect del vecchio store.
- Gestione delle estensioni: mappatura, sostituzione, sviluppo di ciò che manca.
- Migrazione dati controllata, con verifiche su campioni reali e non solo sui totali.
- Testing e go-live pianificato, con un piano di rollback. Il giorno del switch non è il momento per scoprire le sorprese.
La cosa più importante non è nell’elenco: è il tempo. Un re-platform serio non si chiude in due settimane, e a sei settimane dalla fine del supporto la finestra per farlo con calma prima del 30 giugno è di fatto chiusa. Ed è esattamente qui che voglio essere scomodo.
La mia posizione su chi continua a rimandare
Questa scadenza si conosce da tre anni. Non è arrivata a sorpresa. Chi oggi è ancora su Magento 1 senza un progetto avviato non è stato sfortunato: ha deciso, consapevolmente o meno, di non decidere.
Lo capisco, sul serio. Migrare costa, distrae dal quotidiano, e finché lo store vende sembra sempre esserci qualcosa di più urgente. Ma il conto del rimando non sparisce, si accumula. Chi parte adesso non arriverà in tempo per il 30 giugno e dovrà gestire una finestra di rischio con patch non ufficiali. Chi parte “dopo l’estate” quella finestra la allunga a mesi, su una piattaforma sempre più esposta e sempre più difficile da far certificare PCI.
La mia posizione netta: la migrazione da Magento 1 non è più una scelta strategica, è manutenzione obbligatoria. Il momento giusto per iniziare era un anno fa. Il secondo momento migliore è questa settimana. “Rimandare ancora” non è un’opzione, è solo un modo più lento di prendere la stessa decisione, pagandola di più.
Mini-FAQ
Il mio sito Magento 1 smette di funzionare il 30 giugno 2020?
No. Continua a funzionare, ma non riceve più patch di sicurezza né correzioni ufficiali da quella data.
Migrare da Magento 1 a Magento 2 è un aggiornamento automatico?
No. È un re-platform: tema, estensioni e dati vanno ricostruiti o migrati, non semplicemente aggiornati.
Che rischio corro restando su Magento 1 dopo il 30 giugno?
Vulnerabilità di sicurezza senza patch ufficiali e serie difficoltà a mantenere la compliance PCI DSS.
Faccio in tempo a migrare entro il 30 giugno 2020?
Un re-platform serio richiede più di sei settimane. Realisticamente si gestisce una finestra di rischio post-scadenza: meglio iniziare subito e ridurla il più possibile.
Fabio Canovi — Esperto di Magento e Adobe Commerce. Lavoro su Magento dal 2011, progettando e gestendo store per merchant mid-market. Sono tra i primi in Italia ad aver conseguito la certificazione Adobe Commerce.