Migrazione da ECC a S/4HANA: percorsi, fasi e tempi

La manutenzione standard di SAP ECC termina il 31 dicembre 2027, tra circa 15 mesi. La manutenzione estesa opzionale arriva fino alla fine del 2030, a un canone più alto (SAP News). Le migrazioni complesse possono arrivare facilmente a 18-24 mesi, una volta che i test veri iniziano. Se non ha ancora scelto un percorso, andare in produzione prima della scadenza è già improbabile.

Se è il CIO o il responsabile di programma che deve prendere questa decisione, ha tre percorsi: greenfield, brownfield o selective data transition. Il lavoro dietro ciascuno segue le stesse cinque fasi. Prima esegua lo SAP Readiness Check, poi scelga.

Passare da ECC a S/4HANA non è un semplice aggiornamento. Cambia il modo in cui i dati vengono memorizzati, il modo in cui le transazioni vengono registrate e il modo in cui lavorano gli utenti. In un progetto a cui ho lavorato, un team aveva fatto ricostruire decine di report custom esattamente com'erano in ECC. Nessuno si era chiesto se servissero ancora. Più tardi, metà non è mai stata usata. La migrazione era tecnicamente pulita. Il valore no.

Le differenze che determinano lo sforzo di migrazione:

Area	SAP ECC	SAP S/4HANA
Database	Qualsiasi database supportato (Oracle, Db2, SQL Server, altri)	Solo SAP HANA
Modello dati della finanza	Tabelle separate per FI, CO e redditività, con tabelle dei totali	Universal Journal (tabella ACDOCA) come unica fonte delle registrazioni di dettaglio
Dati anagrafici di clienti e fornitori	Record separati per clienti e fornitori	Il business partner è obbligatorio
Interfaccia utente	SAP GUI	App SAP Fiori, con SAP GUI ancora disponibile on-premise e in Private Edition
Deployment	On-premise	On-premise, Private Edition (RISE with SAP) o Public Edition (GROW with SAP)
Estensioni	Programmi Z e modifiche	Clean core: API rilasciate, ABAP Cloud on-stack o side-by-side su SAP BTP
Manutenzione	EHP da 6 a 8: standard fino a fine 2027, estesa fino a fine 2030	SAP si è impegnata a garantire la manutenzione fino alla fine del 2040

Un cliente con cui ho lavorato continuava a chiedersi perché i suoi batch job custom non funzionassero più dopo la conversione. La logica si basava su strutture di tabelle ECC che S/4HANA aveva cambiato. La migrazione in sé era completa. Nessuno si era chiesto se quei job avessero ancora senso nel nuovo modello.

La migrazione sposta i dati. La vera domanda è che cosa farsene delle decisioni di progetto che si ereditano.

Decide

Quale percorso di migrazione fa al caso suo?

Il legacy è frammentato e vuole ridisegnare i processi

→Greenfield

I processi sono solidi, ECC è stabile, lo storico deve restare

→Brownfield

Più entità, vuole un riutilizzo parziale e dati selettivi

→Bluefield

Greenfield: ripartire da zero

Una nuova implementazione di S/4HANA. Nessuna configurazione legacy viene portata avanti, i processi vengono ridisegnati sullo standard SAP e si caricano solo i dati che servono, con lo SAP S/4HANA Migration Cockpit.

Da scegliere quando i sistemi legacy sono troppo frammentati per essere convertiti in modo pulito, oppure l'azienda vuole ripensare i processi invece di copiarli.

Da tenere d'occhio: il carico di cambiamento. Gli utenti perdono i flussi di lavoro che conoscono. Ho visto aziende pentirsi di non aver preparato i propri utenti a quanto un sistema greenfield sia diverso. Se la pianificazione dell'adozione parte con la formazione, è già in ritardo.

Brownfield: conversione del sistema

Il suo sistema ECC esistente viene convertito sul posto. Configurazione, codice custom e storico restano con il sistema. La conversione tecnica passa dal Software Update Manager (SUM), con la sua opzione di migrazione del database.

Da scegliere quando i processi sono maturi, lo storico delle transazioni conta ai fini della compliance e non è in corso nessuna ristrutturazione importante.

Da tenere d'occhio: il debito tecnico che si trascina. La complessità del legacy si trasferisce insieme al sistema, a meno che non la si ripulisca in modo deliberato durante la conversione.

Selective data transition

A volte venduta come «bluefield». Si spostano company code, business unit o intervalli temporali di dati scelti, non tutto, di solito con strumenti specialistici e un partner esperto. Si adatta ai gruppi nati da fusioni o carve-out, o dove anni di storico non contano più.

Da scegliere quando vuole la libertà sui processi tipica del greenfield con la continuità dei dati tipica del brownfield, dove conta.

Ecco come si confrontano i tre percorsi sulle domande che i consigli di amministrazione fanno di solito:

Criteri	Greenfield	Brownfield	Selective
Ridisegno dei processi	Completo, sullo standard SAP	In gran parte mantenuti	Scelto per singola unità
Dati storici	Non portati avanti (o solo partite aperte e saldi)	Portati avanti per intero	Perimetro selezionato
Tempo al go-live	Più lungo	Più breve	Dipende dal perimetro
Debito tecnico	Eliminato	Portato avanti	Ridotto per il perimetro migrato
Impatto del cambiamento	Alto	Più basso	Moderato
Ideale per	Legacy frammentato, grande ridisegno	ECC stabile e ben tenuto	Fusioni, carve-out, rilasci a fasi

La sequenza della migrazione

1. 01

   Valutazione

   Esegua lo SAP Readiness Check. Faccia l'inventario di codice custom, add-on e interfacce.

2. 02

   Classificazione dei dati

   Segmenti i dati in hot, warm e cold. I dati cold non devono per forza migrare.

3. 03

   Pulizia

   Risolva duplicati, incoerenze e campi mancanti. Richiede sempre più tempo del previsto.

4. 04

   Adattamento del codice

   Esegua i controlli dell'ABAP Test Cockpit. Riduca il codice Z, non si limiti a portarlo.

5. 05

   Test e cutover

   Più cicli di test e almeno una prova generale completa di cutover.

1. Valutazione e readiness

Parta da qui. Sempre. Lo SAP Readiness Check analizza il suo sistema ECC e riporta simplification item, compatibilità degli add-on, codice custom, volumi di dati e dimensionamento.

Le sorprese sono di solito gli add-on e il codice custom. Alcuni clienti con cui ho lavorato avevano centinaia di oggetti custom nel perimetro, e la maggior parte si stupisce di quanto codice inattivo salti fuori. Meglio scoprirlo alla seconda settimana che al dodicesimo mese.

Verifichi nello stesso momento i prerequisiti tecnici. La conversione parte da SAP ERP 6.0 con qualsiasi enhancement package. Il sistema deve essere Unicode, altrimenti si pianifica una conversione in due passaggi. I sistemi dual-stack vanno prima separati. Le anagrafiche di clienti e fornitori devono essere convertite in business partner prima della conversione. Quest'ultimo punto fa inciampare più team di qualsiasi altro.

2. Analisi e classificazione dei dati

Misuri i dati prima di spostarli, e li classifichi:

1. Hot: usati spesso, necessari per l'operatività corrente.
2. Warm: accesso occasionale, rilevanti ma non quotidiani.
3. Cold: storici o inutilizzati, conservati solo per l'audit.

I dati cold non devono entrare in S/4HANA. Li archivi. I team che saltano questo passaggio portano nel nuovo sistema una zavorra che rallenta sia la migrazione sia le prestazioni.

3. Pulizia e archiviazione dei dati

Questa fase richiede più tempo di quanto qualsiasi piano preveda. Anagrafiche fornitori duplicate. Unità di misura incoerenti. Anagrafiche clienti compilate a metà. Questi problemi esistono in ogni sistema ECC e passano in S/4HANA intatti se nessuno li corregge prima.

Un cliente con cui ho lavorato ha speso cinque mesi solo per la pulizia e l'archiviazione dei dati. I team che saltano la pulizia scoprono i problemi durante il cutover, quando non c'è più tempo per risolverli come si deve. Il mio articolo su perché la migrazione dei dati SAP fallisce approfondisce questa fase.

4. Adattamento del codice custom

Esegua i controlli di readiness S/4HANA dell'ABAP Test Cockpit (ATC), che confrontano il suo codice con i simplification item di SAP. L'output mostra che cosa richiede una correzione di sintassi, che cosa una sostituzione funzionale e che cosa va dismesso.

L'obiettivo è meno codice Z, non solo codice Z che funziona. Ogni oggetto custom che porta con sé aggiunge costi a ogni futuro aggiornamento. La mia guida al clean core spiega come classificare ciò che resta.

5. Test, formazione e cutover

Esegua i test a cicli: unit test, test di integrazione, user acceptance test (UAT), poi almeno una prova generale completa di cutover. Nei UAT coinvolga sia i power user sia gli utenti occasionali. Trovano problemi diversi.

La prova generale non è facoltativa. Fa emergere buchi nei tempi, validazioni mancanti e guasti delle interfacce che compaiono solo quando l'intera sequenza gira. I team che la saltano incontrano questi problemi nel weekend del go-live.

Gli strumenti SAP che mi aspetto di trovare in qualsiasi piano di migrazione:

Strumento	Che cosa fa	Quando usarlo
SAP Readiness Check	Simplification item, add-on, codice custom, dimensionamento	Prima di scegliere il percorso
ABAP Test Cockpit (ATC)	Individua il codice custom che si romperà	Adattamento del codice custom
SAP Signavio	Mostra come i processi girano davvero, non come erano stati documentati	Prima del design freeze
SAP LeanIX	Mappa applicazioni e interfacce	Progettazione dell'integrazione
Software Update Manager (SUM)	Esegue la conversione tecnica	Conversione brownfield
SAP S/4HANA Migration Cockpit	Carica dati anagrafici e transazionali	Migrazione dei dati nel greenfield

Per SAP ERP 6.0 con enhancement package da 6 a 8, la manutenzione standard termina il 31 dicembre 2027. La manutenzione estesa opzionale arriva al 31 dicembre 2030, con un sovrapprezzo di due punti percentuali sulla base di manutenzione. I pacchetti di miglioramento precedenti sono usciti dalla manutenzione standard a fine 2025.

Oltre il 2030 esiste una sola via stretta. L'opzione di transizione di SAP per SAP ERP, private edition copre il periodo dal 2031 al 2033. Vale solo per i grandi sistemi spostati su SAP ERP, private edition su SAP HANA prima della fine del 2030, e solo con il piano max success di SAP. La consideri un'eccezione, non un piano.

Quanto alla durata, le migrazioni complete di sistemi complessi possono arrivare a 18-24 mesi o più, una volta che i test veri iniziano. Per le aziende medio-grandi, 12-18 mesi o più è un tempo realistico per una conversione ben preparata. Un grande programma greenfield su più entità può durare da 24 a 36 mesi.

1. 2027Fine della manutenzione standard di ECC31 dicembre, per SAP ERP 6.0 EHP da 6 a 8
2. 2028Go-live probabile se parte oggiDa 18 a 24 mesi una volta iniziati i test veri
3. 2030Fine della manutenzione estesaOpzionale, con sovrapprezzo di due punti
4. 2033Fine dell'opzione di transizionePrivate edition, solo grandi sistemi

Fonte: SAP News, febbraio 2020 e agosto 2025

Quindi l'aritmetica è semplice. Se avvia oggi una valutazione complessa, il go-live cade nel 2028. Preventivi la manutenzione estesa e usi il tempo per ripulire i dati e dismettere il codice custom, invece di aspettare. Per mettere alla prova le sue opzioni, provi la mia valutazione della migrazione.

Qual è la differenza tra migrazione greenfield e brownfield da ECC a S/4HANA?

Il greenfield è una nuova implementazione: nessuna configurazione legacy né codice custom viene portato avanti, i processi sono progettati sullo standard SAP e si caricano solo i dati che servono. Il brownfield converte il sistema ECC esistente, mantenendo configurazione, codice custom e storico. È più rapido e meno dirompente, ma il debito tecnico resta. La selective data transition sta a metà tra i due.

Qual è la scadenza per la migrazione da SAP ECC a S/4HANA?

Per SAP ERP 6.0 con enhancement package da 6 a 8, la manutenzione standard termina il 31 dicembre 2027. La manutenzione estesa opzionale arriva al 31 dicembre 2030, con un sovrapprezzo di due punti percentuali sulla base di manutenzione. Un'opzione di transizione per il periodo dal 2031 al 2033 esiste solo per i grandi sistemi spostati su SAP ERP, private edition su SAP HANA prima della fine del 2030.

Che cosa ci dice lo SAP Readiness Check?

Analizza il sistema ECC e riporta i simplification item che incidono sulla configurazione, la compatibilità degli add-on, l'impatto sul codice custom, i volumi di dati e il dimensionamento HANA. Eseguirlo presto cambia la discussione sul perimetro, perché i team scoprono regolarmente add-on e codice custom da cui non sapevano di dipendere.

Quanto dura una migrazione da ECC a S/4HANA?

Una conversione ben preparata per un'azienda medio-grande richiede spesso da 12 a 18 mesi o più. I programmi complessi su più entità possono arrivare a 18-24 mesi una volta iniziati i test veri, e i grandi programmi greenfield a 24-36 mesi. La pulizia dei dati è il motivo più frequente dei ritardi.

Che cos'è l'Universal Journal (ACDOCA) e perché conta per la migrazione?

L'Universal Journal è l'unica tabella delle registrazioni di dettaglio, ACDOCA, che riunisce i dati di contabilità finanziaria, controlling e redditività che ECC teneva in tabelle separate. Il codice custom e i report che leggono le vecchie strutture, come COEP o le tabelle della redditività, vanno rivisti. Alcuni richiedono piccoli adattamenti; altri una riprogettazione.

Quali sono i prerequisiti tecnici per convertire ECC in S/4HANA?

La conversione parte da SAP ERP 6.0 con qualsiasi enhancement package. Il sistema deve essere Unicode, oppure si usa un approccio in due passaggi. I sistemi dual-stack devono essere separati prima. Le anagrafiche di clienti e fornitori devono essere convertite in business partner. Esegua lo SAP Readiness Check e i controlli ATC sul codice custom prima di impegnarsi su delle date.

Per una migrazione da ECC conviene RISE with SAP o GROW with SAP?

La maggior parte dei clienti ECC con molto codice custom e processi complessi passa a S/4HANA Cloud Private Edition con RISE with SAP, che supporta la conversione del sistema esistente. GROW with SAP usa la Public Edition, che è una nuova implementazione con processi standard ed estensioni solo tramite API rilasciate. Si adatta alle aziende disposte ad adottare lo standard SAP.