Modernización de VBA Legado con IA y el Modelo del Queso Suizo

11 min de lectura

Cuando el Código Legado Es el Negocio

07.03.2026, Por Stephan Schwab

Cuando su negocio funciona con una aplicación de hace una década con personalizaciones en VBA que nadie entiende completamente, la modernización no es opcional — es supervivencia. El éxito requiere usar IA para la extracción de conocimiento del VBA legado, construir suites de pruebas en Java para validación y aplicar el modelo del queso suizo para asegurar que su nueva implementación produzca exactamente los mismos resultados. Porque casi correcto significa fracaso empresarial.

En algún lugar de su organización, hay una aplicación empresarial. Ha estado allí durante quince años. Comenzó como software estándar, pero el proveedor expuso VBA para personalización, y su organización lo aprovechó. Lo que comenzó como una simple automatización creció hasta convertirse en lógica crítica para el negocio, y ahora ejecuta decisiones de precios por valor de millones. La persona que escribió estas personalizaciones se retiró en 2019. La documentación es el código mismo — si se le puede llamar documentación.

Este no es un escenario hipotético. Veo situaciones similares regularmente. Las personalizaciones de VBA que calculan primas de seguros en un sistema de gestión de pólizas. El software de contabilidad con scripts de VBA que concilian pagos internacionales. La plataforma CRM donde VBA automatiza una compleja puntuación de leads. Todo crítico para el negocio. Todo irreemplazable. Todo aterrador.

Cuando las organizaciones finalmente deciden modernizar estos sistemas, se enfrentan a un problema fundamental: nadie sabe exactamente qué hace el sistema. Saben lo que se supone que debe hacer. Saben qué botones presionar. Pero la lógica real — los casos extremos, el manejo especial, las peculiaridades que se acumularon durante años de parches — existe solo en el código.

Por Qué Falla la Modernización

La mayoría de los proyectos de modernización de legado fallan por una simple razón: el nuevo sistema no produce los mismos resultados que el antiguo.

Esto suena obvio. Por supuesto, el nuevo sistema debería coincidir con el antiguo. Pero la coincidencia es más difícil de lo que parece. Un cálculo de precios que difiere en un 0.3% puede parecer aceptable hasta que te das cuenta de que el 0.3% en diez mil transacciones por día se convierte en una discrepancia de ingresos significativa. Finanzas se da cuenta. Los auditores hacen preguntas. La confianza se evapora.

El problema no es la capacidad técnica. Los desarrolladores modernos pueden construir sistemas elegantes. El problema es la extracción de conocimiento. ¿Cómo captura lo que el sistema legado realmente hace, incluidos todos los comportamientos no documentados que se han convertido en requisitos comerciales simplemente porque han estado sucediendo durante años?

La IA como su Socio de Extracción de Conocimiento

Aquí es donde la IA se vuelve genuinamente útil — no como un reemplazo para los desarrolladores, sino como un asistente arqueológico que nunca se aburre de leer código terrible.

VBA escrito en 2008 por un profesional de finanzas que aprendió programación por prueba y error tiene un carácter particular. Variables llamadas temp2, finalFinal y estoFunciona. Funciones que abarcan 400 líneas. Bloques copiados y pegados con variaciones sutiles. Comentarios que dicen “no toques esto” sin explicar por qué.

Un asistente de IA puede leer este código y extraer significado que a un desarrollador humano le tomaría días armar. Aliméntelo con un módulo VBA de 2000 líneas y pregunte: “¿Qué reglas de negocio están codificadas en esta función?” La IA identificará los pasos de cálculo, notará las ramas condicionales y describirá la lógica en lenguaje sencillo.

Este flujo de trabajo es particularmente efectivo en IDEs como VS Code donde puede mantener un diálogo continuo con la IA. Puede pedirle que analice secciones específicas de código y documente sus hallazgos en un archivo markdown separado — creando un registro de investigación estructurado. Este archivo se convierte esencialmente en su carta de navegación, destacando lógica ambigua, constantes codificadas o dependencias extrañas que necesitan más investigación.

Pero aquí está el punto crítico: la interpretación de la IA es una hipótesis, no un hecho verificado. La IA podría malinterpretar una sintaxis oscura de VBA. Podría perder contexto que solo tiene sentido si conoce el dominio del negocio. Podría explicar con confianza una lógica que el autor original hizo mal, y esa equivocación se ha convertido en el comportamiento esperado.

No puede confiar directamente en la salida de la IA. Necesita validación.

Construyendo el Arnés de Pruebas

La solución es construir una suite de pruebas completa antes de escribir una sola línea de código de reemplazo. No pruebas que verifiquen su comprensión de lo que el sistema debería hacer — pruebas que capturen lo que el sistema realmente hace.

Esto requiere ejecutar el sistema legado con entradas conocidas y registrar las salidas. Cada escenario. Cada caso extremo que pueda identificar. Cada combinación de parámetros que el negocio utiliza en la práctica.

@ParameterizedTest
@MethodSource("legacyCalculationTestCases")
void newCalculation_MatchesLegacyOutput(
    CalculationInput input,
    LegacyOutput expectedOutput) {
    
    var result = newCalculationEngine.calculate(input);
    
    assertEquals(expectedOutput.getPremium(), result.getPremium(), 0.0001);
    assertEquals(expectedOutput.getTax(), result.getTax(), 0.0001);
    assertEquals(expectedOutput.getFees(), result.getFees(), 0.0001);
}

Las herramientas de IA aceleran la construcción de este arnés. En lugar de determinar manualmente qué entradas cubren todas las rutas de código, alimente la lógica de VBA a un asistente de IA. Pídale que identifique valores límite y activadores condicionales. Detectará que la línea 403 verifica transacciones superiores a $10,000 y sugerirá un caso de prueba para $10,001. También puede generar las estructuras de datos Java (DTOs) directamente desde las definiciones de Tipo VBA, manejando la traducción de sintaxis tediosa al instante.

Podemos ir más allá. Bajo supervisión humana en un diálogo constante, puede construir las pruebas al estilo TDD. En lugar de intentar entender todo el sistema a la vez, utiliza la IA para descubrir reglas incrementalmente y fijarlas con pruebas. Este proceso interactivo mantiene al humano en control — verificando la lógica — mientras la IA maneja el trabajo pesado de sintaxis y estructura.

A veces, ejecutar el VBA legado es difícil debido a dependencias ambientales. En estas situaciones, la IA puede analizar la estructura lógica para generar datos de prueba sintéticos y sensatos. Identifica las combinaciones de entrada necesarias para activar rutas específicas, permitiéndole construir escenarios de prueba completos incluso cuando el entorno de ejecución original es frágil.

Los casos de prueba provienen del sistema legado. Ejecute el VBA con estas entradas, capture esas salidas, guárdelas como su línea base de validación. Ahora tiene un oráculo — una fuente de verdad que define el comportamiento correcto no por especificación sino por observación.

Esencialmente, estamos construyendo un modelo del sistema antiguo en este punto. Aún no estamos diseñando la nueva arquitectura; estamos creando un mapa de comportamiento de alta fidelidad de la aplicación heredada. Este modelo ejecutable se convierte en la especificación de requisitos que ningún documento escrito podría igualar.

Este enfoque tiene un nombre en los círculos de pruebas: pruebas de caracterización, o a veces pruebas de maestro dorado (golden master). Está caracterizando el comportamiento existente, no especificando un nuevo comportamiento. El sistema legado es la especificación.

El Modelo del Queso Suizo para Validación

Aquí es donde el modelo del queso suizo se vuelve esencial. James Reason desarrolló este modelo para explicar cómo ocurren los accidentes en sistemas complejos. La idea es simple: cada capa defensiva tiene agujeros, como rebanadas de queso suizo. Un accidente ocurre cuando los agujeros se alinean, permitiendo que un peligro pase a través de todas las capas.

Esto requiere un cambio psicológico. Los humanos en general están entrenados para buscar la perfección — la respuesta correcta, la función libre de errores, la especificación completa. La complejidad y la ambigüedad se sienten como fracasos. Pero en la modernización de legado, buscar un único método de validación “perfecto” es una trampa. Conduce a la parálisis por análisis.

Debemos aceptar que cada herramienta y cada capa será imperfecta. La IA malinterpretará alguna lógica. Los datos de prueba perderán un escenario. La ejecución en sombra (shadow run) no logrará capturar un caso extremo estacional. Aceptar esta imperfección no es derrotismo; es la realidad estadística de los sistemas complejos. Al reconocer que ninguna capa individual es confiable, nos vemos obligados a construir resiliencia a través de la redundancia.

En la modernización de legado, el peligro es el comportamiento incorrecto que se desliza a producción. Cada capa de validación atrapa algunos problemas pero pierde otros. La solución no es encontrar la capa perfecta — es apilar múltiples capas imperfectas para que sus agujeros no se alineen.

Capa 1: Análisis de código asistido por IA. Haga que la IA explique lo que hace cada función VBA. Regise su interpretación. Haga preguntas de seguimiento. Construya un modelo mental del sistema.

Capa 2: Captura de entrada/salida. Extraiga ejemplos de cálculo reales del sistema legado. No casos de prueba sintéticos — entradas históricas reales y sus salidas correspondientes.

Capa 3: Pruebas de caracterización. Construya la suite de pruebas en Java que ejecuta su nueva implementación contra las líneas base capturadas. Cada prueba fallida revela una diferencia de comportamiento.

Capa 4: Ejecución en sombra (Shadow running). Despliegue el nuevo sistema junto con el antiguo. Ejecute transacciones reales a través de ambos. Compare las salidas continuamente. Alerte sobre cualquier discrepancia.

Capa 5: Despliegue escalonado con reversión. Procese un subconjunto de transacciones en vivo con el nuevo sistema. Monitoree discrepancias. Aumente el volumen solo cuando la confianza sea alta.

Capa 6: Validación de negocio. Haga que expertos en el dominio revisen muestras de salidas. ¿Tienen sentido los números? ¿Se comportan correctamente los casos extremos? Confíe en su intuición — han estado usando este sistema durante años.

Ninguna capa individual es suficiente. La interpretación de la IA podría perder sutilezas. Las pruebas de caracterización podrían no cubrir casos extremos raros. La ejecución en sombra podría no ejercitar cada ruta de código. Pero apile las seis capas, y la probabilidad de que un defecto significativo llegue a producción cae dramáticamente.

El Resultado de la Transferencia de Conocimiento

Hay un beneficio secundario en este enfoque que a menudo resulta más valioso que la modernización misma: conocimiento explícito.

El VBA legado codificaba las reglas de negocio implícitamente. Nadie podía articular estas reglas sin leer el código. Ahora tiene una suite de pruebas con cientos de ejemplos documentados. Las explicaciones generadas por IA, revisadas y corregidas, se convierten en documentación en prosa. Las pruebas de caracterización se convierten en especificaciones ejecutables.

Cuando el próximo desarrollador se une al equipo, no necesita aplicar ingeniería inversa a un módulo VBA. Puede leer las pruebas. Puede ver exactamente qué entradas producen qué salidas. Puede entender las reglas de negocio a través de ejemplos en lugar de a través de una excavación arqueológica.

Pasos Prácticos para Comenzar

Si se enfrenta a un proyecto de modernización de VBA legado, aquí es donde comenzar:

Inventariar y evaluar. Enumere cada módulo VBA, formulario y macro. Note cuáles son críticos para el negocio versus utilidades de conveniencia. Identifique los componentes de mayor riesgo — aquellos que manejan dinero, cumplimiento o datos de clientes.

Extraer conocimiento con IA. Alimente el código VBA crítico a un asistente de IA. Pídale que explique la lógica de negocio. Use el diálogo en su IDE para documentar hallazgos en un archivo que guiará la investigación adicional. Marque áreas de incertidumbre.

Capturar el oráculo. Ejecute el sistema legado con entradas representativas. Registre cada salida. Construya su conjunto de datos maestro dorado.

Construir el arnés de pruebas. Cree la suite de pruebas en Java. Verifique que ejecutar las entradas capturadas a través del sistema legado produce las salidas capturadas. Esto suena circular, pero valida su proceso de captura.

Reemplazo incremental. Reescriba una función a la vez. Ejecute las pruebas de caracterización después de cada cambio. Las discrepancias son defectos hasta que se demuestre lo contrario.

La clave es la paciencia. Apresurar este proceso invita a las mismas fallas que hacen notoria la modernización de legado. Cada capa de validación toma tiempo para implementar. Ese tiempo es una inversión en confianza.

El Riesgo Real es No Hacer Nada

Las organizaciones a menudo retrasan la modernización de legado porque el riesgo se siente alto. ¿Qué pasa si el nuevo sistema rompe algo? ¿Qué pasa si perdemos funcionalidad? ¿Qué pasa si los clientes notan problemas?

Estas preocupaciones son válidas. Pero deben sopesarse contra el riesgo de no hacer nada. El desarrollador de VBA que mantiene el sistema se está retirando. La plataforma del proveedor se acerca al fin del soporte. Los requisitos de auditoría se están volviendo más estrictos. El negocio está creciendo más rápido de lo que las personalizaciones heredadas pueden manejar.

El riesgo de modernización es visible y manejable. El riesgo de estancamiento continuo es silencioso hasta que se vuelve catastrófico — el día que la aplicación se corrompe, el día que la única persona que la entiende se va, el día que un auditor pide documentación que no existe.

Conclusión

La modernización de VBA legado no es un problema tecnológico. Es un problema de extracción de conocimiento con un requisito de validación que exige defensa en profundidad.

La IA acelera la fase de extracción. Las pruebas en Java proporcionan el marco de validación. El modelo del queso suizo asegura que ningún modo de falla individual pueda comprometer el resultado.

La alternativa — reescribir basándose en suposiciones sobre lo que el sistema debería hacer — es cómo fallan los proyectos de modernización. Resultados idénticos es el único estándar aceptable cuando la continuidad del negocio depende del resultado.

La aplicación que ejecuta su negocio merece algo mejor que esperanza. Merece capas de validación tan robustas que la confianza reemplace a la ansiedad. Comience a construir esas capas hoy.

Artículos relacionados

El Product Manager ha muerto. Larga vida al Product Developer.

27.03.2026

La persona que entra a la reunión con mockups de Figma diciendo 'construyan esto' se quedó sin camino. La IA redujo l...

Desarrollo de Productos en la Era de la IA

23.03.2026

El desarrollo de productos ha cambiado fundamentalmente. La brecha entre tener una idea y verla funcionar solía llena...

Cuando la IA se convierte en tu compañero de pensamiento

20.03.2026

La mayoría de los desarrolladores usan IA como un autocompletado glorificado. El verdadero poder viene cuando dejas d...