« Combien coûtera l’abandon de COBOL ? » est la première question que pose chaque conseil d’administration, et la réponse honnête est que cela dépend de bien plus que de la taille de la base de code. Ce guide détaille ce qui détermine réellement le coût de migration COBOL au Royaume-Uni, les fourchettes de budget et de calendrier réalistes, et les risques qui transforment un projet bien planifié en dépassement.
TL;DR
- Une migration COBOL de taille moyenne au Royaume-Uni coûte généralement 200 000 à 800 000 livres sterling et prend un à deux ans ; les décommissionnements complets de mainframe se chiffrent en millions et sur plusieurs années
- Le coût dépend bien plus de la complexité de la base de code, de la logique métier non documentée et de la refonte de l’accès aux données que du simple nombre de lignes
- Le choix du langage cible et de l’approche de migration modifie sensiblement le budget
- La raison la plus courante des dépassements est la sous-estimation du périmètre, en particulier des règles métier non documentées et de la couche d’accès aux données
Ce qui détermine réellement le coût de migration COBOL
Le nombre de lignes est le chiffre en une, mais c’est un prédicteur faible à lui seul. Les véritables facteurs de coût sont :
La complexité, pas seulement la taille. Un système de 100 000 lignes de programmes batch propres est moins coûteux à migrer qu’un système de 50 000 lignes dense en EXEC CICS, CALLs dynamiques et REDEFINES complexes. Les systèmes de traitement transactionnel coûtent plus cher que les systèmes batch de même taille.
La logique métier non documentée. Les systèmes COBOL portent souvent 30 à 40 ans de règles métier intégrées dans le code sans documentation externe. Redécouvrir et valider ces règles est fréquemment le poste le plus important et le moins prévisible.
La couche d’accès aux données. EXEC SQL sur DB2 et la gestion des fichiers VSAM se convertissent rarement automatiquement. Ils doivent être repensés sur la technologie d’accès aux données de la plateforme cible, et c’est souvent le plus gros poste de travail après la découverte de la logique métier.
La conversion des formats de données. Le décimal condensé (COMP-3), l’encodage EBCDIC et les dispositions à largeur fixe nécessitent tous une cartographie explicite et des tests avec des données réelles.
Le langage cible et l’approche. Ceux-ci déplacent le budget de manière prévisible (traité ci-dessous).
Tests et bascule. Construire une suite de tests de régression qui prouve la parité des sorties, et exécuter une bascule sûre avec rollback, est un effort réel et non trivial que les estimations inexpérimentées omettent.
Fourchettes indicatives de coût et de calendrier (UK)
Ces fourchettes couvrent l’analyse, la migration, les tests et le support de mise en production. Elles excluent les coûts opérationnels récurrents, la formation et les travaux d’intégration en aval qui surgissent souvent en cours de projet.
| Taille du système | Approche | Coût estimé | Calendrier typique |
|---|---|---|---|
| Petit (< 50 000 lignes) | Réécriture parallèle | 80 000 à 200 000 livres sterling | 3 à 9 mois |
| Moyen (50 000 à 500 000 lignes) | Strangler fig | 200 000 à 800 000 livres sterling | 12 à 24 mois |
| Grand (500 000+ lignes) | Refactorisation automatisée + incrémentale | 500 000 à 2 000 000+ livres sterling | 2 à 4 ans |
| Décommissionnement de mainframe legacy | Programme complet | 1 000 000 à 10 000 000+ livres sterling | 3 à 5 ans+ |
Traitez-les comme des fourchettes de planification, pas comme des devis. Une estimation appropriée nécessite une évaluation du code ; l’écart au sein de chaque tranche est déterminé par les facteurs de complexité ci-dessus.
Comment le langage cible affecte le coût
Le langage de destination modifie à la fois le profil d’effort et le coût de possession à long terme. En termes généraux :
- Python se calque naturellement sur le style procédural de COBOL et dispose du plus grand vivier de développeurs, ce qui tend à réduire le coût de conversion et de maintenance à long terme.
- C# est efficace pour les organisations déjà sur la pile .NET et Azure, et son type
decimalnatif réduit l’effort nécessaire pour obtenir une précision financière correcte. - Java convient aux entreprises basées sur la JVM ;
BigDecimalgère la précision correctement mais ajoute une certaine verbosité. - Go est efficace à construire et à déployer, mais l’absence de type décimal natif ajoute un effort de revue pour les champs financiers.
- Rust tend vers le haut de gamme de toute tranche de taille car son modèle de propriété ajoute un effort de conception initial.
L’aperçu de la migration COBOL compare les six langages cibles côte à côte pour vous aider à choisir.
Comment l’approche de migration affecte le coût
- La conversion automatisée réduit l’effort de traduction mécanique mais ne produit jamais un système fini ; budgétisez le travail manuel que l’outillage signale (SQL intégré, CICS, appels dynamiques, précision décimale).
- La réécriture parallèle double approximativement le coût opérationnel pendant la transition car deux systèmes fonctionnent en même temps, mais elle minimise le risque de continuité. Elle convient aux systèmes plus petits et critiques.
- L’incrémental (strangler fig ) répartit le coût dans le temps et réduit le risque du big bang, au prix d’une période hybride plus longue. C’est l’approche la plus courante pour les grands systèmes d’entreprise au Royaume-Uni.
La plupart des projets réels mélangent conversion automatisée et déploiement incrémental.
Les risques qui causent les dépassements
Les migrations dérapent pour des raisons prévisibles. Les cinq grands :
- Découverte de la logique métier sous-estimée. Les règles sont dans le code, pas dans un document. Budgétisez un temps de découverte explicite.
- Refonte de l’accès aux données. L’accès DB2 et VSAM ne se porte pas automatiquement. Traitez-le comme son propre chantier.
- Tests de régression inadéquats. Sans tests de parité des sorties sur des données réelles, vous ne pouvez pas prouver que la migration est correcte. Construisez la suite de tests avant le début de la migration.
- Erreurs de précision décimale. Les champs financiers mappés vers des types à virgule flottante corrompent silencieusement l’argent. Mappez vers le type décimal correct du langage cible.
- Échec de la bascule. Le passage en production est le moment le plus risqué. Un plan de bascule détaillé avec rollback et réconciliation est obligatoire.
Comment obtenir une estimation précise
Un chiffre fiable provient d’une évaluation du code, pas d’un comptage de lignes. Une bonne évaluation inventorie les programmes et copybooks, identifie les points chauds EXEC SQL / EXEC CICS / appels dynamiques, mesure la densité de la logique métier et cartographie la surface d’accès aux données. Le service de migration COBOL de Mecanik
fournit des évaluations pour les entreprises du Royaume-Uni et une migration en service complet ; pour les parcs mainframe sur IBM z/OS, le service de migration de mainframe legacy
couvre le décommissionnement de l’infrastructure aux côtés du code.
Points clés à retenir
- Une migration COBOL de taille moyenne au Royaume-Uni coûte généralement 200 000 à 800 000 livres sterling sur un à deux ans ; les décommissionnements de mainframe se chiffrent en millions.
- La complexité, la logique métier non documentée et la refonte de l’accès aux données déterminent le coût bien plus que le nombre de lignes.
- Le langage cible et l’approche de migration déplacent tous deux le budget de manière prévisible.
- Les dépassements viennent de la sous-estimation de la découverte, des tests et de la bascule ; une évaluation du code appropriée est la seule base fiable pour un devis.
Foire aux questions (FAQ)
Combien coûte une migration COBOL au Royaume-Uni ? Un petit système coûte généralement 80 000 à 200 000 livres sterling, un système de taille moyenne 200 000 à 800 000 livres sterling, et les grands systèmes 500 000 et plus. Les programmes complets de décommissionnement de mainframe vont de 1 000 000 à des dizaines de millions. C’est la complexité, pas le nombre de lignes, qui détermine où vous vous situez dans la fourchette.
Combien de temps prend une migration COBOL ? Les petits systèmes bien documentés prennent trois à neuf mois. Les systèmes d’entreprise de taille moyenne durent douze à vingt-quatre mois. Les grands programmes mainframe prennent trois à cinq ans ou plus pour un décommissionnement complet.
Pourquoi les coûts de migration COBOL varient-ils autant ? Parce que la complexité varie énormément. La logique métier non documentée, le SQL et CICS intégrés, la conversion des formats de données, le langage cible et l’approche de migration déplacent tous le coût. Deux systèmes du même nombre de lignes peuvent différer d’un ordre de grandeur.
La conversion automatisée réduit-elle le coût ? Elle réduit l’effort de traduction mécanique, mais aucun outil ne produit un système fini. Vous budgétisez toujours la couche d’accès aux données, les décisions de précision décimale, les tests et la bascule que l’outillage signale pour un travail manuel.
Quelle est la principale cause des dépassements de migration COBOL ? La sous-estimation du périmètre, en particulier de la logique métier non documentée et de la refonte de l’accès aux données. Construire une suite de tests de régression pour la parité des sorties avant le début de la migration est le moyen le plus efficace de maîtriser ce risque.
Commentaires