L'inventario dei vostri sistemi legacy si fa con una pagina per sistema che risponde a 7 domande: responsabile, utenti, dati e se includono dati personali, collegamenti, cosa si ferma se si ferma, date di rinnovo delle licenze, e la tecnologia con la fine del suo supporto. Poi assegnate a ogni sistema una di 5 decisioni: mantenere, dismettere, sostituire con un prodotto pronto, spostare così com'è nel cloud o ricostruire, una versione semplificata delle 7 strategie della guida ufficiale alla migrazione di Amazon. L'IA accelera la metà tecnica, ma non può dirvi chi è il responsabile di un sistema.

Nella parte 2 avete dato a ogni sistema un punteggio su 8. Il punteggio mostra il rischio; l'inventario vi dà ciò che serve per decidere.

Cosa va nella pagina di ogni sistema

Per iniziare non serve un software speciale. Basta una tabella semplice, purché risponda a queste domande per ogni sistema:

  • Responsabile: una persona con nome e cognome che decide sul sistema dal lato del business, non il reparto IT. Se non trovate nessuno, questo è il primo risultato del vostro inventario.
  • Utenti: quali reparti lo usano, quante persone circa e se lo usano anche clienti o fornitori esterni all'azienda.
  • Dati: cosa conserva, se include dati personali di clienti o dipendenti e dove si trovano davvero: un server in ufficio o un cloud, e in quale paese.
  • Collegamenti: da dove arrivano i suoi dati e dove vanno: fatturazione, banca, negozio online, paghe, un file Excel esportato ogni settimana.
  • Impatto di un fermo: cosa succede se si ferma per un giorno intero: si bloccano le vendite, slittano gli stipendi o nessuno se ne accorge?
  • Licenze e contratti: chi pagate, quando si rinnova il contratto e se c'è un termine di preavviso prima del rinnovo. La data di rinnovo spesso stabilisce quando la vostra decisione deve essere pronta.
  • Tecnologia e supporto: il linguaggio di programmazione, il database e il sistema operativo, e quando termina il supporto di ciascuno, come visto nella parte 2.

Se l'inventario mostra che alcuni dei vostri veri sistemi sono fogli di calcolo da cui dipende il lavoro quotidiano, abbiamo spiegato come censirli in quale foglio è il sistema.

La questione dei dati: non saltatela

La colonna dei dati personali conta più di ogni altra, perché cambia la decisione. Un sistema che conserva nomi e numeri di telefono dei clienti o fascicoli dei dipendenti è soggetto alla Legge sulla protezione dei dati personali (PDPL), vigilata dall'Autorità saudita per i dati e l'intelligenza artificiale (SDAIA), e trasferire o trattare quei dati fuori dal Regno durante la modernizzazione richiede una verifica prima di iniziare. Abbiamo spiegato gli obblighi pratici nella nostra guida alla PDPL per le aziende.

Questo riguarda anche gli strumenti di modernizzazione stessi. Per esempio, la pagina ufficiale delle Regioni di AWS Transform elenca 9 Regioni in cui creare spazi di lavoro, nessuna in Medio Oriente, e avverte che i dati possono essere elaborati in una Regione diversa da quella da cui lavorate. Secondo la Saudi Press Agency del 1 settembre 2026, Amazon ha annunciato che la sua prima Regione cloud nel Regno è sulla buona strada per il lancio a dicembre 2026. Annotate quindi dove si trovano oggi i dati di ogni sistema, così saprete quali strumenti possono leggerli senza problemi.

Come l'IA accelera l'inventario, e cosa non può sapere

La metà tecnica di un inventario richiedeva settimane di controlli sui server e di lettura del codice a mano. Gli strumenti di oggi leggono server e codice e mappano automaticamente i collegamenti tra loro. Un esempio tra tanti: Amazon afferma nella pagina di AWS Transform che i suoi agenti automatizzano la migrazione dalla scoperta e dalla pianificazione a ondate fino al passaggio finale, e che la sua valutazione dei mainframe riduce mesi di scoperta a poche ore. È un'affermazione di Amazon, non un risultato garantito. La sua pagina dei prezzi elenca oggi la valutazione tra gli agenti gratuiti.

La guida alla migrazione di Amazon offre anche segnali pratici per individuare i sistemi da dismettere, usando i dati dello strumento di scoperta stesso:

  • Un sistema con un uso medio di CPU e memoria inferiore al 5 per cento è ciò che la guida chiama un'applicazione zombie.
  • Un sistema che usa tra il 5 e il 20 per cento nell'arco di 90 giorni è ciò che chiama un'applicazione inattiva.
  • Un sistema senza alcuna connessione in entrata negli ultimi 90 giorni è candidato alla dismissione.

Ma lo strumento non sa chi è il responsabile del sistema, quando si rinnova il contratto, che l'unico dipendente che lo conosce andrà in pensione l'anno prossimo, né che da lì esce un unico rapporto annuale sulla zakat. Queste informazioni vengono da un breve colloquio con il responsabile e gli utenti di ogni sistema. La macchina compila le colonne tecniche; le persone compilano quelle di business.

Le cinque decisioni per ogni sistema

Dopo l'inventario assegnate una decisione a ogni sistema. Ecco una versione semplificata delle sette strategie della guida di Amazon:

DecisioneCosa significa, in breveQuando è adatta
MantenereResta com'è per ora, sotto osservazioneStabile e isolato, legato a hardware speciale, aggiornato da poco o in attesa di una versione pronta del fornitore
DismettereLo spegnete e ne archiviate i datiNessun valore per il business, uso quasi nullo o tecnologia senza supporto che non vale la pena modernizzare
Sostituire con un prodotto prontoAcquistate un prodotto o un abbonamento che fa lo stesso lavoroIl lavoro che svolge è ordinario e non vi distingue, e un prodotto lo copre senza grandi modifiche
Spostare così com'èLo portate nel cloud senza cambiare il codiceIl problema è il server e l'hardware, non il software in sé
RicostruireLo riscrivete o ne cambiate la strutturaLe sue regole di business sono ciò che vi distingue, e non si può modificare o nessuno sa più gestirlo

La guida avverte che ricostruire è l'opzione più complessa e costosa e, per le grandi migrazioni, consiglia di spostare prima il sistema e modernizzarlo a migrazione conclusa. Se la vostra decisione è il cloud, partite dalla nostra guida al passaggio al cloud per le aziende saudite.

Il punto di vista di Origami

Costruiamo sistemi, li colleghiamo e modernizziamo quelli vecchi, eppure iniziamo ogni progetto di modernizzazione dall'inventario, non dal codice. Un sistema di cui non conoscete i collegamenti può rompere qualcosa che non vedrete finché un cliente non si lamenta, e l'inventario mostra spesso che la decisione giusta per molti sistemi è mantenerli o dismetterli, non ricostruirli.

Per questo usiamo strumenti di IA per leggere rapidamente server e codice e mappare i collegamenti, poi ci sediamo con il responsabile di ogni sistema per completare ciò che lo strumento non può sapere, e ne usciamo con una decisione per sistema e un ordine chiaro per partire. Se volete vedere come lavoriamo, date un'occhiata ai nostri servizi.

L'esercizio della settimana: una pagina per sistema

Prendete i sistemi che hanno ottenuto 6 su 8 o più nell'esercizio della parte 2 e compilate questa tabella per ciascuno su una sola pagina:

VoceRisposta
Nome del sistema e cosa fa, in una frase
Responsabile di business
Utenti (reparti, numero approssimativo, soggetti esterni)
Dati, se includono dati personali e dove sono conservati
Collegamenti in entrata e in uscita
Cosa si ferma se si ferma per un giorno
Licenze, data di rinnovo e termine di preavviso
Tecnologia e fine del suo supporto
Punteggio della parte 2 su 8
Decisione provvisoria, una delle cinque

Scrivete la decisione a matita. Resta provvisoria finché non sapete quali regole vivono dentro il sistema, ed è questo il tema della prossima parte.

Prossimamente

Ora avete un inventario e una decisione provvisoria per ogni sistema. Ma i sistemi che avete deciso di ricostruire nascondono il loro bene più prezioso: le vere regole di business per sconti, prezzi, penali per ritardo e approvazioni, sepolte nel codice e nella testa delle persone. Nella parte 4 spieghiamo come l'IA estrae queste regole dal vostro vecchio sistema e le scrive come specifiche chiare, e perché il responsabile di ogni processo deve confermare ogni regola prima che venga scritto qualsiasi nuovo codice.

Fonti