Per anni, quando un merchant mi chiedeva “quale versione di Adobe Commerce scelgo per il nuovo progetto?”, la risposta era quasi noiosa. C’era il PaaS su Adobe Commerce Cloud, con la sua infrastruttura gestita ma pur sempre tua da presidiare, e c’era l’on-premise per chi aveva ragioni serie per tenersi tutto in casa. La domanda vera non era “SaaS o non SaaS”, perché il SaaS puro non esisteva. Da giugno esiste. E questo, secondo me, sposta il baricentro di tutte le conversazioni di piattaforma che farò da qui in avanti.
Adobe Commerce as a Cloud Service (lo chiamerò ACCS per non ripeterlo venti volte) è andato in general availability a giugno 2025, insieme a Commerce Optimizer. Non è una beta, non è un early access con la lista d’attesa: è disponibile per i nuovi progetti adesso. Ho passato le ultime settimane a rileggermi la documentazione, a rifare i conti su un paio di progetti in pipeline e a chiedermi una cosa sola: cambia davvero il default con cui consiglio una piattaforma? La mia risposta breve è sì.
Cosa è arrivato davvero a giugno
Mettiamo ordine, perché i nomi si somigliano e la confusione è dietro l’angolo. Adobe Commerce as a Cloud Service è la versione fully SaaS di Adobe Commerce: l’infrastruttura, gli aggiornamenti, il patching e lo scaling li gestisce Adobe, non tu e non il tuo partner. Non c’è più un ambiente cloud “tuo” da monitorare, non ci sono più upgrade di versione da pianificare come progetti a sé. La personalizzazione non avviene più mettendo le mani nel core del monolite, ma out-of-process con App Builder e le API. Lo storefront naturale è Edge Delivery Services.
Commerce Optimizer è un’altra cosa e vale la pena non confonderla: è un layer SaaS di catalogo, merchandising e promozioni che puoi appoggiare sopra backend e storefront esistenti, anche non Adobe. Serve a chi vuole i servizi di catalogo moderni senza rifare la piattaforma. Utile, ma non è “la nuova Adobe Commerce”. Quando in questo articolo parlo di scelta di piattaforma, parlo di ACCS.
Perché per i nuovi progetti il default si sposta sul SaaS
Lo dico chiaramente, perché è il punto dell’articolo: per un nuovo progetto mid-market, oggi il mio default parte da ACCS, e sta al PaaS dimostrare perché dovrei sceglierlo. È l’inversione dell’onere della prova rispetto a sei mesi fa, e non è una posizione presa per moda del SaaS.
Il motivo è che la voce di costo che ho visto affossare più budget non è la licenza. È il ciclo di vita. Su un progetto Adobe Commerce Cloud tradizionale, il costo vero degli anni due, tre e quattro è fatto di upgrade di versione, security patch da applicare e testare, manutenzione dell’infrastruttura, e di tutto il tempo che il team spende a non far cadere nulla invece di far vendere di più. Ho visto merchant con GMV interessanti spendere ogni anno l’equivalente di un progetto piccolo solo per “restare fermi”: stessa piattaforma, stessa versione dell’anno prima ma aggiornata, zero feature nuove per il cliente finale.
ACCS toglie di mezzo buona parte di quella spesa strutturale. Se il patching e gli upgrade non sono più roba tua, quel budget può tornare dove serve: merchandising, checkout, contenuti, integrazioni che spostano il fatturato. Per un merchant che vive di margini e non ha un reparto IT gigante, questa è la differenza vera. Non è “è più moderno”, è “smetti di pagare per la manutenzione di una cosa che non ti dà vantaggio competitivo”.
Cosa verificare prima di dire sì
Detto questo, non sono qui a raccontarvi che ACCS sia la risposta per chiunque. Il modello SaaS ha un prezzo, e il prezzo è la libertà di fare esattamente ciò che vuoi. Ecco le cose che verifico prima di consigliarlo, e sono le stesse che consiglio di verificare a voi.
I limiti del modello
In un SaaS non entri nel core. Le personalizzazioni profonde che nel monolite risolvevi con un modulo che riscriveva mezzo checkout qui non si fanno, e non devono farsi. La domanda giusta non è “posso fare tutto come prima?” — la risposta è no — ma “le cose che facevo davvero mi servono ancora, o erano workaround diventati eredità?”. Va verificato caso per caso quali estensioni del vostro parco attuale hanno un equivalente supportato.
Le personalizzazioni e le integrazioni
Il modello di estensibilità è out-of-process: App Builder e API. Se avete integrazioni con ERP, PIM, sistemi di spedizione e fiscali — e nel B2B ne avete sempre più di quante ammettete — vanno ripensate come integrazioni event-driven e non come codice dentro Magento. È fattibile, spesso è pure più pulito, ma è lavoro di design, non un copia-incolla. Se il vostro business dipende da tre personalizzazioni molto particolari, mettetele sul tavolo il primo giorno, non l’ultimo.
La migrazione dal PaaS
E qui sono onesto: ACCS è pensato prima di tutto per i nuovi progetti, non è un bottone “migra da PaaS” premuto il quale il vostro store esistente diventa SaaS. Chi è già su Adobe Commerce Cloud con anni di customizzazioni non fa un lift-and-shift indolore. La data e il catalogo si portano, la logica custom va riprogettata secondo il nuovo modello. Chi vi promette una migrazione trasparente da monolite pieno di moduli a SaaS puro, o non ha capito il modello o vi sta vendendo qualcosa. Per un replatforming pianificato è un’ottima destinazione; per un “cambiamo hosting il mese prossimo” no.
La mia raccomandazione per il mid-market
Per un merchant mid-market che parte oggi con un progetto nuovo, o che ha già in agenda un replatforming nei prossimi dodici-diciotto mesi, ACCS è il punto di partenza da valutare per primo. Il beneficio economico non è la licenza, è liberarsi del costo ricorrente del ciclo di vita e rimettere quei soldi e quel tempo sulla crescita.
Resto invece prudente in due casi. Il primo: chi ha personalizzazioni core così specifiche da essere il cuore del vantaggio competitivo, e non riesce a riesprimerle out-of-process. Il secondo: chi è su un PaaS che funziona, è stabile e appena aggiornato — lì non c’è nessuna fretta di rincorrere il modello nuovo solo perché è nuovo. Il SaaS non premia chi si muove in preda alla FOMO, premia chi sceglie il momento giusto del proprio ciclo di vita.
La cosa che mi tengo stretta, da consulente, è che finalmente la conversazione di piattaforma non è più “quanta infrastruttura sei disposto a gestire” ma “quanto del tuo budget vuoi spendere per crescere invece che per mantenere”. È una domanda molto più sana. ACCS in GA la rende, per la prima volta, una domanda vera.
Mini-FAQ
Adobe Commerce as a Cloud Service è già disponibile?
Sì. È andato in general availability a giugno 2025, insieme a Commerce Optimizer. È disponibile per i nuovi progetti adesso, non è più in early access.
Qual è la differenza tra ACCS e Commerce Optimizer?
ACCS è la versione fully SaaS della piattaforma Adobe Commerce, con infrastruttura e aggiornamenti gestiti da Adobe. Commerce Optimizer è un layer SaaS di catalogo, merchandising e promozioni che si appoggia su backend e storefront esistenti, anche non Adobe. Sono strumenti diversi con scopi diversi.
Posso migrare il mio store PaaS esistente ad ACCS con un click?
No. ACCS è pensato soprattutto per nuovi progetti. Dati e catalogo si portano, ma la logica personalizzata va riprogettata secondo il modello out-of-process. È un replatforming pianificato, non un cambio di hosting.
Per un merchant mid-market conviene ACCS?
Per un progetto nuovo o un replatforming già in agenda, è il primo modello da valutare: il risparmio vero è eliminare il costo ricorrente di upgrade e patching. Va verificato prima che le personalizzazioni e le integrazioni critiche siano esprimibili con App Builder e le API.
Fabio Canovi è consulente Adobe presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Da anni progetta soluzioni e-commerce enterprise e approfondisce l’applicazione dell’AI agentica al commercio online.