Magento Open Source e le tre edizioni Adobe Commerce: che cosa sono, che cosa hanno che le altre piattaforme non hanno, quanto costa un progetto con Magento, come si configura, quali sono le alternative e perché il 2026 è l'anno in cui questa piattaforma si è divisa in due
Magento è la piattaforma di commercio elettronico più profonda del mercato open source, ed è anche quella su cui è più facile sbagliare la domanda. Perché nel 2026 «Magento» non indica un prodotto ma quattro cose diverse: Magento Open Source, gratuito e autogestito; Adobe Commerce on Cloud, il monolite storico su infrastruttura Adobe; Adobe Commerce as a Cloud Service, la versione SaaS completamente headless introdotta a giugno 2025; e Adobe Commerce Optimizer, un livello di catalogo e vetrina da mettere davanti a un backend che già esiste. Hanno funzionalità diverse, costi diversi e vincoli diversi — e confonderle è il modo più rapido per firmare il preventivo sbagliato.
Questa guida percorre la piattaforma per intero — caratteristiche principali, vantaggi competitivi, costi, funzionalità avanzate e integrazioni, configurazione e personalizzazione, alternative e confronto, strategie di crescita, tendenze — e per ogni parte dice non solo che cosa c'è, ma su quale edizione c'è. È la distinzione che conta più di ogni altra: diverse fra le funzioni per cui si sceglie Magento — la ricerca avanzata, le raccomandazioni di prodotto, l'intero modulo B2B — non sono disponibili sulla versione gratuita, e alcune richiedono perfino una licenza separata da quella di Adobe Commerce.
Dove esistono dati verificabili sono citati con la fonte. Dove non esistono, l'articolo lo dice, e su questa piattaforma l'elenco è il più lungo delle nostre guide: Adobe non pubblica alcun prezzo — la pagina dei listini contiene tre pulsanti «richiedi un preventivo» e nient'altro — non esiste un conteggio ufficiale delle estensioni sul marketplace, e non esiste alcuna fonte con metodologia dichiarata sui costi di implementazione e manutenzione. In compenso ci sono due date pubbliche che chi ha un negozio Magento deve avere in agenda, e due incidenti di sicurezza recenti che spiegano meglio di qualsiasi discorso perché su questa piattaforma la manutenzione non è opzionale.
INDICE DEI CONTENUTI
- Che cos'è Magento nel 2026: quattro prodotti, un nome
- Le caratteristiche principali
- I vantaggi competitivi: che cosa ottieni davvero
- Costi: la sezione in cui nessuno pubblica niente
- Funzionalità avanzate e integrazioni
- Configurazione e personalizzazione del negozio
- Alternative a Magento e confronto
- Strategie di crescita usando Magento
- Tendenze future: l'anno in cui Magento si è divisa in due
- Domande frequenti
- In sintesi
Che cos'è Magento nel 2026: quattro prodotti, un nome
Il nome resta ufficiale: Adobe usa la dicitura «Adobe Commerce (Magento)» sulle proprie pagine di prodotto, e Magento Open Source è tuttora il nome della distribuzione gratuita, usato anche nei bollettini di sicurezza. Ma sotto quel nome, oggi, ci sono strade molto diverse.
Magento Open Source
È la distribuzione gratuita con licenza OSL 3.0, ospitata su GitHub e mantenuta da Adobe con un programma di community maintainer che hanno potere di merge. Contiene il cuore della piattaforma: catalogo, multi-sito, gestione dell'inventario, regole di prezzo, checkout, ordini, CMS con Page Builder, API REST e GraphQL. È completa e seria — non una versione mutilata — ma le funzioni che negli ultimi anni hanno differenziato Adobe Commerce (ricerca avanzata, raccomandazioni, B2B) restano fuori.
Le tre edizioni Adobe, spiegate per come si scelgono
Adobe Commerce on Cloud (PaaS) — la piattaforma 2.4.x storica sull'infrastruttura di Adobe. È quella che si personalizza in profondità, con codice proprio dentro il monolite PHP. Il 30 marzo 2026 Adobe ha pubblicato un impegno esplicito: nessun piano di fine supporto o fine vita per il PaaS, e stesse capacità agentiche del SaaS. Per chi ci ha investito dieci anni di sviluppo su misura, è la notizia più importante dell'anno.
Adobe Commerce as a Cloud Service (SaaS) — introdotta a giugno 2025, è cloud-native e completamente headless: aggiornamenti automatici, nessuna patch da applicare, ma anche niente codice proprio dentro il core. Si estende solo dall'esterno, con App Builder ed eventi. Non supporta lo storefront Luma: richiede Commerce Storefront su Edge Delivery Services.
Adobe Commerce Optimizer (SaaS) — un livello di catalogo, ricerca e vetrina da mettere davanti a un backend che già hai, anche non Adobe: un ERP, un PIM, un sistema proprietario, con carrello e checkout di terze parti. Serve a scalare la parte di catalogo e discovery senza sostituire l'infrastruttura. Non è disponibile per Magento Open Source.
Tradotto in una riga: on Cloud si personalizza, as a Cloud Service si compone, Optimizer si antepone. Sono tre modelli di lavoro, non tre livelli di prezzo.
Le versioni e le due date da mettere in agenda
Il calendario di supporto di Magento è pubblico ed è uno dei pochi dati solidi di questa guida.
Versione | Rilascio | Supporto regolare fino a | Extended support |
|---|---|---|---|
2.4.9 | 12 maggio 2026 | 31 maggio 2029 | — |
2.4.8 | 8 aprile 2025 | 31 maggio 2028 | — |
2.4.7 | 9 aprile 2024 | 31 maggio 2027 | fino al 31 maggio 2028 |
2.4.6 | 14 marzo 2023 | terminato l'11 agosto 2026 | fino al 31 agosto 2027 |
Le due righe che contano sono l'ultima e la colonna a destra. Il supporto regolare della 2.4.6 è finito il mese scorso, e l'extended support — un anno aggiuntivo di patch di sicurezza e qualità, senza costi aggiuntivi — è riservato ai clienti Adobe Commerce. Chi sta su Magento Open Source non ce l'ha: alla fine del supporto regolare resta scoperto. È il fatto più importante di tutta la sezione economica di questo articolo, e ci torniamo parlando di Mage-OS.
I requisiti, che da soli definiscono il budget di hosting
La 2.4.9 richiede PHP 8.5 (la 8.4 è ammessa solo per l'aggiornamento e non è raccomandata in produzione; 8.2 e 8.3 non sono più supportate), MariaDB 11.8 o 12 oppure MySQL 8.4, OpenSearch 3, RabbitMQ 4.2 o 4.3, Valkey 9 — che nella matrice ufficiale ha di fatto sostituito Redis dopo il cambio di licenza di quest'ultimo — nginx 1.30, Varnish 8 e Composer 2.9 o 2.10.
Non è un dettaglio tecnico: è uno stack a più servizi che esclude in partenza l'hosting condiviso economico. Chiunque proponga un progetto Magento su un piano da venti euro al mese non ha letto la matrice dei requisiti. La 2.4.9 ha inoltre sostituito diverse componenti storiche — la cache di Zend con quella di Symfony, l'editor TinyMCE con il fork HugeRTE, l'MVC di Laminas con uno nativo, la libreria OAuth di terze parti con le funzioni native di PHP — e ha risolto 666 problemi, 580 dei quali nel core Open Source.
I numeri, e la traiettoria
Store Leads, che dichiara la propria metodologia, conta al 28 agosto 2026 103.381 negozi Magento live, in calo del 14% anno su anno e del 36% rispetto al picco di fine 2021, che era di 161.970 negozi. Nella stessa rilevazione l'Italia conta circa 2.700 negozi, il 2,6% del totale, nono paese al mondo.
W3Techs, al 6 settembre 2026, colloca Magento allo 0,3% di tutti i siti web e all'1,5% dei sistemi di commercio elettronico rilevati.
La lettura onesta di questi numeri non è «Magento sta morendo», ed è importante dirlo perché è la conclusione che quasi tutti traggono. È un'altra: Magento ha smesso di competere per il negozio piccolo, che è migrato verso le piattaforme in abbonamento e verso WooCommerce, e si è concentrata sulla fascia media e alta, dove i numeri di negozi sono piccoli per definizione e il fatturato per negozio è alto. Il calo del conteggio è coerente con quella scelta strategica, non necessariamente con un declino della piattaforma.
Le caratteristiche principali
La gerarchia multi-sito, che nessun concorrente replica allo stesso modo
È la differenza storica di Magento e resta la ragione tecnica più forte per sceglierla. La struttura è a quattro livelli — globale, sito web, negozio, vista negozio — e quasi ogni impostazione della piattaforma ha un proprio scope su quella gerarchia: puoi definire un prezzo diverso per sito web, un catalogo diverso per negozio, una lingua e un tema diversi per vista negozio, tutto da un'unica installazione e un unico pannello.
Il confronto con le altre piattaforme di questa serie chiarisce il punto. Su Shopify serve un abbonamento per negozio. Su WooCommerce serve un multisito WordPress o installazioni separate. PrestaShop ha il multinegozio nativo ed è l'unico concorrente diretto, ma la granularità dello scope di Magento è superiore: là dove PrestaShop separa i negozi, Magento permette di ereditare e sovrascrivere configurazione, prezzi e contenuti livello per livello. Per un gruppo con dieci marchi in sei paesi, quella differenza vale mesi di lavoro. Ed è tutto nel core Open Source.
I tipi di prodotto e il modello EAV
Il core gestisce sei tipi di prodotto — semplice, configurabile, raggruppato, bundle, virtuale e scaricabile — tutti presenti anche su Open Source. Il tipo bundle in particolare, cioè il prodotto componibile in cui il cliente sceglie gli elementi che lo compongono, è nativo qui e altrove richiede un'estensione.
Sotto c'è il modello EAV (entity-attribute-value) per prodotti e clienti: gli attributi non sono colonne di una tabella ma righe di un archivio generico. Il vantaggio è che puoi aggiungere qualunque attributo senza toccare lo schema del database, con tipi, validazioni, comportamento in ricerca e nei filtri configurabili dal pannello — ed è la ragione per cui Magento regge cataloghi tecnici che altrove diventano ingestibili. Lo svantaggio è che ogni lettura completa di un prodotto attraversa molte tabelle: da qui gli indicizzatori, che precalcolano le viste piatte usate dal front-end, e da qui il fatto che su Magento «reindicizzare» sia un verbo di uso quotidiano. Le vecchie tabelle flat catalog sono state rimosse: oggi la strada è indicizzatori più motore di ricerca, non più flat table.
Inventory Management, ancora nel core
La gestione avanzata dell'inventario — nata dal progetto community noto come MSI, con più fonti di stock, aggregazioni per canale, regole di priorità e algoritmi di assegnazione — è installata di serie sia su Magento Open Source sia su Adobe Commerce, con tutte le funzioni attive per impostazione predefinita, e non risulta alcun avviso di deprecazione. Per chi vende da più magazzini, o da magazzino e punti vendita insieme, è una funzione di livello gestionale inclusa nella versione gratuita.
Prezzi, regole e gruppi di clienti
Nel core Open Source ci sono gruppi di clienti, prezzi a scaglioni (tier price), regole di prezzo di catalogo — che modificano il prezzo prima che il prodotto entri nel carrello — e regole di prezzo del carrello, con condizioni componibili e coupon. La 2.4.9 ha aggiunto le azioni massive sulla griglia delle regole di catalogo.
Quello che non c'è su Open Source sono i cataloghi condivisi, cioè i listini assegnati a una singola azienda cliente: fanno parte del modulo B2B, che è materia della prossima sezione e che è la principale ragione di upgrade verso Adobe Commerce.
Contenuti e ricerca
Page Builder, l'editor visuale a blocchi per pagine, blocchi CMS e descrizioni prodotto, è incluso anche in Magento Open Source dalla 2.4.3 nelle sue funzioni di base; Adobe Commerce aggiunge staging e anteprima dei contenuti programmati, contenuti personalizzati e raccomandazioni di prodotto dentro Page Builder.
Sulla ricerca la divisione è netta e va conosciuta prima di scegliere l'edizione: il motore nel core è OpenSearch 3 (Elasticsearch 8 fino alla 2.4.8), che copre ricerca testuale e navigazione a faccette; Live Search — la ricerca gestita con suggerimenti, sinonimi, regole di merchandising e classificazione basata sul comportamento — è una funzione esclusiva di Adobe Commerce. Su Open Source si arriva allo stesso risultato con estensioni o con un servizio di ricerca esterno, che è una voce di costo ricorrente.
I vantaggi competitivi: che cosa ottieni davvero
La profondità funzionale
Il vantaggio principale di Magento è quantitativo prima ancora che qualitativo: fa di serie cose che altrove sono progetti. Sei tipi di prodotto compresi i bundle, inventario multi-sorgente con regole di assegnazione, gerarchia a quattro livelli di siti e viste, due motori di regole di prezzo, gruppi di clienti, prezzi a scaglioni, importazione ed esportazione massive, code di messaggi, indicizzatori configurabili, ruoli e permessi granulari sull'admin. Su una piattaforma in abbonamento, metà di questo elenco è un'app a canone; sulle altre open source, è un plugin da scegliere e mantenere.
L'estensibilità, che qui è un impianto e non una convenzione
Magento è probabilmente la piattaforma di commercio con il sistema di estensione più formale del mercato PHP: iniezione delle dipendenze configurata in XML, plugin (interceptor) che si agganciano prima, dopo o attorno a un metodo pubblico, osservatori di eventi, service contract — interfacce pubbliche che il core si impegna a mantenere stabili — e aree separate per front-end, amministrazione, API REST e GraphQL. Il risultato pratico è che si può cambiare quasi ogni comportamento senza toccare una riga del codice originale, e quindi senza compromettere gli aggiornamenti.
Con un'avvertenza che è anche il difetto della medaglia: i plugin di tipo around, quelli che avvolgono completamente un metodo, sono la causa tecnica principale dei conflitti fra estensioni, e la documentazione raccomanda di preferire before e after. Ne riparliamo nella sezione sulla configurazione.
Il codice è tuo (se scegli Open Source)
Su Magento Open Source non c'è canone, non c'è commissione sul transato, non c'è un fornitore che può cambiare i termini. Il codice è OSL 3.0, il database è tuo, l'hosting lo scegli tu. È il classico vantaggio dell'open source, e su Magento vale in pieno — ma va soppesato con l'assenza di extended support, che è la contropartita specifica di questa piattaforma.
Dove il vantaggio si rovescia
Tre limiti, e sono seri.
Primo: il costo di ingresso e di esercizio è il più alto del confronto. Lo stack tecnico richiede risorse dedicate, l'implementazione richiede competenze specialistiche rare e care, e la manutenzione non è opzionale — come dimostrano i due incidenti di sicurezza di cui parliamo più avanti.
Secondo: la frammentazione funzionale fra edizioni. Ricerca avanzata, raccomandazioni e B2B non ci sono su Open Source, e il B2B richiede una licenza separata anche per chi ha già Adobe Commerce. Chi valuta la piattaforma sulla base di una demo di Adobe Commerce e poi implementa su Open Source scopre il divario a progetto avviato.
Terzo: la questione del front-end. Il tema del core, Luma, è tecnicamente datato — RequireJS e Knockout.js, decine di bundle JavaScript — e pesa sulle metriche di esperienza utente. Le alternative valide sono Hyvä, che è a pagamento, ed Edge Delivery Services, che è riservato alle edizioni Adobe. In pratica, su Magento il front-end moderno è una voce di costo, non una scelta gratuita.
Costi: la sezione in cui nessuno pubblica niente
Va detto subito, perché cambia il modo di leggere tutto il resto: Adobe non pubblica prezzi. La pagina ufficiale dei listini elenca i tre prodotti e per ciascuno mostra un pulsante «richiedi un preventivo», senza soglie di fatturato né fasce. Le cifre che circolano — dai quaranta ai centonovanta mila dollari l'anno in funzione del transato — provengono da blog di agenzie e integratori, non da Adobe, e non sono verificabili. Qui non le riportiamo come dato. Allo stesso modo, non esiste alcuna fonte con metodologia dichiarata sui costi di implementazione, di hosting e di manutenzione di un progetto Magento: tutto ciò che si trova è materiale commerciale di chi quei servizi li vende.
Quello che si può fare, ed è più utile di una cifra inventata, è elencare le voci che compongono il conto e indicare quali hanno un prezzo pubblico.
Le voci del conto, una per una
Licenza del software. Magento Open Source: zero. Adobe Commerce: non pubblico, si negozia.
Infrastruttura. Non è «hosting», è uno stack: PHP 8.5, database, OpenSearch 3, Valkey 9, RabbitMQ, Varnish 8, più ambienti di collaudo. Adobe non pubblica fasce di costo e non esistono rilevazioni indipendenti con metodo dichiarato, quindi qualunque cifra letta in giro è una stima commerciale. Il dato solido su cui ragionare è il requisito: servono risorse dedicate, non un piano condiviso.
Front-end. È la voce che ha finalmente un listino pubblico, ed è quello di Hyvä: Hyvä Commerce 3.000 € l'anno (oppure 12.000 € per cinque anni anticipati), Hyvä Checkout 1.000 €, Hyvä UI 250 €, e dal 1° luglio 2026 Hyvä Enterprise, la suite all-inclusive per merchant Adobe Commerce, a 7.500 € il primo anno e 5.000 € l'anno di rinnovo, per istanza e senza tariffazione legata al transato. La licenza è commerciale e vale una installazione: non è software libero, ed è giusto saperlo.
Estensioni. Sul Marketplace Adobe la ripartizione dei ricavi è 85% al fornitore e 15% ad Adobe, con acquisto perpetuo per installazione oppure abbonamento; il numero totale di estensioni non è pubblicato e buona parte dei fornitori storici vende anche fuori dal marketplace, direttamente dai propri siti.
Le voci italiane, che sono obbligatorie. Il core non prevede codice fiscale, partita IVA, codice destinatario del Sistema di Interscambio né la distinzione fra privato e azienda al checkout, e non include i corrieri italiani. Sono estensioni commerciali da mettere a budget in ogni progetto italiano, insieme all'integrazione con la fatturazione elettronica.
Implementazione e manutenzione. La voce più grande, e l'unica su cui non esiste alcun riferimento pubblico verificabile. L'unico criterio onesto è procedurale, non numerico: farsi quotare separatamente ogni integrazione e ogni personalizzazione, e chiedere quante ore al mese sono previste per l'applicazione delle patch di sicurezza.
Come si costruisce un budget credibile
In assenza di listini, il metodo conta più dei numeri. Tre regole che funzionano.
Chiedi il preventivo su tre anni, non su uno. Su Magento il primo anno è dominato dall'implementazione e il secondo e il terzo dalla manutenzione, dagli aggiornamenti di versione e dalle patch. Un confronto fra piattaforme fatto sul primo anno dà sempre il risultato sbagliato.
Fai listare esplicitamente ciò che non è incluso nell'edizione scelta. Se la demo che hai visto usava Live Search, le raccomandazioni di prodotto o il modulo B2B, chiedi per iscritto su quale edizione girerà il tuo negozio e quali di quelle funzioni saranno disponibili.
Metti a bilancio il front-end. La differenza fra restare su Luma e adottare un tema moderno non è cosmetica ed è quantificabile: c'è una licenza annuale con un prezzo pubblico, e c'è il lavoro di reimplementazione del tema. Preventivarlo dall'inizio evita di scoprire dopo un anno che il negozio è lento e che sistemarlo è un secondo progetto.
Funzionalità avanzate e integrazioni
L'architettura, in breve e per chi decide
Magento è modulare per costruzione: ogni funzionalità è un modulo installato da Composer, con il codice proprio in app/code e le dipendenze in vendor/, che non si tocca mai. Sopra ci sono l'iniezione delle dipendenze configurata in XML, i plugin che intercettano i metodi, gli osservatori di eventi e i service contract, cioè le interfacce che il core garantisce stabili fra le versioni. Completano il quadro gli indicizzatori, il cron — che su Magento non è opzionale: se il cron non gira, il negozio smette progressivamente di funzionare — e le code di messaggi, su database o su RabbitMQ, per il lavoro asincrono.
Perché serve saperlo anche se non scrivi codice: è il vocabolario con cui valutare un fornitore. Chi propone di modificare file dentro vendor/, o di risolvere ogni problema con un plugin around, sta costruendo un negozio che non si potrà aggiornare.
API: REST e GraphQL
Adobe indica GraphQL come «la scelta preferita per le applicazioni moderne», con due implementazioni — una per il PaaS e una per il SaaS — che coprono le funzioni core e quelle B2B. La 2.4.9 ha esteso a tutti gli utenti Open Source la mutazione per svuotare il carrello, ne ha aggiunta una per la lista dei desideri e ha introdotto lo scambio di token per l'autenticazione via integrazione.
Le API REST restano pienamente supportate e documentate — non risulta alcuna dichiarazione di deprecazione, anzi la 2.4.9 ha portato miglioramenti anche lì — e nella pratica sono ancora l'interfaccia con cui parlano gestionali, magazzini e middleware, mentre GraphQL copre soprattutto la vetrina. La regola pratica per un capitolato: GraphQL per il front-end, REST per le integrazioni gestionali.
I Commerce Services: chi ha che cosa
È la tabella più utile di questo articolo, perché è la fonte del malinteso più costoso su questa piattaforma.
Servizio | Magento Open Source | Adobe Commerce |
|---|---|---|
Live Search (ricerca gestita, merchandising, sinonimi) | No | Sì, esclusiva |
Product Recommendations | No | Sì, esclusiva |
B2B (aziende, cataloghi condivisi, preventivi, ordini d'acquisto) | No | Sì, con licenza separata |
Catalog Service | Sì | Sì |
Payment Services | Sì | Sì |
Inventory Management e Braintree | Sì, di serie | Sì, di serie |
Adobe Commerce Optimizer ed Edge Delivery Storefront | No | Sì |
Il modulo B2B: il vero mercato di Magento
È la ragione per cui molte aziende scelgono questa piattaforma, e va descritto con precisione perché le condizioni commerciali sorprendono. Adobe Commerce B2B è un'estensione separata, disponibile solo per Adobe Commerce — cloud e on-premise — e non autorizzata su Magento Open Source. Non solo: Adobe la classifica fra le estensioni che richiedono una licenza separata, quindi non è automaticamente inclusa nella licenza Adobe Commerce e va negoziata a parte. La versione corrente è la 1.5.3 del 12 maggio 2026, compatibile con le 2.4.9 e 2.4.8.
Che cosa contiene: account aziendali con più acquirenti sotto un'unica azienda, ruoli e gerarchia; cataloghi condivisi con prezzi personalizzati per azienda; preventivi negoziabili, cioè la trattativa sul prezzo dentro la piattaforma; ordini d'acquisto con flussi di approvazione; liste di approvvigionamento e ordine rapido. È l'insieme di funzioni che sulle altre piattaforme di questa serie non esiste nativamente o esiste in forma ridotta — e ad Adobe Summit 2026 sono state annunciate anche le componenti B2B per lo storefront Edge Delivery.
Per chi resta su Open Source, il B2B va ricostruito con estensioni di terze parti: è fattibile e si fa, ma è un progetto. Il confronto fra quel progetto e il costo di Adobe Commerce più licenza B2B è la valutazione centrale di moltissimi capitolati.
App Builder e API Mesh
Sono gli strumenti con cui Adobe spinge l'estensibilità fuori dal processo: invece di aggiungere codice dentro il monolite, si scrivono applicazioni serverless che reagiscono agli eventi della piattaforma, e si compongono più sorgenti dati dietro un unico endpoint GraphQL. Su Adobe Commerce as a Cloud Service è l'unica via di personalizzazione possibile, perché il core non è modificabile. È anche il motivo tecnico per cui, in prospettiva, il problema storico dei conflitti fra estensioni si riduce: se nessuno modifica il core, nessuno confligge.
Il front-end: quattro strade, prezzi diversi
Luma e Blank, i temi del core: gratuiti, gli unici disponibili senza costi aggiuntivi, tecnicamente datati. Non risulta una deprecazione formale, ma Adobe Commerce as a Cloud Service non supporta gli storefront Luma: di fatto sono fuori dal percorso SaaS.
PWA Studio: il repository non è archiviato e l'ultima versione è del maggio 2026; non risulta una deprecazione ufficiale, ma altrettanto chiaramente non è più la direzione strategica di Adobe, che punta su Edge Delivery.
Hyvä: costruito su Alpine.js e Tailwind, con JavaScript drasticamente ridotto rispetto a Luma. È oggi la scelta dominante nella community Open Source. Licenza commerciale, una installazione per licenza, con i prezzi pubblici riportati nella sezione sui costi.
Adobe Commerce Storefront su Edge Delivery Services: componenti pronti che parlano alle API GraphQL dal browser, con i contenuti scritti in documenti. Backend supportati: Adobe Commerce on Cloud, as a Cloud Service e Optimizer. Magento Open Source non è fra i backend supportati.
Le integrazioni che servono in Italia
Il core Magento non prevede nulla di ciò che serve a fatturare in Italia: niente codice fiscale, niente partita IVA al checkout, niente codice destinatario del Sistema di Interscambio, niente distinzione fra privato e azienda, e fra i corrieri nativi solo UPS, USPS, FedEx e DHL. Esiste però un ecosistema italiano di estensioni commerciali consolidato che copre esattamente questi punti, con lo stesso schema: attributi cliente e indirizzo aggiuntivi, validazione, interruttore privato/azienda ed esportazione verso il tracciato XML per lo SdI.
La conseguenza pratica da mettere nel preventivo: su Magento la conformità fiscale italiana è sempre una voce di costo, mai una configurazione. È una delle differenze concrete rispetto a PrestaShop e WooCommerce, dove esistono anche soluzioni gratuite mature.
Configurazione e personalizzazione del negozio
La sequenza operativa
Scelta dell'edizione. È il primo bivio e determina tutto il resto: Open Source, Adobe Commerce on Cloud, as a Cloud Service o Optimizer. Si decide sulla base delle funzioni necessarie (B2B? ricerca gestita?) e del modello di personalizzazione (codice nel core o fuori).
Infrastruttura. Stack completo — database, OpenSearch, Valkey, RabbitMQ, Varnish, cron funzionante — più un ambiente di collaudo, che su Magento non è un lusso.
Struttura multi-sito. Siti web, negozi e viste vanno disegnati prima del catalogo, perché lo scope delle configurazioni e dei prezzi si aggancia lì ed è costoso da rifare.
Attributi e set di attributi, cioè il modello dati del catalogo. È la decisione più costosa da cambiare dopo, perché ci si appendono ricerca, filtri, indicizzatori, feed e integrazioni.
Fonti di inventario e regole di assegnazione, se vendi da più magazzini.
Tasse, gruppi di clienti, regole di prezzo, corrieri e metodi di pagamento.
Tema. Luma, Hyvä o Edge Delivery — con la scelta presa consapevolmente e a budget, non per inerzia.
Estensioni italiane per campi fiscali e fatturazione elettronica.
Indicizzatori in modalità pianificata, cache e Varnish, prima di andare in produzione.
Consenso, misurazione, pagine legali e procedura di applicazione delle patch.
Le due regole d'oro della personalizzazione
Prima: non si modifica mai il codice in vendor/. Ogni modifica lì viene cancellata al primo composer update, e ogni patch di sicurezza diventa un conflitto da risolvere a mano. Le strade corrette sono un modulo proprio in app/code, un plugin, un osservatore o la preferenza di classe.
Seconda: attenzione ai plugin around. Due estensioni che intercettano lo stesso metodo con un plugin di quel tipo, o che sovrascrivono lo stesso template, producono comportamenti imprevedibili in cui l'ordine di esecuzione diventa determinante. È il difetto strutturale dell'ecosistema Magento, ed è la ragione per cui la documentazione raccomanda before e after e per cui Adobe spinge l'estensibilità fuori dal processo con App Builder.
Prestazioni: le leve, e una che non esiste più
Varnish come cache di pagina intera è la configurazione di produzione raccomandata; la cache interna su filesystem o su Valkey è per lo sviluppo.
Indicizzatori in modalità «aggiorna su pianificazione»: la reindicizzazione avviene in modo asincrono via cron sui registri delle modifiche, invece che al salvataggio. È la differenza fra un pannello usabile e un pannello che si blocca a ogni importazione.
Valkey per cache e sessioni, secondo la matrice ufficiale corrente.
Il database separato non è più una strategia valida. La funzione di split database è deprecata dalla versione 2.4.2 e Adobe documenta la procedura per tornare a un database unico. Chi la trova ancora citata in un capitolato sta leggendo materiale vecchio di cinque anni.
Sul fronte dell'esperienza utente, il problema noto è strutturale e riguarda Luma: RequireJS e Knockout.js con decine di bundle JavaScript penalizzano i tempi di caricamento e di risposta. È esattamente la motivazione dichiarata dietro Hyvä e dietro Edge Delivery Services. Va detto però che Adobe non pubblica benchmark ufficiali che quantifichino il divario: i confronti in circolazione sono di agenzie, e come tali vanno letti.
Sicurezza: la parte che non si può rimandare
Su Magento la manutenzione della sicurezza non è una buona pratica: è la condizione per restare online. Due casi recenti lo dimostrano meglio di qualsiasi raccomandazione.
CosmicSting (CVE-2024-34102), divulgata nel settembre 2024, è stata descritta dai ricercatori che l'hanno documentata come il peggior difetto che avesse colpito i negozi Magento in due anni: oltre 4.000 negozi compromessi, con una stima che a un certo punto della campagna indicava circa il 75% degli store ancora vulnerabili.
SessionReaper (CVE-2025-54236), divulgata l'8 settembre 2025, è un'esecuzione di codice da remoto senza autenticazione, sfruttabile attraverso il modulo dell'indirizzo cliente. Lo sfruttamento attivo è stato confermato da ottobre 2025, con oltre 250 negozi colpiti in una sola notte e, secondo la stessa ricerca, tre negozi su cinque ancora vulnerabili all'inizio degli attacchi.
Adobe pubblica bollettini con cadenza di circa due mesi, più patch fuori ciclo per i casi critici, e coprono sia Adobe Commerce sia Magento Open Source: il bollettino dell'11 agosto 2026, per esempio, ha corretto sette vulnerabilità su Adobe Commerce dalla 2.4.4 alla 2.4.9, su Magento Open Source dalla 2.4.6 alla 2.4.9 e sul modulo B2B. Esiste inoltre uno strumento di scansione di sicurezza gratuito, accessibile dal proprio account, che esegue oltre 21.000 controlli con scansioni pianificabili settimanali e storico dei report: attivarlo è la prima cosa da fare su un negozio ereditato.
Da qui il piano minimo, che non è negoziabile: finestra ricorrente di applicazione delle patch con ambiente di collaudo, scansione periodica, inventario delle estensioni con la data dell'ultimo aggiornamento di ciascuna, e un piano per il giorno in cui la tua versione esce dal supporto — che su Open Source arriva prima, perché l'extended support non c'è.
Conformità
Gli obblighi di un negozio online italiano ed europeo — informazioni obbligatorie, recesso e garanzia legale, regola dei trenta giorni sugli annunci di riduzione di prezzo, recensioni, informazioni GPSR sulla scheda prodotto, accessibilità, cookie e consenso, IVA e regime OSS, imballaggi e RAEE — non dipendono dalla piattaforma. Li abbiamo trattati per esteso nella guida alla piattaforma Shopify e valgono identici qui. Su Magento c'è però un vantaggio strutturale: il sistema di attributi rende banale modellare i campi obbligatori del GPSR e i nuovi dati su durabilità e riparabilità applicabili dal 27 settembre 2026, con validazioni e visibilità configurabili dal pannello e senza toccare codice.
Alternative a Magento e confronto
Stessa regola di redazione delle altre nostre guide: dove il fornitore non pubblica il prezzo, qui c'è scritto «non pubblico». Dati verificati a settembre 2026.
Il confronto in una tabella
Piattaforma | Modello | Prezzo di listino | Commissione sul transato | B2B nativo |
|---|---|---|---|---|
Magento Open Source | Open source OSL 3.0, self-hosted | Gratuito; stack e front-end a parte | Nessuna | No (da ricostruire con estensioni) |
Adobe Commerce | PaaS, SaaS e Optimizer | Non pubblico | Non pubblico | Sì, con licenza separata |
SaaS | 39-399 $/mese; Plus da 2.300 $/mese | 2,9%-2,5% su carta, più 2%-0,2% se non usi Shopify Payments | Parziale: dal 2 aprile 2026 anche sui piani non Plus, con 3 cataloghi | |
PrestaShop | Open source OSL 3.0, con offerta ospitata | Classic gratuito; Hosted 24-29 €/mese +IVA | Nessuna | Parziale: gruppi clienti, prezzi specifici, modalità B2B |
WooCommerce | Open source GPL, plugin WordPress | Gratuito; hosting ed estensioni a parte | Nessuna. WooPayments in Italia 1,50% + 0,25 € | No, da costruire con estensioni |
Shopware | Community Edition MIT + edizioni commerciali | CE gratuita; Rise da 600 €/mese, Evolve da 2.400 €/mese | Prezzo legato al GMV, in trattativa | Sì, nelle edizioni commerciali |
commercetools | SaaS headless (MACH) | Non pubblico | Modello dichiarato a ordini, non a GMV | Sì |
Sylius | Open source MIT su Symfony, headless | Core gratuito; Sylius Plus non pubblico | Nessuna | Modulo B2B nella licenza commerciale |
Magento contro Shopify Plus
È il confronto che si presenta in quasi ogni gara di fascia alta, e ha una particolarità: nessuno dei due pubblica il prezzo che conta. Shopify pubblica «da 2.300 dollari al mese» per Plus ma negozia commissioni e condizioni; Adobe non pubblica nulla.
Le differenze sostanziali sono altre tre. Il controllo: su Adobe Commerce on Cloud personalizzi il backend fin nelle regole di prezzo, su Shopify il checkout è personalizzabile solo con estensioni entro i limiti previsti. Il B2B: quello di Magento è più profondo — cataloghi condivisi per azienda, preventivi negoziabili, ordini d'acquisto con approvazioni — anche se costa una licenza a parte, mentre quello di Shopify copre il B2B semplice ed è ora disponibile anche sui piani inferiori. Il costo di esercizio: su Shopify l'infrastruttura, gli aggiornamenti, la conformità PCI e la continuità sono inclusi; su Magento sono tutti a carico tuo o del tuo integratore, e le due vulnerabilità critiche del biennio scorso mostrano che cosa succede quando quella responsabilità non è presidiata.
Il criterio pratico: si sceglie Magento quando il modello di vendita non entra in un carrello standard — configurazioni complesse, listini contrattuali, molte entità organizzative, integrazioni profonde con l'ERP — e si sceglie Shopify quando la complessità è nel marketing e nella velocità di esecuzione, non nel modello di dominio.
Magento contro PrestaShop e WooCommerce
Rispetto alle altre due open source di questa serie, Magento occupa un piano diverso, e il confronto ha senso solo se si guarda la dimensione del progetto.
WooCommerce vince su semplicità, contenuti e disponibilità di competenze; perde su profondità del modello di catalogo e su tutto ciò che riguarda multi-sito e regole di prezzo complesse. PrestaShop è il concorrente più vicino sul multinegozio nativo e sui gruppi di clienti, con un costo di gestione nettamente inferiore, ma non ha nulla di paragonabile all'inventario multi-sorgente, ai tipi di prodotto bundle e alla granularità dello scope di configurazione. Magento vince quando il catalogo o l'organizzazione sono complessi davvero, e perde in tutti gli altri casi, perché fa pagare quella potenza in requisiti, competenze e manutenzione anche a chi non la usa.
La domanda che risolve il confronto è una sola: quante di quelle funzioni userai davvero nei prossimi tre anni? Se la risposta è «due o tre», la piattaforma sbagliata è Magento.
Mage-OS: l'alternativa dentro Magento
È la voce che manca in quasi tutti i confronti e che nel 2026 è diventata rilevante. Mage-OS è una distribuzione open source costruita su Magento Open Source — oggi basata sulla 2.4.9, con piena compatibilità a monte — governata da un'associazione della community, senza azionisti né investitori, e dichiaratamente non affiliata ad Adobe o a Magento Open Source. Il sito dichiara oltre 215 sostenitori finanziari e più di 154 mila euro raccolti.
Quello che la rende una destinazione concreta e non un esercizio ideologico è il ritmo: Mage-OS 3.0 a maggio 2026 con nuovo installatore, supporto ai resi merce e compatibilità PHP 8.5, poi 3.1 a giugno, 3.2 e 3.3 a luglio e agosto con correzioni di sicurezza, e 3.4.0 l'11 agosto 2026 — lo stesso giorno del bollettino Adobe, di cui porta le patch. Cioè: le correzioni di sicurezza arrivano in tempi paragonabili a quelli ufficiali, e in più il progetto aggiunge funzioni che Adobe non ha.
Per chi resta su Open Source e si trova senza extended support alla fine del ciclo di una versione, è oggi l'unica risposta strutturata — con l'avvertenza onesta che il progetto non pubblica una roadmap 2026 formalizzata, quindi va valutato sulla cadenza dimostrata, non su promesse.
Come si decide: cinque domande
Il tuo modello di vendita entra in un carrello standard? Se sì, Magento è sovradimensionata.
Ti serve il B2B strutturato — aziende, cataloghi per cliente, preventivi negoziabili, approvazioni? È il caso d'uso in cui Magento non ha equivalenti — ma è Adobe Commerce, con licenza separata, non Open Source.
Quanti siti, mercati e viste devi gestire? Oltre tre o quattro, la gerarchia di scope di Magento inizia a ripagare la complessità.
Chi applica le patch di sicurezza, e con quale frequenza? Su questa piattaforma è la domanda che separa un progetto sano da un incidente annunciato.
Hai messo a budget il front-end? Restare su Luma ha un costo in conversione; uscirne ha un costo in licenza e sviluppo. Una delle due va scelta consapevolmente.
Strategie di crescita usando Magento
I numeri su cui si decide
I soliti cinque — tasso di conversione, valore medio dell'ordine, costo di acquisizione, tasso di riacquisto e margine di contribuzione dopo spedizione, resi e commissioni — con una specificità di questa piattaforma: su un'installazione multi-sito vanno letti per sito web e per vista negozio, non aggregati. È frequentissimo che un mercato o un marchio finanzi le perdite di un altro senza che il cruscotto lo mostri.
Il B2B, che è dove Magento restituisce l'investimento
Se c'è una strategia di crescita specifica di questa piattaforma, è questa. Il passaggio da un canale di vendita telefonico o via e-mail a un portale con account aziendali, listini contrattuali per cliente, riordino rapido da liste, preventivi negoziabili e ordini con approvazione è il tipo di progetto che sposta punti di margine, non decimi: elimina lavoro d'ufficio, riduce gli errori d'ordine e rende il riordino più veloce dell'e-mail al commerciale, che è l'unico modo per farlo adottare davvero.
Le condizioni per riuscirci sono quelle della nostra guida dedicata al costo di un eCommerce B2B: i prezzi devono coincidere con quelli che fattura il gestionale, ogni integrazione va contata separatamente, e serve in squadra qualcuno che conosca il processo commerciale dell'azienda e non solo il software.
Il front-end: il salto di conversione più grande disponibile
Su moltissimi negozi Magento la singola azione con il maggior effetto sui ricavi non è una campagna: è uscire da Luma. Il tema del core porta un impianto JavaScript di due generazioni fa, e le alternative — Hyvä sul percorso Open Source e PaaS, Edge Delivery sulle edizioni Adobe — sono progettate esattamente per risolvere quel problema. È un progetto con un costo dichiarabile in anticipo, e va valutato con lo stesso metro di una campagna: quanto costa, quanto rende, in quanto tempo.
Ricerca e merchandising
Su cataloghi grandi la ricerca interna è il punto in cui si perdono più ordini di quanti se ne guadagnino con l'acquisizione. Su Adobe Commerce la risposta è nativa — Live Search con sinonimi, regole di merchandising e classificazione basata sul comportamento — e su Open Source è una voce di costo: estensione o servizio esterno. In entrambi i casi è l'investimento con il ritorno più rapido su un catalogo oltre le poche migliaia di referenze.
Multi-sito e internazionale
L'espansione su Magento è la più semplice del confronto sul piano tecnico: nuovo sito web o nuova vista, lingua, valuta, catalogo, prezzi e tasse per scope, tutto dentro la stessa installazione. La parte difficile resta fiscale e logistica — superata la soglia dei 10.000 euro di vendite a distanza intracomunitarie si applica l'IVA del paese del cliente, da assolvere con il regime OSS — e il costo di un reso transfrontaliero cancella spesso il margine dell'ordine. Si decide prima di aprire il mercato, non dopo.
Tendenze future: l'anno in cui Magento si è divisa in due
La biforcazione
Il 2026 ha reso esplicita una divisione che covava da anni. Da una parte c'è il monolite personalizzabile — Adobe Commerce on Cloud e Magento Open Source — dove il codice proprio vive dentro la piattaforma. Dall'altra c'è il modello componibile — Adobe Commerce as a Cloud Service e Optimizer — dove il core è intoccabile, l'estensibilità è fuori dal processo con App Builder, e la vetrina è Edge Delivery.
La notizia rassicurante per chi ha investito nel primo modello è arrivata il 30 marzo 2026: Adobe ha dichiarato pubblicamente che non ci sono piani di fine supporto o fine vita per la versione su cloud PaaS, e che riceverà le stesse capacità agentiche del SaaS. È l'impegno che mancava e che rendeva difficile pianificare a tre anni.
Commercio agentico: qui Adobe è avanti a tutti
È il punto in cui questa piattaforma si distingue nettamente dalle altre di questa serie. Il 18 febbraio 2026 Adobe ha annunciato il supporto sia all'Universal Commerce Protocol sia all'Agentic Commerce Protocol, oltre al protocollo per i pagamenti degli agenti già annunciato in precedenza. L'obiettivo dichiarato è rendere catalogo, prezzi e disponibilità leggibili dagli agenti e abilitare transazioni sicure attraverso entrambi gli standard, con integrazione ai sistemi di gestione ordini esistenti.
Ad Adobe Summit, ad aprile 2026, sono arrivati gli strumenti: un server MCP per Commerce con accesso sicuro e in tempo reale a catalogo, carrello, prezzi, inventario, promozioni e ordini — quindi la possibilità di costruire assistenti di acquisto e agenti vocali su misura; l'integrazione di Adobe Brand Concierge per esperienze conversazionali con dati di catalogo aggiornati; un agente per sviluppatori, annunciato come in arrivo, che analizza l'implementazione esistente e migra il codice legacy verso l'architettura a eventi; e partnership con PayPal, Stripe e Adyen per il checkout su superfici conversazionali. Va detto con precisione che diverse di queste capacità sono dichiarate come intenzioni con rilasci pianificati nel corso dell'anno, non tutte già generalmente disponibili.
Il confronto con il resto della serie è netto. Shopify ha attivato per prima la vendita dentro le interfacce conversazionali. WooCommerce e PrestaShop hanno il lato «l'agente amministra il negozio» — entrambe con MCP — e non il lato vendita. Adobe Commerce è l'unica ad aver annunciato formalmente il supporto a entrambi i protocolli di acquisto agentico, e con un impianto pensato per il mid-market e l'enterprise.
Che cosa arriva su Magento Open Source
Di tutto questo, nulla è stato annunciato per Magento Open Source: il server MCP, Brand Concierge, l'agente per sviluppatori e il supporto ai protocolli sono capacità di Adobe Commerce. Adobe dichiara che PaaS e SaaS riceveranno le stesse funzioni agentiche — il che esclude implicitamente la versione gratuita.
È la ragione per cui, guardando ai prossimi tre anni, la scelta fra Open Source e Adobe Commerce smette di essere una scelta di budget e diventa una scelta di traiettoria. Chi resta su Open Source ha oggi due risposte concrete: Mage-OS, per il ciclo di vita e le patch, e l'ecosistema attorno a Hyvä, la cui suite Enterprise introdotta il 1° luglio 2026 include un framework dichiarato pronto per l'intelligenza artificiale. Sono risposte della community, non di Adobe, ed è esattamente il punto.
Che cosa non cambierà
La qualità dei dati di catalogo, la velocità delle pagine, la chiarezza sui costi finali, la gestione dei resi e la conformità normativa. Valgono su qualsiasi piattaforma. Su Magento se ne aggiunge una sesta che è la più cara di tutte se ignorata: qualcuno deve applicare le patch. Non è un'opinione: è il contenuto dei due incidenti del 2024 e del 2025, in cui la maggioranza dei negozi colpiti era vulnerabile perché nessuno aveva installato una correzione già disponibile.
Domande frequenti
Qual è la differenza fra Magento e Adobe Commerce?
Magento Open Source è la distribuzione gratuita con licenza OSL 3.0: contiene catalogo, multi-sito, inventario multi-sorgente, regole di prezzo, checkout, CMS con Page Builder e le API. Adobe Commerce è la famiglia commerciale, oggi in tre forme: on Cloud (il monolite personalizzabile su infrastruttura Adobe), as a Cloud Service (SaaS headless, senza codice proprio nel core) e Optimizer (catalogo e vetrina davanti a un backend esistente). Le funzioni che differenziano davvero — Live Search, Product Recommendations e il modulo B2B — non sono disponibili su Open Source.
Quanto costa Adobe Commerce?
Adobe non pubblica prezzi. La pagina ufficiale dei listini mostra i tre prodotti e, per ciascuno, solo un pulsante per richiedere un preventivo: nessuna fascia, nessuna soglia di fatturato. Le cifre che si trovano online — tipicamente decine di migliaia di dollari l'anno in funzione del transato — vengono da blog di agenzie e integratori e non sono confermate da Adobe. Nemmeno sui costi di implementazione, hosting e manutenzione esiste una fonte con metodologia dichiarata. L'unico listino pubblico e verificabile del confronto è quello del tema Hyvä.
Il B2B di Magento è incluso?
No, e ci sono due sorprese da conoscere. La prima: il modulo B2B è disponibile solo per Adobe Commerce e non è autorizzato su Magento Open Source. La seconda: Adobe lo classifica fra le estensioni che richiedono una licenza separata, quindi non è automaticamente incluso nella licenza Adobe Commerce e va negoziato a parte. Contiene account aziendali con ruoli e gerarchia, cataloghi condivisi con prezzi per azienda, preventivi negoziabili, ordini d'acquisto con approvazioni, liste di approvvigionamento e ordine rapido. La versione corrente è la 1.5.3 del 12 maggio 2026.
Quale versione di Magento devo usare nel 2026?
La 2.4.9, rilasciata il 12 maggio 2026 e supportata fino al 31 maggio 2029. Attenzione al calendario: il supporto regolare della 2.4.6 è terminato l'11 agosto 2026 e quello della 2.4.7 scade il 31 maggio 2027. L'extended support, cioè l'anno aggiuntivo di patch senza costi ulteriori, è riservato ai clienti Adobe Commerce: chi sta su Magento Open Source, alla fine del supporto regolare, resta scoperto. La 2.4.9 richiede PHP 8.5, OpenSearch 3, Valkey 9, RabbitMQ e Varnish 8 — uno stack che esclude l'hosting condiviso.
Devo restare su Luma o passare a Hyvä?
Dipende dall'edizione, ed è una decisione di budget più che di gusto. Luma è gratuito ma tecnicamente datato — RequireJS e Knockout.js, molti bundle JavaScript — e pesa sulle metriche di esperienza utente; non risulta formalmente deprecato, ma Adobe Commerce as a Cloud Service non lo supporta. Hyvä è la scelta dominante nella community, con licenza commerciale e prezzi pubblici: 3.000 € l'anno per Hyvä Commerce, 1.000 € per il checkout, 250 € per la UI, e dal 1° luglio 2026 la suite Enterprise a 7.500 € il primo anno e 5.000 € di rinnovo. Edge Delivery Services è l'alternativa Adobe, ma non è disponibile per Magento Open Source.
Magento è sicuro?
La piattaforma riceve patch con cadenza di circa due mesi, più correzioni fuori ciclo per i casi critici, e i bollettini coprono sia Adobe Commerce sia Magento Open Source; esiste inoltre uno strumento di scansione gratuito con oltre 21.000 controlli. Il problema non è la piattaforma: è chi non applica le patch. Con CosmicSting (2024) sono stati compromessi oltre 4.000 negozi, con una stima di circa il 75% degli store ancora vulnerabili in una fase della campagna; con SessionReaper (2025), un'esecuzione di codice da remoto senza autenticazione, sono stati colpiti oltre 250 negozi in una sola notte, con tre negozi su cinque ancora vulnerabili. Su Magento la finestra di applicazione delle patch è parte del contratto di manutenzione, non un optional.
Che cos'è Mage-OS e quando ha senso?
È una distribuzione open source costruita su Magento Open Source — oggi sulla 2.4.9, compatibile a monte — governata da un'associazione della community, senza azionisti, e non affiliata ad Adobe. Ha senso soprattutto per chi resta su Open Source e si troverà senza extended support alla fine del ciclo della propria versione, perché porta le patch di sicurezza Adobe in tempi molto rapidi — la 3.4.0 è uscita l'11 agosto 2026, lo stesso giorno del bollettino Adobe di cui contiene le correzioni — e aggiunge funzioni che il core non ha, come la gestione dei resi merce. Va valutata sulla cadenza dimostrata, perché non pubblica una roadmap formalizzata.
Magento va bene per gli adempimenti italiani?
Funziona, ma è sempre una voce di costo. Il core non prevede nativamente codice fiscale, partita IVA, codice destinatario del Sistema di Interscambio né la distinzione fra privato e azienda al checkout, e fra i corrieri nativi ci sono solo UPS, USPS, FedEx e DHL. Esiste però un ecosistema italiano di estensioni commerciali consolidato che copre esattamente questi punti, con attributi aggiuntivi, validazione e generazione del tracciato XML per lo SdI. È una differenza concreta rispetto a PrestaShop e WooCommerce, dove per gli stessi adempimenti esistono anche soluzioni gratuite mature. In compenso, il sistema di attributi di Magento rende più semplice che altrove modellare i campi obbligatori del GPSR e i nuovi dati su durabilità e riparabilità.
In sintesi
Magento è la scelta giusta quando il tuo modello di vendita non entra in un carrello standard: cataloghi tecnici con molti attributi, prodotti componibili, inventario su più magazzini, molti siti e mercati con configurazioni ereditate, e soprattutto un B2B strutturato con account aziendali, listini contrattuali e ordini con approvazione. In quei casi non ha equivalenti a parità di controllo. È la scelta sbagliata in tutti gli altri, perché fa pagare quella potenza in requisiti, competenze e manutenzione anche a chi non la usa.
Le tre cose da portare via, se ne resta spazio solo per tre. Primo: «Magento» sono quattro prodotti diversi, e le funzioni per cui probabilmente la stai valutando — ricerca gestita, raccomandazioni, B2B — non sono nella versione gratuita, e il B2B richiede perfino una licenza a parte. Secondo: nessuno pubblica i prezzi, quindi il budget si costruisce con il metodo — preventivi a tre anni, elenco esplicito di ciò che non è incluso nell'edizione scelta, front-end messo a bilancio dall'inizio. Terzo: la manutenzione della sicurezza non è opzionale, e i due incidenti del 2024 e del 2025 lo hanno dimostrato su migliaia di negozi che avevano la patch disponibile e non l'avevano installata.
Se stai valutando Magento per la tua azienda, o hai un negozio da aggiornare alla 2.4.9, da portare su un front-end moderno o da mettere in sicurezza, su FreelanceWWW trovi professionisti che lavorano su moduli, temi, migrazioni e integrazioni con l'ERP: pubblica il tuo progetto e ricevi le offerte dai freelance che quel lavoro lo hanno già fatto. Se invece stai ancora confrontando le piattaforme, leggi anche le nostre guide complete a Shopify, WooCommerce e PrestaShop.