L’11 agosto 2026 è terminato il supporto standard di Adobe Commerce 2.4.6. Non è successo niente di visibile: i negozi su 2.4.6 hanno continuato a prendere ordini il 12 agosto esattamente come il 10. Però da quel giorno la conversazione con i clienti è cambiata, e la domanda che mi arriva più spesso non è “quando facciamo l’upgrade” ma “quanto ci mettiamo, se ci facciamo aiutare dall’AI”.
La risposta breve è che l’AI non fa l’upgrade. La risposta lunga è più interessante, perché c’è un pezzo del lavoro dove un agente serve davvero, e non è quello che la gente immagina.
Che cosa è scaduto davvero
Prima i fatti, perché su questo tema girano parecchie semplificazioni. Il supporto standard di 2.4.6 è finito l’11 agosto 2026, quello esteso arriva al 31 agosto 2027, le sole patch di sicurezza fino al 31 maggio 2028. Nello stesso giorno della scadenza Adobe ha pubblicato anche un aggiornamento di sicurezza (APSB26-92).
Quindi no, il 12 agosto non ti sei svegliato con un sito insicuro. Hai una finestra, ed è ampia. È il tempo che hai per pianificare bene invece che male: chi arriva a maggio 2028 con la stessa lista di dubbi di oggi non ha risparmiato, ha solo compresso lo stesso lavoro in meno mesi.
Dall’altra parte c’è 2.4.9, uscita il 12 maggio 2026. Non è una release spettacolare, ed è un bene: è una release di igiene. Porta il supporto a PHP 8.5 (con 8.3 e 8.4 ancora supportati, e PHP 8.2 rimosso), MariaDB 11.8 e 12.x, RabbitMQ 4.2. Sul funzionale, cose piccole ma concrete: la migrazione dell’integrazione USPS dalle vecchie Web Tools API alle API REST, il controllo dell’ereditarietà delle immagini di galleria a livello di store view via REST API, un menu Actions nella griglia delle Catalog Price Rules per le operazioni multiple, una nuova mutation GraphQL exchangeExternalCustomerToken.
La riga che mi fa alzare la testa non è una feature, è “PHP 8.2 rimosso”. Perché è lì che si nasconde il costo vero, e non è nel core Adobe.
Il costo dell’upgrade non è mai nel core
La parte Adobe è la parte prevedibile: note di rilascio pubbliche, breaking change documentati, compatibilità dichiarata. Il costo sta nel delta tra il Magento vanilla e il tuo Magento: personalizzazioni accumulate in anni, moduli di terze parti, preference e plugin che intercettano classi nel frattempo deprecate, template sovrascritti, patch applicate a mano su un ticket urgente di tre anni fa e mai più toccate, moduli il cui vendor ha smesso di rispondere alle email.
Sono categorie note a chiunque abbia fatto questo mestiere. Il problema non è che siano ignote: è che quasi nessuno le mappa per intero prima di aprire il cantiere. Si parte, si compila, si rompe, si ripara, e a metà sprint si scopre che l’estensione del PIM non ha una versione compatibile. A quel punto la stima non vale più niente. Non ho una misura da darvi, ho l’esperienza di chi questi upgrade li vede dal 2011: la voce che fa esplodere i preventivi non è quasi mai una difficoltà tecnica sorprendente, è un pezzo di codebase che nessuno aveva contato.
Dove metterei un agente
La mia tesi, netta: l’upgrade non lo fa l’AI, e chi lo promette probabilmente non ha mai fatto un upgrade Magento. Un upgrade è un progetto con staging, strategia di merge, regression suite, piano di rollback, finestra di deploy concordata e una persona che alle due di notte decide se si va avanti o si torna indietro. Niente di tutto questo si delega.
Quello che un agente fa bene, proprio perché è noioso e sistematico, è l’inventario: la mappa del rischio prima di aprire il cantiere. Non l’ho ancora fatto su un codebase cliente, quindi vi racconto il metodo che userei, non un risultato che non ho.
Il perimetro reale. Elenco completo dei moduli in app/code e dei pacchetti di terze parti da composer.lock, con vendor, versione installata, ultima disponibile e vincolo PHP dichiarato. È l’unica lista che conta e quasi nessuno ce l’ha aggiornata.
I punti di contatto con il core. Tutte le preference, i plugin e gli observer dichiarati nei vari di.xml, classificati per classe intercettata, da incrociare con le aree cambiate tra 2.4.6 e 2.4.9. E i template sovrascritti nel tema, dove le regression si nascondono meglio: non rompono niente, cambiano solo silenziosamente cosa vede l’utente.
Il codice orfano. Moduli senza commit da anni, vendor spariti, patch applicate fuori da qualsiasi sistema di patching. Un agente può segnalarli. Non può dirti se quel modulo serve ancora: quello lo sa solo il business.
La compatibilità PHP. Con 8.2 fuori dal supporto, il custom code va passato al setaccio per sintassi e funzioni deprecate. Qui l’agente non deve inventare nulla, deve leggere, e leggere migliaia di file senza stancarsi è letteralmente il suo mestiere.
Il risultato che voglio non è “l’upgrade si può fare”. È un documento che dice: questi sono i punti di rottura potenziali, questi sono bloccanti, per questi non esiste una versione compatibile e va decisa una strategia. Da lì in poi la stima è una stima, non un numero sparato.
Perché serve sapere già cosa cercare
Un agente che analizza un codebase è bravissimo a produrre output che sembra completo: tabella ordinata, tutte le celle piene, tono tranquillo. Se non sai già cosa dovrebbe esserci in quella tabella, non hai modo di accorgerti che manca una riga. Su un’analisi di marketing una rassicurazione sbagliata la paghi con un post mediocre. Su un upgrade la paghi in produzione, di notte, con il checkout fermo.
È per questo che l’analisi di impatto è il caso da manuale della tesi che porto avanti da mesi: l’AI è un moltiplicatore di competenza, non un sostituto. Moltiplica quello che c’è. Se c’è zero, moltiplica zero, con una prosa impeccabile.
In pratica: le domande vanno poste in modo verificabile. Non “questo modulo è compatibile con 2.4.9”, che è un invito a rassicurarti, ma “mostrami il vincolo PHP dichiarato nel suo composer.json e le classi core che estende”. Prove, non giudizi. È lo stesso principio con cui ho costruito il mio MCP per Adobe Commerce: strumenti che restituiscono dati dall’istanza, non opinioni sull’istanza. Ed è la logica del toolkit di skill che uso su Claude Code, dove ogni passo delicato si ferma e chiede conferma.
“Ma allora tanto vale andare su Cloud Service”
È l’obiezione che mi aspetto, ed è legittima. Adobe Commerce as a Cloud Service esiste, è SaaS, e sposta davvero il problema degli upgrade fuori dalle mani del merchant. Se il tuo dolore è “non voglio più fare questa conversazione ogni due anni”, è una direzione seria.
Ma non è una scorciatoia per evitare l’analisi: è un altro progetto, con lo stesso prerequisito. In un modello SaaS il PHP custom non gira dentro l’applicazione, e la logica che oggi vive nei tuoi moduli va ricostruita fuori, come servizi e integrazioni. Quindi prima devi sapere esattamente quale logica hai: lo stesso identico inventario, solo che invece di dirti cosa va aggiornato ti dice cosa va riscritto e dove.
Entrambe le strade partono dal sapere cosa hai. Vale anche a monte, sui dati: quando ho scritto di UCP e cataloghi il punto era simile, la struttura la devi conoscere prima, non scoprire dopo.
Perciò, se dovessi partire domani su un’istanza 2.4.6, non aprirei un branch: aprirei due o tre settimane di analisi, con l’agente che fa l’inventario e me che leggo ogni riga con sospetto. Poi porterei al cliente tre numeri (2.4.9 adesso, 2.4.9 dopo, ACCS) con le assunzioni scritte accanto, così che quando una salta si vede subito quale. Quello che non direi è “con l’AI risparmiamo il 40%”. Non l’ho misurato, e sospetto che la risposta onesta sia un’altra: non risparmia sull’upgrade, risparmia sulle sorprese.
La domanda che mi porto dietro: quanto della mia diffidenza verso l’output di un agente è metodo, e quanto è l’abitudine di uno che ha visto abbastanza upgrade andare storti da non fidarsi di nessuno, nemmeno di sé stesso?
Mini-FAQ
Adobe Commerce 2.4.6 è ancora sicura dopo l’11 agosto 2026? Sì. È finito il supporto standard, non il supporto. Quello esteso copre fino al 31 agosto 2027 e le patch di sicurezza arrivano al 31 maggio 2028. Il tema non è “sei scoperto”, è “hai una scadenza nota, usala per pianificare”. Sull’igiene delle patch avevo già scritto qui.
Meglio 2.4.9 diretta o uno step intermedio? Dipende quasi solo dalle terze parti. Se le estensioni critiche hanno versioni compatibili con 2.4.9 e PHP 8.3 o superiore, il salto diretto evita di pagare due volte i test di regressione. Se ci sono moduli fermi, lo step intermedio spezza il rischio.
Un agente può stimare le giornate dell’upgrade? Può darti gli ingredienti: quanti moduli, quante override, quanti punti di rottura noti. La stima resta umana, perché dipende dal team, dalla qualità dei test esistenti e dalla tolleranza al rischio del cliente.
Cosa serve avere pronto prima? Accesso in lettura al repository, il composer.lock reale della produzione (non quello del repo, che spesso diverge), l’elenco delle patch applicate e, se c’è, la documentazione delle personalizzazioni. Se questi quattro elementi non esistono, il primo risultato dell’analisi sarà proprio quello.
Chi sono. Sono Fabio Canovi, consulente Adobe italiano specializzato nell’AI agentica, presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Costruisco integrazioni AI agentiche basate su MCP per il mondo Adobe, e scrivo di quello che imparo mentre le realizzo.