La manutenzione di SAP ECC finisce il 31 dicembre 2027: un aumento di prezzo, non uno spegnimento

Il 31 dicembre 2027 SAP chiude la manutenzione mainstream per SAP ECC 6.0 e per le altre applicazioni core di SAP Business Suite 7. Il 1° gennaio 2028 non si spegne nulla. Il vostro sistema continua a girare, gli utenti continuano a registrare fatture e SAP continua a vendervi assistenza. Cambiano quanto la pagate e cosa ricevete.

La distinzione conta, perché molti dei consigli in circolazione trattano il 2027 come un precipizio. Per la maggior parte delle aziende ancora su ECC non lo è, e lo sanno: il gruppo più numeroso di utenti ECC rimasti sta pianificando sul 2030. Il rischio vero è un altro. Il lavoro che decide davvero la data (ABAP personalizzato, interfacce, dati) viene dimensionato tardi, e il 2030 si rivela stretto quanto lo era il 2027.

Questo articolo è per CIO e responsabili SAP di aziende di medie dimensioni, per lo più nei mercati di lingua tedesca, che usano ancora ECC e devono decidere come saranno i prossimi tre anni.

Cosa si è davvero impegnata a fare SAP

Le condizioni sono nella pagina sulla strategia di manutenzione di SAP e sono state annunciate per la prima volta a febbraio 2020:

• Fino al 31 dicembre 2027: manutenzione mainstream per le applicazioni core di Business Suite 7, tra cui SAP ERP 6.0, sugli ultimi tre enhancement package. Se il vostro sistema è su un enhancement package più vecchio, controllate la SAP Note 2881788 (collegata da quella pagina) prima di costruire un piano sulla data del 2027.
• Dal 1° gennaio 2028 al 31 dicembre 2030: manutenzione estesa facoltativa, con «una maggiorazione di due punti percentuali sulla base di manutenzione». In parole semplici, l'aliquota di manutenzione che pagate oggi sale di due punti.
• Se non sottoscrivete la manutenzione estesa: passate automaticamente alla manutenzione specifica per il cliente. Cosa copre è descritto nella SAP Note 52505, collegata dalla stessa pagina. Leggetela prima di dare per scontato che basti.
• Per S/4HANA: SAP si è impegnata a garantire la manutenzione fino alla fine del 2040.

Per un gruppo più ristretto c'è un'ulteriore strada. Ad agosto 2025 SAP ha definito la SAP ERP, private edition, transition option: un abbonamento a tempo che porta ECC dal 2031 al 2033 dentro il cloud privato di SAP. Le condizioni sono rigide. «I sistemi devono essere migrati a SAP ERP, private edition su SAP HANA prima del 31 dicembre 2030.» HANA è l'unico database supportato, l'opzione è disponibile solo insieme al piano max success per il periodo dal 2031 al 2033, e SAP fissa un minimo di 2 TB per i sistemi sottoscritti con questa formula. SAP dice che è pensata per «i nostri clienti SAP ERP più grandi e complessi». Le «condizioni commercialmente equivalenti» offerte da SAP valevano per i clienti che si sono impegnati sulla private edition entro la fine del 2025.

Qualunque livello scegliate, fate per iscritto una domanda a SAP e al vostro partner: quali modifiche normative (fisco, paghe, formati di fatturazione elettronica) continueranno ad arrivare sul vostro sistema ECC, e fino a quando. Per un'azienda tedesca, questa risposta da sola può decidere se restare dove si è sia praticabile.

Cosa sta facendo il resto del mercato

La DSAG, l'associazione degli utenti SAP di lingua tedesca, ha condotto il suo Investment Report 2026 con 198 partecipanti tra l'8 dicembre 2025 e il 21 gennaio 2026. Di questi, il 54% usa ancora ECC o la vecchia Business Suite, contro il 68% del 2024.

Sui tempi, quasi la metà dei partecipanti prevede di passare a S/4HANA entro la fine del 2030, il che, come fa notare la DSAG, significa pagare la manutenzione estesa. Un altro 37% vuole passare entro la fine del 2027, e appena il 4% punta al 2033 e alla private edition transition option.

Il presidente della DSAG, Jens Hungershausen, ha spiegato i motivi senza giri di parole: carenza di competenze, progetti di trasformazione paralleli e budget limitati stanno facendo slittare i calendari, «anche se questo comporta costi di manutenzione più alti».

Anche gli acquirenti pubblici si muovono. Il nostro conteggio dei bandi di gara pubblici nell'UE trova circa 200 procedure di migrazione a S/4HANA per semestre nel 2025 e nel 2026, e più di 300 nel 2026 a inizio ottobre, la maggior parte in Germania. Il lavoro si sta facendo. È distribuito su un arco di tempo più lungo di quanto lascino pensare i titoli sul 2027.

Dove sta davvero il lavoro

La conversione tecnica da ECC a S/4HANA è ben supportata dagli strumenti di SAP e dei suoi partner. Se usate un ECC poco personalizzato con una manciata di interfacce standard, il vostro integratore l'ha fatto molte volte e quasi tutto ciò che segue non è un vostro problema.

Lo diventa in proporzione a quanto avete costruito da soli.

ABAP personalizzato: dove i progetti slittano

S/4HANA non è ECC su un nuovo database. Parti del modello dati sono cambiate. Clienti e fornitori diventano business partner. Le registrazioni di contabilità e magazzino sono state consolidate in tabelle meno numerose e più larghe. Alcune transazioni e funzioni sono state eliminate o sostituite.

Il codice personalizzato che legge direttamente le tabelle, si appoggia a un exit che si è spostato o presuppone in silenzio un ordinamento (HANA non ne garantisce uno se la query non lo chiede) può superare un controllo di sintassi e fare comunque la cosa sbagliata. È quest'ultimo tipo che fa male, perché emerge nei test di integrazione o dopo l'avvio, non nella scansione del codice.

Il processo che funziona:

1. Misurate prima l'utilizzo. Attivate la registrazione dell'utilizzo in produzione (l'ABAP call monitor, transazione SCMON) e lasciatela girare per un'intera chiusura di fine anno. Nei sistemi longevi una quota consistente degli oggetti personalizzati spesso non gira mai. Il codice che nessuno esegue si cancella, non si migra.
2. Fate girare gli strumenti di analisi su ciò che resta. I controlli di SAP trovano i problemi candidati. Non possono dirvi quali contano per l'azienda.
3. Classificate ogni oggetto. Dismetterlo, sostituirlo con funzionalità standard, correggerlo sul posto o ricostruirlo fuori dal core. Una decisione per oggetto, con un responsabile di business nominato.
4. Testate per processo, non per oggetto. Modificare il codice è la parte economica. Dimostrare che order-to-cash e chiusura mensile producono ancora gli stessi numeri è la parte costosa.

I progetti slittano qui per un motivo noioso: nessuno ha contato abbastanza presto. Il volume del codice personalizzato è noto solo a grandi linee, chi l'ha scritto spesso se n'è andato, e i risultati veri arrivano nel secondo ciclo di test, dopo che la data è già stata annunciata internamente.

Interfacce, e PI/PO con lo stesso orologio

ECC raramente vive da solo. IDoc verso il magazzino, chiamate RFC e BAPI dal reparto produttivo, file piatti verso la banca e il consulente fiscale, un portale clienti che legge una vista del database creata da qualcuno nel 2011. Ognuna di queste va trovata, testata e in alcuni casi ricostruita.

Se quelle interfacce passano da SAP Process Integration o Process Orchestration, c'è una seconda scadenza sulle stesse date. L'Architecture Center di SAP dice che PI/PO si avvicina alla «fine della manutenzione standard nel 2027», che i clienti possono estendere la manutenzione fino al 2030 e che dopo l'assistenza SAP termina. SAP indirizza i clienti PI/PO verso SAP Integration Suite, che include una valutazione della migrazione e strumenti di migrazione guidati.

Gli strumenti aiutano con gli oggetti standard. Non vi dicono quali interfacce servono ancora a qualcosa, e la logica di mappatura personalizzata ha comunque bisogno di una persona che la legga. Costruite l'inventario a partire da configurazione del middleware, log e job pianificati, non da un questionario. Poi pianificate insieme lo spostamento dell'ERP e quello del middleware. Fatti uno dopo l'altro, ogni interfaccia viene testata due volte.

Migrazione dei dati

In una conversione di sistema i vostri dati si spostano con il sistema, e con loro la loro qualità. La conversione in business partner è di solito il primo scontro: clienti duplicati, fornitori che sono anche clienti, indirizzi in campi di testo libero, codici fiscali nel posto sbagliato. Tutto questo va ripulito prima della conversione, non durante.

In una nuova implementazione estraete, ripulite, trasformate e caricate, e la parte difficile è la riconciliazione. L'amministrazione dà il via libera quando saldi e partite aperte coincidono, non quando il job di caricamento finisce. Costruite la migrazione come codice ripetibile da far girare una dozzina di volte su dati via via più puliti, confrontando automaticamente i risultati a ogni esecuzione.

In entrambi i percorsi, archiviate prima ciò che non vi serve più. Meno dati significa conversioni più brevi e una finestra di fermo più corta.

Estensioni clean core

La tentazione in un progetto guidato da una scadenza è portarsi dietro ogni modifica e promettere di mettere in ordine dopo. Il dopo non arriva.

Il nome che SAP dà all'alternativa è clean core: lasciare il sistema standard senza modifiche e costruire le estensioni su interfacce che SAP pubblica e mantiene stabili, dentro S/4HANA oppure accanto, sulla SAP Business Technology Platform. Non tutto può essere pulito dal primo giorno. La regola che si riesce davvero a rispettare è più semplice: niente di nuovo si costruisce alla vecchia maniera. Ogni modifica che evitate adesso è una modifica che non dovrete ritestare a ogni futuro aggiornamento.

Uno schema per decidere

Ci sono tre percorsi realistici, e un quarto che riceve meno attenzione.

Avvio su S/4HANA entro il 31 dicembre 2027. Va bene per le aziende che hanno già iniziato, usano un sistema per lo più standard e hanno già ingaggiato un partner. Da oggi sono quindici mesi, e poche amministrazioni accetteranno un passaggio nel pieno della chiusura di fine anno. Se l'analisi del codice personalizzato non è stata fatta, probabilmente non è il vostro percorso.

Pagare la manutenzione estesa e partire entro il 2030. È la direzione in cui va la maggior parte del mercato. Il costo è la maggiorazione di due punti; verificate con SAP come si applica se partite a metà del periodo. Il rischio è trattare il 2030 come è stato trattato il 2027: lontano, finché all'improvviso non lo è più.

Scegliere la private edition transition option fino al 2033. Significa un contratto RISE with SAP, HANA, il vostro sistema spostato su SAP ERP, private edition prima del 31 dicembre 2030, il piano max success e il minimo di 2 TB. Per un'azienda di medie dimensioni raramente è il modo più economico di comprare tempo.

Lasciare SAP. Per alcuni produttori e distributori di medie dimensioni un ERP più piccolo è un'opzione reale. Il lavoro su interfacce e dati non si riduce. Diventa la maggior parte del progetto.

I prossimi sei mesi, qualunque strada scegliate

Da qui alla fine di marzo 2027, tutto questo ripaga su ogni percorso:

1. Verificate il punto di partenza. Enhancement package, database, contratto di manutenzione. Chiedete per iscritto al vostro account team SAP le condizioni di manutenzione estesa che si applicano a voi.
2. Attivate subito la registrazione dell'utilizzo, così copre la chiusura di fine 2026.
3. Eseguite un'analisi del codice personalizzato e uscitene con un conteggio, non con un'impressione: quanti oggetti, quanti in uso, quanti toccano le parti modificate del modello dati.
4. Costruite l'inventario delle interfacce, compreso tutto ciò che passa da PI/PO, con un responsabile e una decisione per ogni interfaccia.
5. Avviate la pulizia delle anagrafiche, partendo da clienti e fornitori.
6. Smettete di aggiungere modifiche. Da oggi i nuovi sviluppi seguono il clean core.
7. Mettete l'aumento di manutenzione del 2028 nel budget 2027 come costo noto e non come sorpresa.
8. Prenotate le risorse: il partner, il vostro team SAP interno e gli sviluppatori che si occupano dei sistemi intorno a SAP. La carenza di competenze è uno dei motivi che i membri della DSAG indicano per i calendari che slittano.

Contando a ritroso da un avvio nel 2030: cicli di test e prove di passaggio nel 2030, sviluppo e correzioni nel 2029, progettazione e pulizia dei dati nel 2028, analisi adesso. C'è meno margine di quanto sembri.

Dove trovare aiuto

Non siamo una società di consulenza funzionale SAP e non eseguiamo conversioni a S/4HANA; lavoriamo accanto al partner che le esegue, sull'inventario e sulla ricostruzione delle interfacce, sul codice di migrazione dei dati e sulla sua riconciliazione, e sulle applicazioni costruite intorno a ECC che devono sopravvivere allo spostamento. Questo lavoro è descritto nella nostra pagina sulla modernizzazione dei gestionali, e la manutenzione dei sistemi legacy copre i sistemi che restano dove sono finché non vi spostate. Se volete che l'ecosistema intorno al vostro ERP venga contato prima di firmare un programma, scrivete a office@c9group.dev.