Negli ultimi anni ho seguito diversi progetti di migrazione da Adobe Experience Manager 6.5 verso AEM as a Cloud Service, e ogni volta mi ritrovo a fare la stessa premessa con il cliente: non stiamo spostando lo stesso software su una macchina diversa. Stiamo cambiando il modo in cui il sito vive, si aggiorna e cresce. È una distinzione che sembra ovvia sulla carta, ma che sul campo fa la differenza tra una migrazione riuscita e un progetto che si trascina.
Voglio raccontare cosa cambia davvero nella pratica, dove ho visto risparmi concreti e dove invece si nascondono le insidie, e perché sono convinto che il prossimo capitolo di questa piattaforma riguarderà l’ingresso degli agenti AI nella gestione quotidiana del sito.
Aggiornamenti continui: la fine dei progetti di upgrade
La differenza più visibile è banale solo in apparenza: con AEM 6.5 l’upgrade è un progetto. Con AEM as a Cloud Service non esiste più. La piattaforma riceve aggiornamenti continui gestiti da Adobe, e il codice del cliente ci gira sopra senza le maratone di service pack che tutti conosciamo.
Su un progetto di un merchant del settore arredamento, la sola voce “upgrade AEM” nel piano pluriennale valeva più di quanto molti si aspettino: settimane di lavoro tra pianificazione, test di regressione e finestre di rilascio, ripetute a ogni ciclo. Toglierla dal tavolo non azzera il lavoro, lo sposta. Il team non ragiona più su “quando facciamo l’upgrade” ma su “il nostro codice è sempre compatibile con l’ultima versione”. È un cambio di mentalità che va accompagnato, non dato per scontato.
Qui arriva la prima insidia. Gli aggiornamenti continui funzionano se il codice rispetta le regole della piattaforma. Le Cloud Manager quality gates bloccano i deploy che non passano i controlli, e ho visto team abituati all’on-premise scoprire in modo brusco che pratiche tollerate per anni su 6.5 semplicemente non passano più. Non è una punizione: è il prezzo di una piattaforma che si aggiorna da sola.
Auto-scaling: pagare per il traffico che serve
Sul dimensionamento, AEM 6.5 mi ha sempre costretto a una domanda scomoda: per quale picco progetto l’infrastruttura? Se dimensiono per il Black Friday, pago capacità ferma undici mesi l’anno. Se dimensiono per la media, rischio di cadere proprio nel momento che conta di più.
Con AEM as a Cloud Service l’auto-scaling gestito ribalta la logica. L’ambiente publish scala in funzione del carico, e questo cambia sia i conti sia il modo di prepararsi ai picchi. Su un retailer con forte stagionalità, la conversazione è passata da “compriamo server per stare tranquilli” a “verifichiamo che il codice e la cache reggano lo scaling”. Il collo di bottiglia si sposta dall’hardware all’architettura applicativa, ed è lì che secondo me va concentrata l’attenzione.
Sia chiaro: l’auto-scaling non è una bacchetta magica. Una dispatcher cache mal configurata o query pesanti verso il repository fanno danni a qualsiasi scala. Il cloud non perdona il codice scritto male, lo rende solo più costoso.
Cloud Manager: il deploy diventa disciplina
Il terzo pilastro è Cloud Manager, la pipeline CI/CD che Adobe impone come unica via per portare codice in produzione. Su 6.5 ogni cliente aveva la sua ricetta artigianale per i deploy, con tutta la fragilità del caso. Qui il percorso è uno solo, con test automatici, analisi statica del codice e controlli di performance e sicurezza incorporati.
La mia opinione, dopo averlo usato su più progetti, è che il vero valore di Cloud Manager non sia tecnico ma organizzativo. Standardizza il modo in cui un team rilascia, e riduce quella categoria di incidenti che nascono da un deploy fatto “a mano” di venerdì sera. Il rovescio della medaglia è che la pipeline è rigida per scelta: chi cerca scorciatoie le trova sbarrate. Ho imparato a presentarlo ai team come una guardrail, non come una gabbia.
Sommando i tre elementi, l’impatto su costi, manutenzione e time-to-market è concreto. Meno tempo speso a mantenere in piedi l’infrastruttura e a gestire upgrade significa più tempo dedicato al contenuto e alle esperienze. La spesa si sposta da capitale immobilizzato a costo operativo legato all’uso, e per molte aziende è un modello più leggibile. Ma il risparmio non è automatico: si materializza solo se il team smette di trattare il cloud come un data center in affitto e ne adotta davvero le pratiche.
Integrazione con il commerce
C’è un aspetto che mi sta particolarmente a cuore, perché lavoro da anni a cavallo tra content e commerce: l’integrazione tra AEM e Adobe Commerce. La combinazione classica vede AEM gestire l’esperienza editoriale e di contenuto, e Adobe Commerce fornire catalogo, prezzi e checkout, con i due mondi che dialogano tramite le Commerce Integration disponibili sulla piattaforma.
Nella pratica, il punto delicato non è “far parlare” i due sistemi, è decidere chi è la fonte di verità per ogni dato. Su un progetto fashion, gran parte delle discussioni non riguardava la tecnologia ma la governance: il contenuto di prodotto arricchito vive in AEM o in Commerce? Dove sta il dato di catalogo? La mia posizione è netta: separare in modo pulito il dominio “esperienza” da quello “transazione”, e resistere alla tentazione di duplicare la logica di business in AEM. Quando questa disciplina manca, l’integrazione tecnica regge ma il modello dei contenuti diventa ingestibile nel giro di pochi mesi.
Perché il prossimo passo saranno gli agenti
Arrivo alla parte su cui mi espongo di più. Sto approfondendo molto l’AI agentica, e guardando ad AEM as a Cloud Service vedo un terreno quasi ideale perché ci entrino gli agenti.
Il motivo è strutturale. Gli agenti danno il meglio dove esistono API pulite, ambienti standardizzati e azioni con esiti verificabili. È esattamente ciò che questa piattaforma offre oggi: gestione dei contenuti via API, pipeline di deploy governate da Cloud Manager, ambienti uniformi. Un agente non deve indovinare com’è fatto l’ambiente del singolo cliente, perché la piattaforma è la stessa per tutti.
Nel breve mi aspetto agenti che alleggeriscono il lavoro ripetitivo attorno al contenuto: generare varianti di una pagina, proporre metadati e alt text, controllare la coerenza tra versioni linguistiche, segnalare asset orfani o link rotti. Compiti oggi manuali, noiosi e proprio per questo trascurati. Più avanti immagino agenti che agiscono lungo la pipeline, aiutando a interpretare un quality gate fallito o a preparare una modifica prima di sottoporla a revisione umana.
Sono ottimista, ma non ingenuo. Un agente che tocca contenuti in produzione va tenuto dentro guardrail severi: permessi limitati, azioni tracciate, un umano che approva ciò che conta. Il valore, secondo me, non sarà “il sito che si gestisce da solo”, formula che non mi convince. Sarà togliere alle persone il lavoro a basso valore per lasciare loro le decisioni. E una piattaforma standardizzata e governata come AEM as a Cloud Service è, oggi, il posto più naturale perché questo cominci ad accadere.
In sintesi
Il passaggio da AEM 6.5 ad AEM as a Cloud Service non è un cambio di hosting: è un cambio di modello operativo. Gli aggiornamenti continui eliminano i progetti di upgrade, l’auto-scaling sposta il collo di bottiglia dall’hardware al codice, Cloud Manager trasforma il deploy in disciplina. I benefici su costi, manutenzione e time-to-market sono reali ma condizionati: arrivano solo a chi adotta davvero le pratiche del cloud. E il prossimo passo, ne sono convinto, sarà l’ingresso graduale degli agenti AI nella gestione del contenuto e della pipeline.
Mini-FAQ
Qual è la differenza principale tra AEM 6.5 e AEM as a Cloud Service?
AEM 6.5 richiede progetti di upgrade periodici e infrastruttura dimensionata a mano. AEM as a Cloud Service riceve aggiornamenti continui gestiti da Adobe, scala automaticamente in base al carico e impone i deploy tramite Cloud Manager.
Migrare ad AEM as a Cloud Service fa risparmiare?
Riduce i costi di manutenzione e la capacità infrastrutturale inutilizzata, spostando la spesa da capitale a costo operativo. Il risparmio però si concretizza solo se il team adotta le pratiche del cloud e scrive codice compatibile con le quality gate.
Come si integra AEM as a Cloud Service con Adobe Commerce?
AEM gestisce esperienza e contenuto, Adobe Commerce gestisce catalogo, prezzi e checkout, con integrazione tramite le Commerce Integration della piattaforma. Il punto critico è la governance: definire chiaramente quale sistema è la fonte di verità per ciascun dato.
Gli agenti AI possono già gestire un sito AEM?
Non in autonomia. La direzione plausibile è quella di agenti che assistono il lavoro ripetitivo sui contenuti e lungo la pipeline, sempre dentro permessi limitati, azioni tracciate e approvazione umana sulle modifiche rilevanti.
Chi sono. Sono un consulente Adobe presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Da tempo approfondisco l’AI agentica e il suo impatto sull’e-commerce e sulla gestione dei contenuti.