Il sistema che smette di ricevere correzioni
Un ERP fuori manutenzione continua a funzionare. Il problema arriva dopo: le correzioni di sicurezza smettono di uscire per quella versione, un tema che si lega agli obblighi di sicurezza, le segnalazioni non hanno più una risposta ufficiale, e i fornitori delle integrazioni certificano i loro prodotti sulle release supportate.
Chi rimanda l’aggiornamento non risparmia il lavoro: lo accumula. Saltare più versioni di seguito rende il passaggio successivo più lungo, perché le modifiche da verificare si sommano e il collaudo diventa un progetto invece di un’attività programmata.
Ogni quanto esce una nuova versione?
Il cambio di ritmo sposta il modo di pianificare. Con release annuali e cinque anni di copertura l’aggiornamento era un appuntamento ricorrente ravvicinato; con il ciclo attuale si può scegliere se seguire ogni versione o saltarne una, sapendo che la copertura arriva comunque più lontano.
Resta il vincolo di fondo, che vale per chi è ancora sul sistema precedente: la manutenzione mainstream di SAP ERP 6.0 con enhancement package 6, 7 e 8 si chiude il 31 dicembre 2027, con manutenzione estesa fino a fine 2030 e un incremento del 2% sul canone. Le tre strade per arrivarci sono nel report scaricabile «Migrare a S/4 HANA senza impatti sul business».

Che cosa comprende un progetto di upgrade?
| Ambito | Che cosa comporta | Chi lo fa |
|---|---|---|
| Software e database | Aggiornamento della release applicativa e della versione del database, sugli ambienti di prova e poi in produzione. | Team tecnico, con una finestra concordata. |
| Codice su misura | Verifica e adattamento degli sviluppi personalizzati che toccano oggetti cambiati nella nuova release. | Chi mantiene gli sviluppi, sulla base dell’analisi preliminare. |
| Collaudo dei processi | Riesecuzione dei processi aziendali critici sull’ambiente aggiornato, prima di andare in produzione. | Le persone che quei processi li usano ogni giorno. |
| Integrazioni | Controllo dei flussi verso banche, portali, applicativi esterni e strumenti di stampa. | Team di progetto insieme ai fornitori terzi. |
Sulla terza riga le aziende sbagliano le stime più spesso. Il collaudo non lo può fare chi installa: serve chi conosce il processo e sa riconoscere un risultato sbagliato. Sono le stesse persone che nel frattempo mandano avanti il lavoro ordinario, ed è il vincolo che detta il calendario più di qualsiasi considerazione tecnica.
Che cosa si guadagna aggiornando?
La risposta onesta dipende dalla distanza fra la versione in uso e quella di arrivo. Chi salta più release trova funzioni nuove in tutte le aree e un’interfaccia SAP Fiori rinnovata; chi aggiorna a ogni ciclo trova miglioramenti incrementali e la copertura di manutenzione che si sposta in avanti.
Le novità degli ultimi cicli si concentrano sull’automazione delle attività ripetitive e sull’assistenza dentro le applicazioni. Vale la pena valutarle sui processi reali dell’azienda invece che sull’elenco delle funzionalità: molte richiedono dati puliti e processi vicini allo standard per dare qualcosa, e su un sistema molto personalizzato restano inutilizzate.
Quando rimandare è la scelta giusta
Se l’azienda ha appena chiuso un progetto importante, o sta per affrontare il picco stagionale, o ha le persone chiave impegnate altrove, l’aggiornamento si sposta. Un collaudo fatto di corsa da chi non ha tempo produce un avvio con problemi che costano più dell’attesa.
Va però deciso con una data, non lasciato aperto. La differenza fra rimandare e trascurare sta nell’avere una finestra scritta in calendario: senza quella, il rinvio si ripete finché la release non è più supportata e la scelta la fa il calendario di SAP. Il presidio del sistema fra un aggiornamento e l’altro è il tema dei servizi di manutenzione applicativa.
Domande frequenti sull’upgrade di SAP S/4HANA
Quanto dura un progetto di aggiornamento?
La parte tecnica si misura in giorni; il progetto si misura sul collaudo. La durata dipende da quanti processi vanno riprovati, da quanti sviluppi su misura sono coinvolti e da quante finestre di fermo l’azienda può concedere. Saltare più release allunga la fase di verifica, non l’installazione.
Serve fermare il sistema?
Sì, per una finestra concordata, che si colloca fuori dalle attività critiche — tipicamente in un fine settimana lontano dalle chiusure. La durata del fermo si stima sugli ambienti di prova, dove l’aggiornamento viene eseguito prima per misurarlo.
Che cosa succede agli sviluppi personalizzati?
Quelli che usano oggetti modificati nella nuova release vanno adattati. L’elenco si ottiene con un’analisi preliminare sul sistema in esercizio, prima di impegnare il budget: è il numero che più di ogni altro determina l’effort del progetto.
Conviene aggiornare o passare al cloud?
Sono due decisioni diverse che spesso si affrontano insieme, e si incrociano con le metodologie di conversion. L’aggiornamento mantiene l’impianto attuale e ne sposta la scadenza; il passaggio a un ambiente gestito cambia anche il modello di esercizio e di costo. Chi ha davanti entrambe le scelte valuta prima quanto della configurazione attuale vuole conservare.
Come si sa su quale release si è?
Il dato è leggibile dal sistema e va confrontato con il calendario di manutenzione della propria versione, non con quello generale. È la prima informazione da raccogliere: da lì si capisce se la finestra utile è di anni o di mesi.
Parliamo del vostro sistema
Software Business affianca le aziende del mid-market italiano negli aggiornamenti dei sistemi SAP, dall’analisi preliminare al collaudo con gli utenti. Se volete sapere a che punto siete e quanto costerebbe rimettervi in pari, scrivici.
Le tre metodologie di migrazione a confronto, i tre numeri che decidono quale conviene, la lista di controllo del Readiness Check e le date di fine manutenzione.
