Salta al contenuto principale
Shopify Premier Partner
Giovanni Fracasso·

I problemi di Magento e Adobe Commerce per chi ce l'ha già (e cosa cambia su Shopify Plus)

12 min di lettura

Il costo operativo di tenere in piedi Magento: il tempo di attesa, gli aggiornamenti con le date di Adobe, le competenze introvabili. E cosa cambia su Shopify Plus.

i problemi di magento e adobeImmagine generata con intelligenza artificiale

Chi gestisce un ecommerce su Magento, oggi Adobe Commerce, non ha bisogno che gli si spieghi che cos'è Magento. Lo sa meglio di chiunque scriva articoli sull'argomento. Il punto non è la piattaforma in astratto, è la settimana lavorativa: il tempo che passa fra il momento in cui serve una modifica e il momento in cui quella modifica è online, la persona che non trovi sul mercato, la fattura di manutenzione che arriva anche nei mesi in cui non è successo niente.

Questo articolo parla di quello, e soltanto di quello. Non è un confronto funzione per funzione fra le due piattaforme, che sta nel confronto fra Adobe Commerce e Shopify. Non è un elenco di ragioni per non scegliere Magento in un progetto nuovo, che sta nelle ragioni per non entrare in Magento. È il costo operativo di tenere in piedi Magento, visto da chi ce l'ha già, e cosa cambia nella pratica di tutti i giorni quando quel costo sparisce.

Il primo costo di Magento non compare in nessuna fattura, ed è il tempo. Non il tempo dello sviluppatore, che quello si paga e si vede: il tempo di attesa di chi il negozio lo manda avanti. La responsabile ecommerce che deve cambiare una regola di sconto e apre un ticket. Il marketing che vuole una landing per la campagna di novembre e la chiede a settembre. Il commerciale che ha bisogno di un listino nuovo per un cliente e scopre che tocca allo sviluppatore.

Il backend di Magento è potente, e la potenza si paga in superficie di configurazione: tante opzioni, tanti moduli, tante interdipendenze fra cose che sembrano lontane. Chi non è tecnico impara a non toccarlo, perché ha già visto cosa succede quando si tocca la cosa sbagliata. E così ogni modifica, anche minima, diventa una richiesta a qualcun altro. Il negozio smette di essere una cosa che governi e diventa una cosa che chiedi.

Il conto vero si fa qui, ed è il conto che nessuno mette a bilancio: non quanto costa la singola modifica, ma quante modifiche non fai perché il costo e l'attesa non le giustificano. È il costo delle cose che non succedono. Non lo vede nessuno, e pesa più di tutti gli altri messi insieme.

Il secondo costo è l'aggiornamento, ed è quello che negli ultimi mesi è cambiato di più. Per anni la manutenzione di Magento è stata, di fatto, una scelta: si rimandava, si accumulava debito tecnico, si conviveva. Nel 2026 non è più così, perché Adobe ha messo le date sulla carta.

Sono numeri pubblici, sulla documentazione ufficiale Adobe (Experience League, pagine Released versions e Software lifecycle policy, verificate il 12 luglio 2026). Il supporto regolare della 2.4.6 finisce l'11 agosto 2026, cioè fra poche settimane. Il supporto esteso della 2.4.5 finisce lo stesso giorno. Il supporto esteso della 2.4.4 è già finito, il 14 aprile 2026. Il supporto regolare della 2.4.7 arriva al 9 aprile 2027, quello della 2.4.8 all'11 aprile 2028. La 2.4.9, uscita il 12 maggio 2026, è coperta fino a maggio 2029.

C'è poi la parte che pesa di più, e riguarda chi sta su Adobe Commerce on Cloud. Adobe ha introdotto una policy di enforcement degli aggiornamenti: la data si calcola come data di rilascio più tre anni di supporto regolare più al massimo un anno di supporto esteso, e alla scadenza Adobe smette di mantenere gli ambienti che girano su versioni non supportate e si riserva il diritto di dismetterli. La prima data di enforcement è il 1° giugno 2027 (Adobe, Version upgrade enforcement policy, aggiornata il 18 giugno 2026). Adobe dichiara che manda preavvisi e che concede una finestra per esportare i dati prima della disattivazione dell'ambiente.

Qui serve una precisazione di onestà, perché è il punto su cui è più facile esagerare e poi passare per allarmisti davanti a chi la documentazione l'ha letta. L'anno di supporto esteso senza costi Adobe oggi lo dichiara per la 2.4.4 e la 2.4.5. Per la 2.4.6 e la 2.4.7 la tabella ufficiale non riporta una data di fine supporto esteso, e Adobe scrive che l'estensione viene annunciata in prossimità della fine del supporto regolare. Quindi: le date di fine supporto regolare sono confermate, l'anno aggiuntivo su 2.4.6 e 2.4.7 non lo è. Chi ci costruisce sopra una scadenza perentoria sta tirando a indovinare.

E c'è un punto che Adobe mette per iscritto nel documento legale della Software Lifecycle Policy: la policy non si applica a Magento Open Source. Il supporto esteso, dice la pagina ufficiale, non è disponibile per il codice Open Source. Chi sta sulla versione gratuita non ha una scadenza da temere, perché non ha nemmeno una copertura da cui scadere. È una posizione diversa, non una posizione migliore.

Tradotto in operatività: l'aggiornamento non è un progetto che decidi tu quando fare. È un progetto che qualcun altro ha messo in calendario al posto tuo, e che va pianificato, testato su ogni personalizzazione e su ogni modulo di terze parti, collaudato e poi portato in produzione. Ogni volta. Dove sta andando davvero la piattaforma, e cosa comporta il salto al modello SaaS di Adobe, l'abbiamo analizzato a parte.

Il terzo costo è la persona. Uno sviluppatore Magento vero, capace di mettere le mani nel core senza fare danni, oggi è una figura rara e cara, e la ragione è strutturale: la curva di apprendimento è lunga, il mercato del lavoro si è spostato altrove, e chi quelle competenze le ha se le fa pagare. Non è un giudizio sulla piattaforma, è un dato del mercato del lavoro, e chi assume lo sa senza bisogno che glielo dica un'agenzia.

Per un'azienda questo significa due cose sgradevoli. La prima è la dipendenza: se il fornitore che conosce il tuo Magento se ne va, cambiarlo non è un cambio di fornitore, è un progetto di travaso di conoscenza, con i suoi tempi e i suoi rischi. La seconda è il potere contrattuale, che si sposta tutto dalla parte di chi il lavoro lo sa fare. Non perché sia disonesto: perché è l'unico.

Sull'ecosistema Shopify la situazione è diversa, ma va detta con precisione e senza vendere una favola: il fatto che Shopify sia più accessibile non significa che chiunque sappia costruirci sopra progetti seri. Le agenzie capaci di fare temi su misura, integrazioni con il gestionale e app private in linea con la filosofia della piattaforma restano poche. Il bacino da cui pescare, però, è molto più largo, e questo cambia i tempi con cui trovi qualcuno e il prezzo a cui lo trovi.

Parlando per noi e non per gli altri: ICT Sviluppo lavora con Shopify dal 2013 ed è Shopify Premier Partner, uno dei pochissimi in Italia. Come è fatta la squadra, e come lavora dentro un progetto, lo raccontiamo per esteso altrove: qui basti dire che il criterio con cui scegli il partner conta quanto il criterio con cui scegli la tecnologia.

Il quarto costo è la somma di tutti gli altri, e ha un nome tecnico: il costo di possesso. Con Magento Open Source la licenza è gratuita, e questo è l'unico numero certo dell'intera equazione. Tutto il resto — server dimensionati per reggere i picchi tutto l'anno, sistemisti, sviluppatori, moduli a pagamento, patch di sicurezza, ambienti di test, collaudi — resta a carico tuo, e cresce insieme alla complessità che accumuli.

Su Adobe Commerce alla gestione si somma una licenza, e qui va fatta una precisazione che vale più di qualunque numero: Adobe i prezzi non li pubblica. La pagina prezzi ufficiale non contiene una sola cifra, e rimanda a un modulo di contatto. Quello che Adobe pubblica è il modello, e sta nelle product description legali: il livello di prezzo è funzione del GMV e dell'AOV dichiarati, oppure di un limite di ordini, e viene fissato nel Sales Order. Il costo, per costruzione, cresce con il fatturato.

Le cifre che girano in rete — ventiduemila, quarantamila, centoventimila dollari l'anno — sono stime di terzi, divergono fra loro di un fattore venti e non hanno una fonte Adobe. In una trattativa non si usano: chi le porta al tavolo si espone alla prima domanda seria. Il modello si spiega, il numero si chiede.

Replatforming

Il conto corretto, quindi, non si fa sulla licenza. Si fa sul costo di possesso su tre o cinque anni, voce per voce, mettendo in colonna anche le ore interne che nessuno fattura. Il metodo per farlo, senza cifre inventate, è il tema di un pezzo dedicato.

Su Shopify Plus l'infrastruttura, la sicurezza e gli aggiornamenti sono della piattaforma. Non è uno slogan, è una divisione di responsabilità: il negozio è sempre sull'ultima versione, e la nottata dell'upgrade non esiste perché non esiste l'upgrade. Le patch arrivano senza fermare il negozio e senza che qualcuno debba collaudarle su quaranta moduli.

Nella pratica quotidiana la differenza si sente su tre cose. Le modifiche di configurazione — listini, regole di sconto, pagine, campagne — le fa chi gestisce il negozio, non chi scrive codice. Le personalizzazioni standard passano dalle app, la cui compatibilità è garantita dal modello SaaS. E quando serve una funzione che nello store non c'è, si sviluppa un'app privata che dialoga con Shopify via API senza toccare il core, oppure si interviene in modo chirurgico su sconti, spedizioni, pagamenti e checkout con le Shopify Functions.

Una precisazione doverosa, perché la verità serve più dello slogan: il SaaS non rende immuni dagli errori. Se il tema custom lo fa chi non sa farlo, o se si installano trenta app che appesantiscono il frontend, il sito rallenta lo stesso. La piattaforma regge, ma quello che ci metti sopra va fatto bene. Quello che cambia è chi è responsabile di cosa, non la necessità di lavorare con criterio.

Il confronto funzione per funzione — catalogo, ricerca, filtri, checkout, listini, B2B, mercati e lingue, performance, sicurezza, modello di costo — non sta qui, perché duplicherebbe pezzi che esistono già e sono più completi di quanto potrebbe essere una sezione. Chi sta su Adobe Commerce trova il confronto dedicato poco sopra; chi sta su Magento Open Source ha il suo, ed è un confronto diverso, perché le due edizioni non hanno le stesse funzioni.

È la prima domanda che fanno tutti, ed è legittima. La risposta breve: catalogo, clienti, ordini e contenuti si migrano con una mappatura, e il posizionamento si difende con i redirect, uno a uno, dai vecchi indirizzi alle pagine corrispondenti. La risposta lunga — compreso l'unico punto in cui l'obiezione ha davvero un fondamento, cioè le pagine filtrate della navigazione a livelli, che su Shopify non nascono come pagine autonome e vanno ricostruite — sta nell'articolo sulla SEO di Shopify.

E il come si esegue — le entità che non si traducono, i moduli senza corrispettivo, le trappole tipiche di un'origine Magento — sta nella guida alla migrazione da Magento a Shopify Plus. La migrazione non è un copia e incolla: è un progetto, ed è un progetto noto.

Per onestà, non tutto si risolve con un passa a Shopify, e ci sono casi in cui non si passa. Chi ha bisogno del controllo totale sul codice per logiche di business fuori standard. Chi ha integrazioni storiche e profonde, costruite in anni, il cui rifacimento costerebbe più del beneficio che porta. Chi ha in casa un team tecnico solido, che l'infrastruttura la sa gestire e la gestisce bene, e per cui il costo di cui parla questo articolo semplicemente non esiste. Chi è dentro l'ecosistema Adobe e ne trae valore su tutta la suite, non solo sul commercio.

In questi casi il problema non è la piattaforma, ed è giusto restare. Vale la pena dirlo chiaramente: se l'unico argomento per migrare è che la migrazione la vendiamo noi, non è un argomento.

Quello che invece non è una decisione è l'inerzia. Restare perché cambiare costa fatica non è una scelta, è un rinvio, e il rinvio ha un prezzo che cresce ogni trimestre. Il momento per fare i conti non è quando il sito si è fermato: è quando ci si accorge di passare più tempo a tenere in piedi la piattaforma che a far crescere le vendite. Se un replatforming abbia senso, e soprattutto quando non ne ha, è la domanda da cui partire, e ha una risposta che non è sempre sì.

Lo sappiamo come suona: scriviamo un articolo che elenca i problemi di Magento, e Shopify è esattamente quello che vendiamo. In parte è vero, e non ha senso nasconderlo. Ma se pensassimo che Adobe Commerce fosse la scelta migliore per le aziende che seguiamo, avremmo costruito l'agenzia attorno a quella. Preferiamo sederci a un tavolo per parlare di funzioni nuove piuttosto che passare gli anni su aggiornamenti e bug fixing che divorano il budget del cliente, ed è un interesse nostro tanto quanto suo.

Quali sono i problemi ricorrenti di chi usa Magento o Adobe Commerce?

Sono quattro, e sono operativi prima che tecnici: il tempo di attesa fra la richiesta di una modifica e la sua messa online, gli aggiornamenti che vanno pianificati e collaudati su ogni personalizzazione e su ogni modulo di terze parti, la difficoltà di trovare e trattenere competenze Magento sul mercato del lavoro, e un costo di gestione che cresce insieme alla complessità accumulata.

Adobe ha davvero messo una scadenza agli aggiornamenti?

Per Adobe Commerce on Cloud sì. Adobe ha pubblicato una policy di enforcement: alla scadenza smette di mantenere gli ambienti che girano su versioni non supportate e si riserva il diritto di dismetterli, con preavvisi e una finestra per esportare i dati. La prima data è il 1° giugno 2027. Le date di fine supporto regolare per versione sono pubbliche: 2.4.6 all'11 agosto 2026, 2.4.7 al 9 aprile 2027, 2.4.8 all'11 aprile 2028 (fonti Adobe Experience League, verificate il 12 luglio 2026).

Chi sta su Magento Open Source è coperto?

No, e lo scrive Adobe. Il documento legale della Software Lifecycle Policy dichiara espressamente di non applicarsi a Magento Open Source, e la pagina ufficiale precisa che il supporto esteso non è disponibile per il codice Open Source. Il codice continua a uscire — la 2.4.9, del 12 maggio 2026, è stata rilasciata anche per Open Source — ma la copertura contrattuale sul supporto non c'è. È una differenza che si sente il giorno in cui esce una vulnerabilità.

Migrare a Shopify significa perdere le personalizzazioni che ho su Magento?

No, cambia il modo di realizzarle. Si passa da modifiche al core a un modello a estensioni: app dello store, app private che dialogano via API e Shopify Functions per intervenire su sconti, spedizioni, pagamenti e checkout. Quello che si perde non è la funzione, è la libertà di riscrivere il cuore della piattaforma. Che è anche, esattamente, ciò che rendeva ogni aggiornamento un collaudo.

Quanto dura una migrazione da Magento a Shopify Plus?

Si misura in mesi, non in anni, ma la variabile che determina i tempi non è la migrazione dei dati: è la ricostruzione delle funzioni custom e delle integrazioni con i sistemi aziendali. È la discovery iniziale a fissare il calendario, non il travaso del catalogo. Chi promette una data prima di aver fatto il censimento delle integrazioni sta indovinando.

Quanto costa davvero, rispetto a Magento?

Il confronto sulla licenza non dice niente, perché Adobe la licenza non la pubblica e Magento Open Source non ce l'ha. Il confronto corretto è sul costo di possesso su tre o cinque anni: licenza, hosting, sistemisti, sviluppo, moduli, aggiornamenti, collaudi, più le ore interne che nessuno fattura. Su Shopify Plus gran parte di quel costo si concentra in un canone prevedibile; su Magento resta distribuito, e cresce con la complessità.

Post correlati