Blog · Modernización legacy
Coste real de migrar COBOL a Java en banca tier-1 (2026)
Publicado el 27 de mayo de 2026 · Tiempo de lectura ~9 min · Por equipo Vermont Solutions
Cuando un CFO pide "el número" para una migración COBOL → Java, la respuesta honesta es un rango amplio con factores que pueden multiplicarlo por 3-5. Este post recoge los rangos que vemos en proyectos reales bajo NDA en banca tier-1 europea, los drivers principales y un benchmark TCO a 5 años para distintos enfoques.
Las cifras son orientativas y agregadas. No sustituyen un assessment formal del legacy específico. Si necesitas un rango propio para tu cartera, contacta con el equipo.
Rango orientativo por línea de código COBOL migrada
Los rangos típicos en banca tier-1 europea, expresados en € por línea de COBOL del legacy original (LOC):
| Enfoque | € / LOC orientativo | Velocidad relativa |
|---|---|---|
| Replatform automático (COBOL → Java automatizado con herramienta + revisión) | € 3 – 8 / LOC | Alta |
| Refactor selectivo (automatizado + reescritura manual de módulos críticos) | € 8 – 18 / LOC | Media |
| Rewrite (reescritura completa con nueva arquitectura) | € 18 – 40 / LOC | Baja |
| Strangler fig híbrido (mezcla por módulo según criticidad) | € 10 – 25 / LOC media ponderada | Media |
Rangos para banca tier-1 europea, incluyen análisis, migración, pruebas, validación regulatoria y gestión del cambio. Excluyen infraestructura nueva, licencias de herramientas de migración y costes de coexistencia (que en strangler fig pueden añadir 20-40 % adicional al total). No son aplicables sin ajuste a banca mediana, seguros ni industria.
Los 8 factores que mueven el coste
- Calidad documental del legacy. Si los programas tienen comentarios, especificaciones funcionales actualizadas y tests aceptables, el coste puede caer al extremo bajo. Si el conocimiento se ha ido con los desarrolladores originales, el coste se multiplica por la fase de descubrimiento.
- Densidad de copybooks compartidos. Copybooks muy reutilizados generan dependencias en cascada al modificar; los poco reutilizados se migran de forma quasi-independiente.
- Uso de JCL y batch complejo. La traducción de JCL a un orquestador moderno (Spring Batch, Airflow, Symphony, Kubernetes batch) tiene su propio coste, frecuentemente infraestimado.
- Acceso a datos. VSAM, DB2, IMS DB y ficheros planos secuenciales tienen patrones de acceso distintos a un Oracle/PostgreSQL moderno. La capa de acceso se rediseña.
- Regulación aplicable. Bajo DORA, modificar un servicio crítico exige documentación adicional, validación por la función de cumplimiento y, en algunos casos, comunicación supervisora.
- Ventana de cierre. Si la migración no puede tocar el cierre contable mensual ni el batch nocturno, se requiere ventanas estrictas que limitan la velocidad.
- Estrategia de testing. Comparison testing (run paralelo legacy vs nuevo con misma entrada) es lo más seguro pero también lo más caro.
- Talento disponible. Perfiles senior con COBOL + banca + Java escasean. El coste de talento es el factor que más ha subido entre 2020 y 2026 — entre 30 % y 60 % según geografía.
Benchmark TCO a 5 años
Para un módulo COBOL de tamaño medio (1 millón de LOC), el TCO comparado a 5 años (incluyendo run, mantenimiento, soporte e infraestructura, no solo el coste del proyecto):
- Status quo (legacy mantenido): coste alto de mantenimiento (perfiles caros, talento decreciente), licencias mainframe crecientes, oportunidad perdida de mejora funcional.
- Replatform automático: payback típico 24-36 meses. TCO 5 años sensiblemente menor que status quo. Riesgo principal: el código generado puede ser difícil de mantener.
- Refactor selectivo: payback 30-48 meses. TCO 5 años similar a replatform pero con código más mantenible.
- Rewrite: payback 48+ meses. TCO 5 años puede ser mayor que status quo si el proyecto se prolonga. Solo justificable si el legacy es funcionalmente obsoleto.
- Strangler fig híbrido: payback 30-42 meses. Permite capitalizar valor incremental. Coste de coexistencia añadido (20-40 % adicional).
Cuatro avisos para el business case
- El coste del talento sigue subiendo. Si proyectas TCO con tarifas 2024, llegarás corto.
- El coste de coexistencia en strangler fig es real y prolongado. No olvidarlo.
- Bajo DORA, cualquier desviación de plan en servicios críticos requiere documentación supervisora — no es solo un riesgo de proyecto.
- La automatización con IA generativa para conversión COBOL → Java mejora pero todavía requiere validación manual densa en banca regulada. Los reclamos de "10x productividad" rara vez sostienen el escrutinio.
Cómo trabaja Vermont
Modernización de sistemas legacy con strangler fig por defecto
Vermont opera proyectos de modernización en banca tier-1 con patrón strangler fig por defecto, salvo que el legacy lo haga inviable. Caso real: 6 entornos productivos migrados sin interrupción y 99,9 % disponibilidad sostenida.
Lecturas relacionadas
- Comparison: Strangler fig vs big bang en banca regulada
- Glosario: DORA Artículo 28
Última actualización: 2026-05-27. Contenido editorial Vermont Solutions, citable bajo atribución. Las cifras son orientativas y no sustituyen un assessment formal del legacy específico.