Migrazione da ECC a S/4HANA: percorsi, fasi e scadenze di SAP ECC

Una migrazione da ECC a S/4HANA porta il Suo sistema SAP ERP da SAP ECC 6.0 a SAP S/4HANA, con un nuovo database, un nuovo modello dei dati finanziari e una nuova interfaccia utente. La decisione che ha davanti è quale percorso seguire, e se riesce ad andare in go-live prima che la manutenzione standard di ECC termini il 31 dicembre 2027.

Risposta breve: greenfield se arriva da altri sistemi o Le servono processi nuovi, brownfield se i Suoi processi sono definiti e funzionano, selective data transition se solo alcune aree vanno riprogettate. Nella mia esperienza il brownfield richiede da 12 a 18 mesi, il greenfield da 18 a 24 mesi e la selective data transition da 12 a 18 mesi. Esegua il SAP Readiness Check prima di impegnarsi su uno qualsiasi di questi.

Passare da ECC a S/4HANA non è un semplice upgrade. Cambia il modo in cui i dati vengono memorizzati, in cui le transazioni vengono registrate e in cui gli utenti lavorano.

In un progetto a cui ho lavorato, un team ha fatto ricostruire decine di report custom esattamente come erano in ECC. Nessuno ha chiesto se servissero ancora. In seguito, la metà non è mai stata usata.

La migrazione era tecnicamente pulita. Il valore no.

SAP ECC sta per SAP ERP Central Component. È il nucleo di SAP ERP 6.0, una delle applicazioni centrali di SAP Business Suite 7, e quando si dice «SAP ECC» si intende quasi sempre ECC 6.0. Gestisce finanza, controlling, acquisti, vendite e produzione su qualsiasi database supportato da SAP, da Oracle a SQL Server e Db2.

Il primo motivo per migrare è la manutenzione. Per SAP ERP 6.0 sugli enhancement package da 6 a 8, la manutenzione standard termina il 31 dicembre 2027. I sistemi sull'enhancement package 5 o inferiore sono usciti dalla manutenzione standard alla fine del 2025 (SAP).

SAP S/4HANA è il successore, e SAP si è impegnata a mantenerlo fino alla fine del 2040.

Il secondo motivo è il tempo. Se avvia oggi, nell'ottobre 2026, una conversione brownfield, il go-live cade tra la fine del 2027 e la primavera del 2028. Se avvia oggi un greenfield, va in go-live nel 2028.

Per la maggior parte dei clienti ECC, quindi, la domanda non è più se migrare. È quale percorso scegliere, e quanta manutenzione estesa mettere a budget nel frattempo.

Tratto questo tema anche in un video sul mio canale YouTube (in inglese).

Queste sono le differenze che generano la maggior parte dell'effort di migrazione:

Area	SAP ECC	SAP S/4HANA
Database	Qualsiasi database supportato (Oracle, Db2, SQL Server, altri)	Solo SAP HANA
Modello dei dati finanziari	Tabelle separate per FI, CO e redditività, con tabelle dei totali	Universal Journal (tabella ACDOCA) come unica fonte a livello di singola partita
Anagrafica clienti e fornitori	Record separati per clienti e fornitori	Il business partner è obbligatorio
Numero materiale	18 caratteri	Fino a 40 caratteri, se attiva la lunghezza estesa
Gestione del credito	Gestione del credito SD	SAP Credit Management (FIN-FSCM)
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 alla fine del 2027, estesa fino alla fine del 2030	Garantita fino alla fine del 2040

SAP registra ciascuna di queste differenze come simplification item e le pubblica nella Simplification List di ogni release di S/4HANA. Alcune sono obbligatorie per tutti i clienti, come il business partner. Altre contano solo se usa la funzione, e il SAP Readiness Check Le indica quali si applicano al Suo sistema.

Un cliente manifatturiero europeo con cui ho lavorato nel 2023 continuava a chiedere 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. Nessuno si era chiesto se quei job avessero ancora senso nel nuovo modello.

La migrazione sposta i dati. La vera domanda è che cosa fa delle scelte di progettazione che eredita.

La mia regola per scegliere è breve. Greenfield quando arriva da altri sistemi o quando vanno definiti processi nuovi. Brownfield quando i Suoi processi sono definiti e funzionano, e selective data transition quando i processi di alcune aree vanno ridefiniti.

Decide

Quale percorso da ECC a S/4HANA si adatta alla Sua situazione?

→Greenfield

Arriva da altri sistemi, o vanno definiti processi nuovi

→Brownfield

I processi sono definiti e funzionano

→Selective data transition

Solo alcune aree devono ridefinire i propri processi

Greenfield: una nuova implementazione

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

È la scelta naturale se oggi una parte della Sua attività gira su sistemi non SAP. Ho visto aziende pentirsi di non aver preparato gli utenti a quanto un sistema greenfield risulti diverso. Se la pianificazione dell'adozione parte dalla formazione, è già tardi.

Brownfield: conversione del sistema

Il brownfield è una conversione del sistema. Il Suo sistema ECC esistente viene convertito sul posto, e configurazione, codice custom e storico vengono con Lei. La conversione tecnica passa dal Software Update Manager (SUM) con la sua Database Migration Option.

SAP pubblica per ogni release una Conversion Guide for SAP S/4HANA, con i prerequisiti e l'ordine dei passi tecnici. Legga quella della Sua release di destinazione prima di pianificare le date. Il rischio è il debito tecnico che si porta dietro, perché la complessità legacy si sposta con Lei a meno che non la ripulisca deliberatamente.

Selective data transition

La selective data transition trasferisce società, business unit o finestre temporali di dati scelte, non tutto. Richiede strumenti specialistici e un partner con esperienza specifica. Alcuni vendor la vendono come «bluefield».

È adatta a gruppi in cui la finanza funziona bene ma gli acquisti vanno riprogettati, o in cui fusioni e carve-out hanno lasciato processi molto diversi uno accanto all'altro. Riprogetta le aree che ne hanno bisogno e conserva lo storico dove conta.

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

Percorso	Quando sceglierlo	Tempi tipici	Rischio principale
Greenfield	Arriva da altri sistemi, o vanno definiti processi nuovi	Da 18 a 24 mesi	Carico di cambiamento sugli utenti, e storico lasciato indietro
Brownfield	I processi sono definiti e funzionano	Da 12 a 18 mesi	Debito tecnico e codice custom inutilizzato portati avanti
Selective data transition	I processi di alcune aree vanno ridefiniti	Da 12 a 18 mesi	Dipendenza da strumenti e partner specialistici, e perimetro dei dati complesso

Il percorso cambia i dettagli, ma la sequenza resta la stessa. Queste sono le cinque fasi che pianificherei, in ordine.

La sequenza della migrazione

1. 01

   Readiness check

   Esegua il SAP Readiness Check e confermi i prerequisiti tecnici.

2. 02

   Scegliere e pianificare

   Scelga il percorso, definisca il perimetro e pianifichi l'intero programma prima che inizi la realizzazione.

3. 03

   Codice custom

   Individui ciò che si usa, dismetta il resto, adatti ciò che rimane.

4. 04

   Dati

   Classifichi, pulisca e archivi prima di spostare qualsiasi cosa.

5. 05

   Test e cutover

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

1. Eseguire il readiness check

Si parte da qui. Sempre. Il SAP Readiness Check analizza il Suo sistema ECC e riporta simplification item, compatibilità degli add-on, codice custom, volumi di dati e sizing.

Le sorprese di solito sono gli add-on e il codice custom. Alcuni clienti con cui ho lavorato avevano centinaia di oggetti custom nel perimetro. Meglio scoprirlo alla seconda settimana che al dodicesimo mese.

Per una conversione brownfield, verifichi contemporaneamente questi prerequisiti:

1. Release: la conversione funziona a partire da SAP ERP 6.0 su qualsiasi enhancement package.
2. Unicode: il sistema deve essere Unicode, altrimenti va pianificata una conversione in due passi.
3. Dual-stack: i sistemi dual-stack vanno prima separati.
4. Business partner: le anagrafiche clienti e fornitori devono essere convertite in business partner prima della conversione. È il punto che mette in difficoltà più team di qualsiasi altro.

2. Scegliere il percorso e pianificare il programma

Usi i risultati del readiness check e la mia regola qui sopra per scegliere il percorso. Poi pianifichi l'intero programma, inclusi dati, test e cutover, prima che chiunque inizi a realizzare.

Nei 21 programmi SAP che ho guidato o salvato, l'errore di migrazione più grande che vedo è non pianificarla bene all'inizio dell'implementazione. Decida nelle prime settimane chi è responsabile della pulizia dei dati, quale codice custom viene dismesso e quando si svolgono le prove generali del cutover. Sono decisioni costose da prendere tardi.

3. Adattare il codice custom

Esegua i controlli S/4HANA nell'ABAP Test Cockpit, che confrontano il Suo codice con i simplification item di SAP. L'app Custom Code Migration mostra gli stessi risultati con i dati di utilizzo, così vede cosa si usa prima di correggere qualsiasi cosa.

L'obiettivo è avere meno codice Z, non solo codice Z che funziona. In un programma, l'analisi con smartShift ci ha portato da 18.000 oggetti custom a 3.200.

Ogni oggetto custom che si porta dietro aggiunge costi a ogni upgrade futuro. Ho visto aziende ridurre del 40% i tempi di upgrade con i principi del Clean Core, e la mia guida a SAP Clean Core spiega come classificare ciò che rimane.

4. Preparare e trasferire i dati

Classifichi, pulisca e archivi prima di spostare qualsiasi cosa. Questa fase richiede più tempo di quanto preveda qualunque piano, per questo ha una sezione dedicata più sotto.

5. Test, formazione e cutover

Esegua i test a cicli: unit test, test di integrazione e user acceptance test (UAT), poi almeno una prova generale completa del cutover. Coinvolga negli UAT sia i key user sia gli utenti occasionali, perché trovano problemi diversi.

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

Nella mia esperienza la migrazione dei dati assorbe dal 30 al 40% dell'effort di implementazione. È anche il motivo più comune per cui i piani slittano.

Il modo in cui i dati vengono trasferiti dipende dal percorso. Nel brownfield, SUM converte i dati sul posto. Nel greenfield, carica i dati anagrafici e le partite aperte con il SAP S/4HANA Migration Cockpit, e nella selective data transition sono gli strumenti specialistici a trasferire il perimetro scelto.

Qualunque sia il percorso, classifichi i dati prima di spostarli:

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

I dati freddi non devono per forza andare in S/4HANA. Li archivi. Record fornitori duplicati, unità di misura incoerenti e anagrafiche clienti compilate a metà esistono in ogni sistema ECC, e passano intatti in S/4HANA se nessuno li sistema prima.

Un cliente con cui ho lavorato ha dedicato cinque mesi soltanto alla pulizia e all'archiviazione dei dati. Il mio articolo sul perché la migrazione dei dati SAP fallisce approfondisce questa fase.

Questi sono i cinque strumenti che ho usato nei programmi da ECC a S/4HANA. Due sono di SAP e tre vengono da vendor specializzati:

Strumento	Chi lo produce	Cosa fa	Dove si colloca
SAP Readiness Check for SAP S/4HANA	SAP	Riporta simplification item, compatibilità degli add-on, impatto sul codice custom, volumi di dati e sizing	Prima di scegliere il percorso
App Custom Code Migration	SAP	App SAP Fiori che esegue i controlli S/4HANA dell'ABAP Test Cockpit e usa i dati di utilizzo per trovare il codice inutilizzato; gira in S/4HANA o nell'ambiente ABAP di SAP BTP	Perimetrazione e adattamento del codice custom
smartShift	smartShift Technologies	Analisi e trasformazione automatizzate del codice ABAP custom per S/4HANA	Analisi e correzione del codice custom
SNP (piattaforma Kyano)	SNP Group	Software di trasformazione dei dati per la selective data transition, venduto con l'approccio «Bluefield» di SNP	Selective data transition, fusioni e carve-out
Natuvion	Natuvion Group	Software di conversione dei dati e strumenti di cutover per le transizioni a S/4HANA	Selective data transition e cutover

SNP e Natuvion sono entrambi membri fondatori della Selective Data Transition Engagement community di SAP. Gli altri strumenti SAP che incontrerà sono SUM per la conversione brownfield e il Migration Cockpit per i caricamenti di dati greenfield.

Uno strumento non sostituisce le decisioni. Qualcuno dalla Sua parte deve comunque concordare cosa dismettere.

Per SAP ERP 6.0 sugli enhancement package da 6 a 8, la manutenzione standard termina il 31 dicembre 2027. La manutenzione estesa opzionale va dal 2028 al 31 dicembre 2030, con una maggiorazione di due punti percentuali sulla Sua base di manutenzione attuale (SAP News).

Oltre il 2030 c'è una strada stretta, la SAP ERP, private edition, transition option. Offre manutenzione dal 2031 al 2033 ai clienti che trasferiscono il proprio sistema ECC nel cloud privato di SAP come SAP ERP, private edition, su SAP HANA, nell'ambito di RISE with SAP. Il sistema deve essere trasferito prima del 31 dicembre 2030, deve essere di almeno 2 TB e richiede il max success plan di SAP.

Il 2033 quindi non è una scadenza generale. Vale per sistemi di grandi dimensioni che hanno già portato ECC nel cloud di SAP. Per tutti gli altri, ECC sulla propria infrastruttura ha il 2027 come data della manutenzione standard e il 2030 come fine della manutenzione estesa.

1. 2027Fine della manutenzione standard di ECC31 dicembre, per SAP ERP 6.0 EHP da 6 a 8
2. 2028Go-live probabile se inizia adessoBrownfield da 12 a 18 mesi, greenfield da 18 a 24
3. 2030Fine della manutenzione estesaOpzionale, con due punti di maggiorazione
4. 2033Fine della transition optionSolo SAP ERP, private edition, sistemi da 2 TB in su

Fonte: SAP News, febbraio 2020 e agosto 2025

Il conto è semplice. Metta a budget almeno un po' di manutenzione estesa, e usi il tempo per pulire i dati e dismettere codice custom invece che per aspettare.

Il costo segue gli stessi fattori dei tempi: il percorso, il volume di codice custom, lo stato dei Suoi dati e quante società vanno in go-live. I soli dati assorbono dal 30 al 40% dell'effort, ed è per questo che un buon piano dei dati fa risparmiare più di qualsiasi negoziazione sulle tariffe. La mia guida ai costi della migrazione a S/4HANA spiega cosa determina il budget di una migrazione, e la mia guida ai costi di implementazione SAP scompone il budget per dimensione aziendale.

Per vedere come è andato un programma, legga il mio caso di studio sulla migrazione da ECC a S/4HANA. Per valutare le Sue opzioni, provi la valutazione della migrazione greenfield o brownfield.

Questo articolo è la panoramica. Ciascuna guida qui sotto risponde per intero a una domanda.

1. Tempi e piano di progetto della migrazione a S/4HANA: fase per fase, per percorso, con mock conversion e cutover.
2. Costi della migrazione a S/4HANA: cosa determina il budget di una conversione, di una nuova implementazione o di una transizione selettiva.
3. SAP Readiness Check e assessment della migrazione: cosa Le dice il check e cosa non vede.
4. SAP S/4HANA Migration Cockpit, passo per passo: caricare i dati con staging table o trasferimento diretto.
5. RISE with SAP: public o private cloud: quale edizione si adatta ai Suoi processi.
6. Contratto e prezzi di RISE with SAP: cosa copre l'abbonamento e cosa negoziare.
7. Come scegliere un partner per la migrazione a S/4HANA: le domande da porre e i segnali d'allarme.
8. Recupero di progetti SAP: come salvare una migrazione fuori rotta.

Due strumenti aiutano con i numeri: il calcolatore dei costi di implementazione SAP e lo stimatore della migrazione dei dati.

Che cos'è SAP ECC?

SAP ECC (SAP ERP Central Component) è il nucleo di SAP ERP 6.0, parte di SAP Business Suite 7. Copre finanza, controlling, logistica e altri processi centrali e gira su diversi database. SAP S/4HANA è il suo successore e gira solo su SAP HANA.

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

Nella mia esperienza una conversione brownfield richiede da 12 a 18 mesi, un'implementazione greenfield da 18 a 24 mesi e una selective data transition da 12 a 18 mesi. La pulizia dei dati è il motivo più comune per cui i piani slittano, perché la migrazione dei dati assorbe dal 30 al 40% dell'effort di implementazione.

Cosa succede a SAP ECC dopo il 2027?

Per SAP ERP 6.0 sugli enhancement package da 6 a 8, la manutenzione standard termina il 31 dicembre 2027. Può acquistare la manutenzione estesa opzionale fino al 31 dicembre 2030 a fronte di due punti percentuali in più. Dal 2031 al 2033 la manutenzione è disponibile solo tramite la SAP ERP, private edition, transition option, per sistemi di grandi dimensioni trasferiti nel cloud privato di SAP prima della fine del 2030.

Brownfield o greenfield: quale è meglio?

Nessuno dei due è migliore in assoluto. Scelga il greenfield quando arriva da altri sistemi o vanno definiti processi nuovi, e il brownfield quando i Suoi processi sono definiti e funzionano. Se solo alcune aree vanno riprogettate, valuti la selective data transition.

Che cos'è la selective data transition in SAP?

La selective data transition trasferisce in S/4HANA società, business unit o finestre temporali di dati scelte, invece di convertire tutto o partire da zero. Le consente di riprogettare alcune aree mantenendo lo storico in altre. Richiede strumenti specialistici, come quelli di SNP o Natuvion, e un partner esperto.

Quali sono i prerequisiti per convertire ECC 6.0 a S/4HANA?

La conversione funziona a partire da SAP ERP 6.0 su qualsiasi enhancement package. Il sistema deve essere Unicode, altrimenti si usa un approccio in due passi, e i sistemi dual-stack vanno prima separati. Le anagrafiche clienti e fornitori devono essere convertite in business partner prima della conversione.

Cosa Le dice il SAP Readiness Check?

Analizza il Suo sistema ECC e riporta i simplification item che La riguardano, la compatibilità degli add-on, l'impatto sul codice custom, i volumi di dati e il sizing HANA. Lo esegua presto, perché i team scoprono regolarmente add-on e codice custom da cui non sapevano di dipendere.

Per una migrazione ECC è meglio scegliere 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 nell'ambito di RISE with SAP, che supporta la conversione del sistema esistente. GROW with SAP usa la Public Edition, cioè una nuova implementazione con processi standard ed estensioni solo tramite API rilasciate. È adatta alle aziende disposte ad adottare lo standard SAP.