Una aseguradora europea nos pidió estimar dos caminos para migrar 480 pantallas de Oracle Forms. Una reescritura manual cotizada en 38 meses y 14 desarrolladores. Un traductor automático de código cotizado en 9 meses pero que producía TypeScript que replicaba los triggers WHEN-VALIDATE-ITEM originales línea por línea. Ninguno era aceptable.
Esta es la falsa elección que todo CIO que moderniza Forms hereda. Lento y seguro, o rápido y arquitectónicamente idéntico al sistema del que se intenta escapar.
La falsa elección
Las reescrituras manuales consumen presupuesto y dejan al negocio funcionando sobre el sistema legado durante años. Nuestros datos de migración muestran que la aplicación Forms empresarial promedio tiene entre 200 y 600 pantallas, de 1.500 a 4.000 triggers PL/SQL y una década de reglas de negocio no documentadas. Reescribir eso a mano es un proyecto arqueológico de varios años.
Los traductores automatizados invierten la compensación. Son rápidos, pero tratan el archivo .fmb como la fuente de verdad y emiten sintaxis moderna que preserva cada suposición legada. El resultado compila. También arrastra el mismo acoplamiento, los mismos patrones procedurales y la misma deuda de mantenimiento.
Hay una tercera vía.
Qué hace realmente la migración estructurada
En lugar de traducir código línea por línea, trabajamos a un nivel más alto de abstracción. El pipeline de DEX Elements se ejecuta en tres etapas.
- Analizar cada bloque, trigger, LOV, canvas y procedimiento PL/SQL en la aplicación fuente.
- Extraer la lógica de negocio en una representación intermedia normalizada que llamamos descriptor JSON.
- Generar una aplicación moderna en TypeScript a partir de esos descriptores usando un framework de componentes gobernado.
La representación intermedia no es código. Es una descripción estructurada de lo que hace la aplicación. Esa distinción es todo el punto. La salida es determinista y auditable. La lógica de negocio sobrevive sin heredar la arquitectura legada. Los mismos descriptores pueden apuntar a cualquier framework que soportemos. Y cuando un descriptor cambia, la aplicación en ejecución se actualiza.
Por qué esto importa a las empresas
Para el CTO, la salida es TypeScript estándar que la empresa posee por completo. Sin runtime de proveedor, sin licencias de Oracle en la nueva pila.
Para el equipo de desarrollo, el proyecto generado es un workspace npm normal. Herramientas familiares, despliegue familiar, sin conocimiento especializado de migración requerido para mantenerlo después de que nos vayamos.
Para el negocio, la migración se entrega en meses en lugar de años. El sistema legado funciona en paralelo, y la transición ocurre pantalla por pantalla en lugar de en un solo fin de semana de riesgo.
Para cumplimiento, cada pantalla lleva un descriptor estructurado que funciona como documentación viva. Los registros de auditoría SOX, el acceso basado en roles y la revisión de seguridad viven a nivel del framework en lugar de en decisiones individuales de desarrolladores.
La capa de IA que esto desbloquea
Una vez que una aplicación existe como descriptores JSON, un asistente de IA puede operar sobre ella de forma segura. El modelo no está generando código de formato libre. Está editando un esquema restringido que el framework ya sabe cómo renderizar. La salida es predecible, revisable y reversible.
Eso habilita trabajo que sería imprudente sobre código crudo. Analistas no técnicos modifican pantallas describiendo cambios en lenguaje natural. El sistema responde preguntas sobre su propio comportamiento. Los nuevos módulos se bosquejan a partir de un párrafo de intención en lugar de un épica de Jira.
La migración estructurada no es solo más rápida que una reescritura o más limpia que un traductor. Convierte un proyecto único en una capacidad permanente.