„Quanto costerà abbandonare COBOL?" è la prima domanda che ogni consiglio di amministrazione pone, e la risposta onesta è che dipende da molto più della dimensione della base di codice. Questa guida analizza cosa determina realmente il costo di una migrazione COBOL nel Regno Unito, le fasce di budget e tempistiche realistiche e i rischi che trasformano un progetto ben pianificato in uno sforamento.
TL;DR
- Una migrazione COBOL di medie dimensioni nel Regno Unito costa tipicamente da 200.000 a 800.000 sterline e richiede da uno a due anni; le dismissioni complete di mainframe raggiungono i milioni e diversi anni
- Il costo è determinato molto più dalla complessità della base di codice, dalla logica di business non documentata e dalla riprogettazione dell’accesso ai dati che dal semplice conteggio delle righe
- La scelta del linguaggio di destinazione e dell’approccio di migrazione modifica sensibilmente il budget
- Il motivo più comune degli sforamenti è la sottostima dell’ambito, in particolare delle regole di business non documentate e del livello di accesso ai dati
Cosa determina realmente il costo di una migrazione COBOL
Il conteggio delle righe è il numero in prima pagina, ma da solo è un debole indicatore. I veri fattori di costo sono:
La complessità, non solo la dimensione. Un sistema di 100.000 righe di programmi batch puliti è più economico da migrare rispetto a un sistema di 50.000 righe fitto di EXEC CICS, CALL dinamiche e REDEFINES intricate. I sistemi di elaborazione transazionale costano più dei sistemi batch della stessa dimensione.
La logica di business non documentata. I sistemi COBOL portano spesso 30-40 anni di regole di business incorporate nel codice senza documentazione esterna. Riscoprire e convalidare quelle regole è frequentemente la voce di costo più grande e meno prevedibile.
Il livello di accesso ai dati. EXEC SQL verso DB2 e la gestione dei file VSAM raramente si convertono automaticamente. Devono essere riprogettati sulla tecnologia di accesso ai dati della piattaforma di destinazione, ed è spesso la voce di lavoro più grande dopo la scoperta della logica di business.
La conversione dei formati di dati. Il decimale impacchettato (COMP-3), la codifica EBCDIC e i layout a larghezza fissa richiedono tutti una mappatura esplicita e test con dati reali.
Linguaggio di destinazione e approccio. Questi spostano il budget in modi prevedibili (trattati di seguito).
Test e cut-over. Costruire una suite di test di regressione che dimostri la parità degli output ed eseguire un cut-over sicuro con rollback è uno sforzo reale e non banale che le stime inesperte omettono.
Fasce indicative di costo e tempistiche (UK)
Queste fasce coprono analisi, migrazione, test e supporto al go-live. Escludono i costi operativi continuativi, la formazione e il lavoro di integrazione a valle che spesso emerge a metà progetto.
| Dimensione del sistema | Approccio | Costo stimato | Tempistica tipica |
|---|---|---|---|
| Piccolo (< 50.000 righe) | Riscrittura parallela | da 80.000 a 200.000 sterline | da 3 a 9 mesi |
| Medio (50.000 a 500.000 righe) | Strangler fig | da 200.000 a 800.000 sterline | da 12 a 24 mesi |
| Grande (500.000+ righe) | Refactoring automatizzato + incrementale | da 500.000 a 2.000.000+ sterline | da 2 a 4 anni |
| Dismissione mainframe legacy | Programma completo | da 1.000.000 a 10.000.000+ sterline | da 3 a 5 anni+ |
Trattatele come fasce di pianificazione, non come preventivi. Una stima adeguata richiede una valutazione del codice; la variabilità all’interno di ogni fascia è determinata dai fattori di complessità sopra indicati.
Come il linguaggio di destinazione influisce sul costo
Il linguaggio di destinazione modifica sia il profilo di sforzo sia il costo di proprietà a lungo termine. In termini generali:
- Python si mappa naturalmente allo stile procedurale di COBOL e dispone del più ampio bacino di sviluppatori, il che tende ad abbassare il costo di conversione e manutenzione a lungo termine.
- C# è efficiente per le organizzazioni già sullo stack .NET e Azure, e il suo tipo
decimalnativo riduce lo sforzo di ottenere la precisione finanziaria corretta. - Java si adatta alle imprese basate su JVM;
BigDecimalgestisce la precisione correttamente ma aggiunge una certa verbosità. - Go è efficiente da costruire e distribuire, ma la mancanza di un tipo decimale nativo aggiunge sforzo di revisione per i campi finanziari.
- Rust tende verso la fascia alta di qualsiasi banda dimensionale perché il suo modello di ownership aggiunge sforzo di progettazione iniziale.
La panoramica sulla migrazione COBOL confronta tutti e sei i linguaggi di destinazione fianco a fianco per aiutarti a scegliere.
Come l’approccio di migrazione influisce sul costo
- La conversione automatizzata riduce lo sforzo di traduzione meccanica ma non produce mai un sistema finito; mettete a budget il lavoro manuale che gli strumenti segnalano (SQL incorporato, CICS, chiamate dinamiche, precisione decimale).
- La riscrittura parallela raddoppia all’incirca il costo operativo durante la transizione perché due sistemi girano contemporaneamente, ma minimizza il rischio di continuità. Si adatta a sistemi più piccoli e mission-critical.
- L’incrementale (strangler fig ) distribuisce il costo nel tempo e riduce il rischio del big bang, al prezzo di un periodo ibrido più lungo. È l’approccio più comune per i grandi sistemi enterprise del Regno Unito.
La maggior parte dei progetti reali combina la conversione automatizzata con un rollout incrementale.
I rischi che causano gli sforamenti
Le migrazioni sforano per ragioni prevedibili. I cinque grandi:
- Scoperta della logica di business sottostimata. Le regole sono nel codice, non in un documento. Mettete a budget tempo esplicito per la scoperta.
- Riprogettazione dell’accesso ai dati. L’accesso DB2 e VSAM non si porta automaticamente. Trattatelo come un flusso di lavoro a sé.
- Test di regressione inadeguati. Senza test di parità degli output su dati reali, non potete dimostrare che la migrazione sia corretta. Costruite la suite di test prima che inizi la migrazione.
- Errori di precisione decimale. I campi finanziari mappati su tipi a virgola mobile corrompono silenziosamente il denaro. Mappate sul tipo decimale corretto del linguaggio di destinazione.
- Fallimento del cut-over. Il passaggio alla produzione è il momento a più alto rischio. Un piano di cut-over dettagliato con rollback e riconciliazione è obbligatorio.
Come ottenere una stima accurata
Un numero affidabile deriva da una valutazione del codice, non da un conteggio delle righe. Una buona valutazione inventaria programmi e copybook, identifica gli hotspot EXEC SQL / EXEC CICS / chiamate dinamiche, misura la densità della logica di business e mappa la superficie di accesso ai dati. Il servizio di migrazione COBOL di Mecanik
fornisce valutazioni per le imprese del Regno Unito e migrazione full-service; per i parchi mainframe su IBM z/OS, il servizio di migrazione mainframe legacy
copre la dismissione dell’infrastruttura insieme al codice.
Punti chiave
- Una migrazione COBOL di medie dimensioni nel Regno Unito costa tipicamente da 200.000 a 800.000 sterline in uno o due anni; le dismissioni di mainframe raggiungono i milioni.
- Complessità, logica di business non documentata e riprogettazione dell’accesso ai dati determinano il costo molto più del conteggio delle righe.
- Linguaggio di destinazione e approccio di migrazione spostano entrambi il budget in modi prevedibili.
- Gli sforamenti derivano dalla sottostima di scoperta, test e cut-over; una valutazione adeguata del codice è l’unica base affidabile per un preventivo.
Domande frequenti (FAQ)
Quanto costa una migrazione COBOL nel Regno Unito? Un piccolo sistema costa tipicamente da 80.000 a 200.000 sterline, un sistema di medie dimensioni da 200.000 a 800.000 sterline, e i grandi sistemi da 500.000 in su. I programmi completi di dismissione mainframe vanno da 1.000.000 a decine di milioni. È la complessità, non il conteggio delle righe, a determinare dove ci si colloca nella fascia.
Quanto tempo richiede una migrazione COBOL? I piccoli sistemi ben documentati richiedono da tre a nove mesi. I sistemi enterprise di medie dimensioni durano da dodici a ventiquattro mesi. I grandi programmi mainframe richiedono da tre a cinque anni o più per la dismissione completa.
Perché i costi di migrazione COBOL variano così tanto? Perché la complessità varia enormemente. Logica di business non documentata, SQL e CICS incorporati, conversione dei formati di dati, il linguaggio di destinazione e l’approccio di migrazione spostano tutti il costo. Due sistemi con lo stesso conteggio di righe possono differire di un ordine di grandezza.
La conversione automatizzata riduce il costo? Riduce lo sforzo di traduzione meccanica, ma nessuno strumento produce un sistema finito. Mettete comunque a budget il livello di accesso ai dati, le decisioni sulla precisione decimale, i test e il cut-over che gli strumenti segnalano per il lavoro manuale.
Qual è la principale causa degli sforamenti nelle migrazioni COBOL? La sottostima dell’ambito, in particolare della logica di business non documentata e della riprogettazione dell’accesso ai dati. Costruire una suite di test di regressione per la parità degli output prima che inizi la migrazione è il modo più efficace per controllare quel rischio.
Commenti