Una cartera de aplicaciones no se migra como un solo programa
Cuando varias aplicaciones COBOL comparten datos, el orden de intervención importa. Una librería aparentemente pequeña puede condicionar muchos procesos, mientras que un programa grande puede tener una frontera bien definida. En el análisis identificamos productores, consumidores y responsables antes de proponer el calendario.
Para una empresa madrileña con varios equipos implicados, una entrega útil es un mapa que muestre qué se puede cambiar de forma independiente. No reducimos la prioridad a antigüedad o tamaño del código: también consideramos el impacto operativo, la facilidad de probar y las dependencias de proveedores.
Decisiones explícitas para cada componente
Mantenimiento, integración y migración pueden convivir dentro del mismo proyecto. Documentamos qué partes seguirán en COBOL, cuáles tendrán una interfaz nueva y cuáles se estudiarán para C# sobre .NET. Así se evita que la palabra «modernización» se interprete como una reescritura completa por un equipo y como un cambio de servidor por otro.
Las decisiones incluyen lo que queda fuera. Si una migración no contempla modificar reglas de negocio, cualquier diferencia detectada debe clasificarse como incidencia o cambio solicitado. Mezclar ambas cosas dificulta la aceptación y hace que el alcance crezca sin una decisión consciente.
Evidencias que permitan aprobar un hito
Proponemos relacionar cada entrega con procesos de negocio comprobables. El comité o responsable del proyecto necesita saber qué operación funciona, qué excepciones se han ensayado y qué limitaciones siguen abiertas. Un porcentaje de líneas convertidas no responde a esas preguntas.
El plan puede exigir ejecuciones comparadas, revisión del usuario y documentación de reversión. Los criterios se acuerdan antes del desarrollo para no discutir al final qué significa «equivalente». Las pruebas deben poder repetirse sobre una versión identificada, no depender de una demostración preparada a mano.
OpenAI, Anthropic y la gobernanza del uso de IA
El uso de herramientas de OpenAI o de Claude, de Anthropic, se encuadra en las reglas del proyecto. Definimos repositorios autorizados, tareas permitidas y revisión de los cambios propuestos. No asumimos que una autorización para generar documentación también permite enviar datos de producción.
La IA puede ayudar a preparar borradores y localizar relaciones que luego revisa el equipo. La responsabilidad de aprobar arquitectura, equivalencia y accesos no se delega en la herramienta. Tampoco se presenta su participación como una certificación de calidad del resultado.
Una hoja de ruta que admita correcciones
El primer módulo debe servir para contrastar supuestos sobre esfuerzo y dependencia. Tras el piloto se actualiza la planificación: puede aparecer una integración no inventariada, una regla sin propietario o una restricción del entorno. Mantener esas dudas visibles es preferible a ocultarlas dentro de una cifra global.
Podemos trabajar en una evaluación inicial o en un proyecto de desarrollo acordado por fases. La propuesta económica se apoya en el alcance disponible y distingue lo conocido de lo pendiente de investigar. No ofrecemos un precio por línea como sustituto del análisis técnico.