Acquistare servizi di modernizzazione COBOL non somiglia a nessun altro acquisto di lavoro software. Il sistema in questione gira da trenta o quarant’anni, nessuno fra le persone attualmente in azienda lo comprende del tutto, e le conseguenze di un errore si misurano in segnalazioni regolamentari mancate anziché in sprint saltati. Nel frattempo le proposte sulla vostra scrivania promettono tutte lo stesso risultato a prezzi enormemente diversi.

Questa guida illustra che cosa contiene davvero un incarico serio, in che cosa differiscono le categorie di fornitori e quali domande separano un’offerta costruita sulle evidenze da una costruita sull’ottimismo. Presuppone che siate voi a dover difendere la decisione in seguito.

Che cosa cercare: una proposta credibile di modernizzazione COBOL comprende discovery, progetto dell’architettura di destinazione, migrazione dei dati, conversione o rehosting, un programma di test basato sul confronto, un esercizio in parallelo, la pianificazione del passaggio in produzione e il trasferimento di competenze. Se un’offerta valorizza solo la conversione del codice, non è un piano di programma: è il suo quarto meno costoso.

Che cosa comprendono davvero i servizi di modernizzazione COBOL

Chiedete una proposta a tre fornitori e riceverete tre definizioni diverse del perimetro. Uniformare quell’elenco prima di confrontare i prezzi è la cosa più utile che possiate fare, perché un’offerta che omette metà del lavoro apparirà sempre migliore nella pagina di sintesi.

Discovery e analisi vengono per prime. Il fornitore analizza l’intero patrimonio applicativo, costruisce le mappe delle dipendenze e della provenienza dei dati, individua il codice morto e produce un inventario di programmi, copybook, catene di job e oggetti di base dati. Questa fase deve anche segnalare i costrutti che determinano il costo: moduli Assembler, schemi transazionali inconsueti, tracciati record varianti e tutto ciò che il compilatore tollera da decenni.

L’architettura di destinazione viene subito dopo. Qualcuno deve decidere che cosa diventa il sistema: un carico COBOL rehostato, una base di codice convertita in un linguaggio moderno, un insieme di servizi, o una combinazione scaglionata nel tempo. Questa decisione precede l’inizio della conversione e va documentata con il ragionamento in chiaro, non semplicemente affermata.

La migrazione dei dati copre progetto dello schema, estrazione, conversione e riconciliazione. I formati dati del mainframe portano un significato che uno schema relazionale non può esprimere direttamente, per cui questo lavoro è analitico e non meccanico.

Conversione del codice o rehosting è la parte su cui tutti si concentrano e rappresenta di norma una minoranza dello sforzo complessivo. Gli strumenti di migrazione mainframe ne assorbono una parte consistente, ma non tutta, e il punto esatto in cui passa quel confine determina il carico delle altre fasi.

Le fasi che i committenti tagliano più spesso

Test e confronto sono il punto in cui va il denaro. Un programma fatto bene costruisce un banco che esegue il vecchio e il nuovo sistema sugli stessi input e confronta gli output campo per campo, poi lavora sulle differenze finché ciascuna non è corretta o formalmente accettata. È un progetto software a pieno titolo e va valorizzato come tale.

Esercizio in parallelo e passaggio in produzione significano far girare entrambi i sistemi per un periodo definito con volumi reali di produzione, per poi commutare con un piano di rientro già provato. I programmi che saltano questa fase per guadagnare tempo sono quelli che finiscono nei casi di studio per le ragioni sbagliate.

Trasferimento di competenze e supporto chiudono l’incarico. Il vostro team deve poter esercire e modificare il risultato senza il fornitore. Se questo non è un deliverable esplicito con criteri di accettazione, non avete comprato una modernizzazione: avete comprato una dipendenza.

I tre tipi di fornitore e i punti di forza di ciascuno

Il mercato si divide in tre gruppi con punti di forza realmente diversi, e la scelta giusta dipende più dal vostro patrimonio applicativo che da qualsiasi classifica.

I produttori di strumenti e i loro partner si presentano con la conversione automatizzata o con una piattaforma di rehosting. La loro tecnologia è di norma matura e la produttività di conversione è davvero notevole. L’aspetto da valutare è l’allineamento degli interessi: il loro interesse commerciale sta nel massimizzare la quota di lavoro svolta dal loro prodotto, che non coincide sempre con una base di codice che vi farà piacere manutenere. Inoltre legano il vostro esercizio produttivo al loro runtime, ed è una dipendenza che conviene valorizzare economicamente.

I grandi integratori globali portano scala, governance di programma e la capacità di presidiare uno sforzo pluriennale. Se il patrimonio conta milioni di righe distribuite su più aree di business, questa capacità pesa e pochi altri possono fornirla. Il contrappeso sta nella struttura dei costi e nella distanza fra chi ha scritto la proposta e chi svolgerà il lavoro. Chiedete in modo esplicito chi compone il team, dove si trova e quale esperienza porta.

Le società di ingegneria specializzate sono più piccole, lavorano con figure senior dall’inizio alla fine e sono di norma neutrali rispetto agli strumenti, perché non hanno un prodotto da vendere. Sono adatte a patrimoni di qualche centinaio di migliaia di righe, a programmi per fasi e alle situazioni in cui la difficoltà sta nella logica di business più che nel volume. Non possono presidiare un programma da duecento persone, e dovrebbero dirlo.

Non esiste una risposta universalmente corretta. Esiste una risposta corretta per un determinato patrimonio applicativo, e ogni fornitore che sostenga che il proprio modello va bene per ogni situazione vi sta dicendo qualcosa di utile su come vende.

Le domande che smascherano un’offerta debole

I questionari di gara raramente fanno emergere ciò che conta. Queste domande sì.

“Convertite il nostro modulo peggiore e mostrateci il risultato.” Scegliete il programma che tutti evitano, possibilmente uno che richiama Assembler e usa un record variante a più livelli. Chiedete di vedere il codice generato, non una sintesi. Un fornitore convinto del proprio approccio lo farà a fronte di un compenso di scoping fisso e contenuto. La riluttanza è già una risposta.

“Come gestite l’aritmetica decimale e l’ordinamento?” I campi decimali impaccati e la sequenza di collazione del mainframe producono entrambi differenze che emergono solo nei risultati economici e nell’ordine dei tabulati. Le risposte devono essere puntuali e tecniche. La vaghezza su questo punto preannuncia una fase di collaudo utente difficile.

“Che cosa contiene esattamente il perimetro di test, e chi scrive il banco di confronto?” Cercate un deliverable con un nome, una stima di impegno e chiarezza su chi fornisce dati rappresentativi della produzione. Se il test è descritto come una percentuale della costruzione, il fornitore sta tirando a indovinare.

“Che cosa succede alle differenze che non riuscite a spiegare?” Ogni programma trova output che divergono senza che nessuno sappia perché. I buoni fornitori descrivono un processo di triage con approvazione del business. Chi sostiene che non capiti o non ha mai portato a termine un programma o non è del tutto sincero.

“Di chi è il codice sorgente risultante, e possiamo andarcene?” La risposta deve essere che tutto è vostro senza vincoli e che non serve alcuna licenza di runtime per continuare a operare. Se una parte della risposta comporta la licenza continuativa di uno strato proprietario, chiarite esattamente che cosa accade al vostro sistema di produzione il giorno in cui smettete di pagare.

“Mostrateci un programma andato male e che cosa avete cambiato dopo.” Ogni organizzazione che ne abbia fatti più di una manciata ne ha uno. La risposta vi dice se state parlando con ingegneri o con una funzione commerciale.

Come vengono prezzati i servizi di modernizzazione COBOL

I modelli di prezzo variano e ciascuno distribuisce il rischio in modo diverso. Capire quella distribuzione conta più della cifra in copertina.

Il tempo e spese è il modello più onesto per un lavoro con incognite reali, e il più scomodo per un consiglio di amministrazione. Si adatta alla discovery, che andrebbe quasi sempre acquistata separatamente e per prima, proprio perché il resto possa essere quotato sulle evidenze invece che sulle ipotesi.

Il prezzo fisso a modulo o a migliaio di righe è comune per la conversione ed è ragionevole una volta che la discovery ha stabilito che cosa contengono i moduli. Leggete con attenzione le esclusioni. Questi prezzi presuppongono in genere codice compreso in una fascia di complessità definita, e tutto ciò che ne esce viene riquotato caso per caso: è lì che risiede la varianza.

Il prezzo legato al risultato, in cui il pagamento dipende dall’equivalenza funzionale accettata, allinea bene gli incentivi ma richiede criteri di accettazione abbastanza precisi da poter dirimere una controversia. Definire bene quei criteri vale lo sforzo che richiede.

Siate scettici di fronte a un prezzo chiuso per l’intero programma quotato prima che la discovery sia stata svolta. Non è una dimostrazione di fiducia. O è calcolato con contingenza sufficiente a coprire lo scenario peggiore, e allora state pagando un rischio che potrebbe non verificarsi, oppure è ottimistico e tornerà sotto forma di richieste di variazione non appena affioreranno i moduli difficili. Nessuna delle due è un affare.

Sulla questione degli sconti, questo mercato non funziona davvero così. Le riduzioni significative arrivano dal restringere il perimetro, dallo scaglionare il programma perché le fasi successive traggano vantaggio da quanto appreso nella prima, o dal dismettere il codice che la discovery mostra non essere più in uso. Un fornitore che abbatte sensibilmente il prezzo senza cambiare il perimetro vi ha appena detto che il primo numero era arbitrario. La nostra guida a costi e tempi della migrazione COBOL scompone dove va davvero il budget.

Le clausole contrattuali su cui insistere

Poche clausole proteggono il risultato meglio di qualsiasi quantità di governance.

Pretendete la proprietà piena e libera di tutto il codice sorgente consegnato, degli schemi, degli script e degli asset di test, banco di confronto compreso. Quel banco è un bene che riutilizzerete per anni.

Definite l’accettazione come equivalenza funzionale dimostrata su insiemi di dati concordati, non come consegna di codice. La distinzione fra “la conversione è completa” e “gli output coincidono” è l’intero progetto.

Richiedete una struttura a fasi con reali punti di uscita. Un programma suddiviso in discovery, pilota, conversione progressiva e passaggio in produzione vi consente di fermarvi dopo qualsiasi fase con qualcosa di valore in mano. Un incarico monolitico unico no.

Nominate le persone chiave nel contratto e inserite una clausola sulla sostituzione. Il divario fra il team che ha presentato e il team che poi arriva è la lamentela più diffusa in questo mercato.

Infine, rendete il trasferimento di competenze un deliverable con propri criteri di accettazione, comprovato dal vostro team che esegue una modifica reale senza assistenza. Altrimenti diventa una presentazione consegnata nell’ultima settimana.

Parlate con ingegneri, non con rivenditori

Mecanik lavora su programmi di modernizzazione COBOL e di migrazione COBOL come società di ingegneria indipendente. Non rivendiamo una piattaforma di conversione, quindi la nostra raccomandazione sugli strumenti riflette ciò di cui ha bisogno il vostro codice e non ciò che abbiamo in licenza.

Partiamo dalla discovery e da un pilota a pagamento sul vostro modulo più difficile, perché produce una stima ancorata al vostro codice reale invece che a una media di settore. Da lì possiamo convertire, rehostare, oppure dirvi che al momento nessuna delle due cose è giustificata, il che ogni tanto è la risposta giusta. Le nostre pagine sul servizio di migrazione COBOL descrivono le fasi in maggior dettaglio, e la nostra guida alla strategia di modernizzazione mainframe affronta la scelta fra riscrittura, refactoring e cambio di piattaforma, che viene prima di tutto il resto.

Diteci all’incirca quanto è grande il patrimonio applicativo e che cosa impone i tempi, e vi diremo che aspetto ha un programma realistico.

Da leggere anche: Migrazione da COBOL a Java - Guida enterprise UK , Migrazione da COBOL a C#: guida UK 2026 , Migrazione da COBOL a Python e Migrazione da COBOL a Go: guida per le aziende UK .

Domande frequenti

Che cosa comprendono i servizi di modernizzazione COBOL? Un incarico completo copre discovery e analisi, progetto dell’architettura di destinazione, migrazione dei dati, conversione del codice o rehosting, un programma di test basato sul confronto, l’esercizio in parallelo, la pianificazione del passaggio in produzione e il trasferimento di competenze. Le proposte che valorizzano solo la conversione coprono una minoranza del lavoro reale.

Chi realizza la migrazione da COBOL a linguaggi moderni? Lo fanno tre gruppi: i produttori di strumenti con i loro partner di implementazione, i grandi integratori globali e le società di ingegneria specializzate indipendenti. I produttori offrono automazione matura, gli integratori la scala per patrimoni molto estesi, e gli specialisti ingegneri senior e indipendenza dagli strumenti per programmi di media dimensione.

Come vengono prezzati i progetti di modernizzazione COBOL? I modelli comuni sono il tempo e spese, il prezzo fisso a modulo o a migliaio di righe e il prezzo legato al risultato ancorato all’equivalenza funzionale. La discovery andrebbe acquistata separatamente e per prima, così che il resto possa essere quotato sulle evidenze invece che sulle ipotesi.

Devo accettare un prezzo chiuso prima della discovery? In genere no. Un prezzo chiuso quotato senza analisi o è imbottito di contingenza che potreste non usare, oppure è ottimistico e destinato a tornare sotto forma di richieste di variazione. Comprate prima la discovery e usate i suoi risultati per ottenere prezzi fermi sulle fasi successive.

Come verifico che un fornitore regga la mia base di codice? Chiedetegli di convertire il modulo più difficile durante lo scoping e di mostrarvi l’output generato. Scegliete qualcosa che contenga chiamate Assembler, tracciati record varianti e aritmetica decimale impaccata. Quello che produce, e la prontezza con cui accetta, dice più di qualsiasi colloquio con una referenza.