Alla fine di marzo, all’Adobe Summit, Adobe ha annunciato Adobe Commerce as a Cloud Service (ACCS) e Commerce Optimizer. Da quando lavoro su questa piattaforma — ho cominciato su Magento 1 nel 2011 e ho seguito da vicino tutta l’evoluzione fino ad Adobe Commerce Cloud — non ricordo un annuncio che tocchi in modo cosi diretto il modo in cui costruiamo e manteniamo i progetti. Non e una feature in piu: e un cambio di modello di erogazione. Vale la pena capire cosa significa davvero, prima di lasciarsi trascinare dalle slide.
Premessa onesta: in questo momento parliamo di un annuncio. La general availability non c’e ancora, e molte delle cose che scrivo qui vanno verificate quando il prodotto sara realmente in mano nostra. Ma la direzione e chiara, ed e su quella che voglio ragionare.
Da PaaS a SaaS: cosa cambia sotto il cofano
Fino a oggi Adobe Commerce, anche nella versione Cloud, e sostanzialmente un PaaS: Adobe ti fornisce l’infrastruttura gestita, ma il codice applicativo e tuo. Hai accesso al filesystem, ai moduli custom, alla pipeline di deploy, alle patch da applicare. Con questa liberta arriva anche il peso: ogni upgrade e un progetto, ogni modulo di terze parti e una potenziale sorgente di conflitti, ogni security patch va testata e rilasciata da qualcuno.
ACCS, per come e stato annunciato, si sposta verso un modello SaaS multi-tenant. Tradotto: l’applicazione core e gestita e aggiornata da Adobe, non piu da te. Niente piu upgrade come li conosciamo, niente piu patch da schedulare la notte, niente piu ambienti da provisionare. La personalizzazione non sparisce, ma cambia natura: si sposta dal modificare il monolite all’estendere la piattaforma dall’esterno, tramite App Builder, API e out-of-process extensibility, con Edge Delivery Services sul fronte del frontend.
Chi ha vissuto la transizione da un mondo dove “si patcha il core” a un mondo dove “il core e una black box che estendi via API” sa che questo e un cambio culturale, non solo tecnico. E secondo me e la parte piu sottovalutata dell’annuncio.
Il replatform cambia forma
Qui viene la domanda che mi fanno tutti: come cambia un progetto di replatform? La mia lettura e che cambi il baricentro dell’effort.
In un progetto Adobe Commerce classico, una fetta enorme del budget va in cose che il cliente non vede: gestione degli ambienti, upgrade path, integrazione dei moduli, hardening, tuning delle performance. Con un modello SaaS multi-tenant, buona parte di questo lavoro — se le promesse reggono — passa ad Adobe. In teoria liberi budget per quello che conta davvero per un merchant: catalogo, esperienza d’acquisto, integrazioni con ERP e sistemi di gestione, logica di business.
Ma attenzione, e qui parlo per esperienza diretta: i progetti che soffrono di piu nel passaggio a un SaaS sono quelli pieni di customizzazioni profonde sul core. Ho visto merchant fashion nel mid-market — indicativamente sui 15 milioni di GMV — con decine di moduli custom che riscrivevano comportamenti nativi del checkout o del pricing. In un mondo dove il core non e piu tuo, quel codice non “migra”: va ripensato come estensione esterna, oppure eliminato perche la piattaforma nel frattempo copre il caso in modo standard. Non e un lift-and-shift. E un ridisegno.
La mia opinione netta: chi immagina ACCS come “la stessa cosa di prima ma senza pensare ai server” si prepara a una delusione. Il valore c’e, ma si sblocca solo per chi accetta di ristrutturare l’architettura attorno all’extensibility, non di trascinarci dentro il vecchio monolite.
Manutenzione: meno lavoro invisibile, piu governance
Sul fronte manutenzione l’annuncio e quello che mi convince di piu. Gli aggiornamenti continui gestiti da Adobe, se funzionano come descritto, tolgono dal tavolo il problema che da anni erode i margini di ogni contratto di gestione: la gestione della versione. Non dover piu pianificare l’upgrade da una major all’altra, non dover piu rincorrere le security patch entro le finestre imposte dai bollettini, e un guadagno reale.
Il rovescio della medaglia — e va detto — e che perdi il controllo sul quando. In un mondo dove Adobe aggiorna il core in continuo, il merchant e chi lo assiste devono spostare energia dal “fare l’upgrade” al “verificare che l’upgrade non abbia rotto le mie estensioni”. La manutenzione non sparisce: cambia mestiere. Da lavoro di sistemistica a lavoro di regression testing e governance delle integrazioni. Chi vende contratti di AMS dovra ripensare cosa ci mette dentro.
Commerce Optimizer ed Edge Delivery: i due pezzi da capire
Due nomi da tenere d’occhio, perche raccontano dove sta andando Adobe.
Commerce Optimizer, per come e stato presentato, e la risposta a un problema molto concreto: i merchant che hanno gia un backend, magari non Adobe, e vogliono aggiungere capacita di merchandising, catalogo e discovery senza rifare tutto. E un modo per entrare nel mondo Adobe Commerce dalla porta laterale, con un approccio piu componibile e meno “tutto o niente”. Trovo interessante il segnale strategico: Adobe smette di chiedere il replatform totale come biglietto d’ingresso.
Edge Delivery Services e il fronte con cui Adobe risponde alla pressione su performance e Core Web Vitals. L’idea di servire il frontend dall’edge, disaccoppiato dal backend commerce, va nella direzione — ormai matura — del composable e dell’headless, ma con un’esperienza di authoring che punta a restare accessibile a chi crea contenuti. Sulla carta e la combinazione giusta: performance di un frontend edge, senza il costo di costruirsi da zero uno stack headless.
La mia opinione da consulente: cosa aspettarsi, cosa verificare
Sono ottimista sulla direzione. Il modello PaaS ci ha dato flessibilita, ma anche un debito di manutenzione che pesa su ogni progetto e che i merchant mid-market faticano sempre di piu a giustificare. Un SaaS multi-tenant ben fatto e la risposta naturale a questa tensione.
Detto questo, non firmo assegni in bianco su un annuncio. Prima della GA, le cose che voglio verificare con mano sono quattro:
- Il perimetro reale dell’extensibility. Quanto lontano posso spingermi con App Builder e le API prima di sbattere contro un muro? I casi B2B complessi, i pricing engine articolati, le integrazioni ERP pesanti sono il vero banco di prova.
- La storia di migrazione per chi e gia su Adobe Commerce. Esiste un percorso ragionevole dal PaaS attuale, o e di fatto un progetto nuovo? La risposta cambia radicalmente il business case.
- Il modello di controllo sugli aggiornamenti. Che strumenti ho per testare in anticipo cosa cambia, e con che preavviso? Senza questo, il SaaS diventa un rischio invece che un sollievo.
- Il costo totale reale. Meno effort sistemistico non significa automaticamente meno spesa: dipende dal pricing del servizio e da quanto lavoro di estensione resta a carico nostro.
La mia sintesi, oggi, a inizio aprile: ACCS e l’evoluzione che aspettavo, ma il diavolo sta nell’implementazione. Nei prossimi mesi il lavoro serio non e entusiasmarsi per le slide del Summit — e mettere le mani sul prodotto quando arrivera e misurare la distanza tra la promessa e la realta. Su questo blog conto di tornarci con dati veri, non con impressioni.
Mini-FAQ
Adobe Commerce as a Cloud Service e gia disponibile?
No. Al momento (aprile 2025) e stato annunciato all’Adobe Summit di marzo 2025. Non e ancora in general availability, quindi va trattato come una direzione confermata ma non come un prodotto gia in produzione.
Qual e la differenza principale tra il modello PaaS attuale e ACCS?
Nel PaaS il codice applicativo e tuo e gestisci upgrade e patch; in ACCS, modello SaaS multi-tenant, il core e gestito e aggiornato da Adobe e le personalizzazioni si realizzano come estensioni esterne via App Builder, API ed Edge Delivery.
Cosa e Commerce Optimizer?
E una proposta annunciata da Adobe per aggiungere capacita di catalogo, merchandising e discovery a un backend commerce esistente, anche non Adobe, senza un replatform completo.
Un progetto Adobe Commerce esistente puo semplicemente migrare?
Non con un lift-and-shift. Le customizzazioni profonde sul core vanno ripensate come estensioni esterne o eliminate se la piattaforma copre gia il caso in modo standard. E un ridisegno architetturale, non un travaso.
Fabio Canovi e consulente Adobe presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Lavora su progetti e-commerce dal 2011 e approfondisce l’applicazione dell’AI agentica al commercio digitale.