Cuando le decimos a un CTO que convertimos PL/SQL a TypeScript, la primera reacción suele ser de temor. “¿Están reescribiendo nuestra lógica de negocio?” No. La estamos traduciendo. La distinción es precisamente el punto.
Una reescritura significa que un desarrollador lee el PL/SQL, forma un modelo mental de lo que debería hacer y escribe código nuevo desde cero. Ahí es donde aparecen los errores. Ahí es donde la exención del GST australiano añadida en 2014 desaparece silenciosamente. Una traducción significa que el sistema lee el PL/SQL, identifica patrones estructurales y emite TypeScript equivalente que implementa un comportamiento idéntico. La lógica sobrevive. El lenguaje cambia. La arquitectura mejora.
Qué cambia
El runtime. PL/SQL se ejecuta dentro de Oracle Database. TypeScript se ejecuta en Node.js o en el navegador. Ese único cambio desbloquea la exposición vía API, el escalado horizontal y el despliegue en contenedores — tres capacidades que el motor de base de datos nunca fue diseñado para proporcionar.
El sistema de tipos. Los tipos de PL/SQL se mapean limpiamente. NUMBER se convierte en number. VARCHAR2 se convierte en string. DATE se convierte en Date. Los tipos record se convierten en interfaces. El mapeo es mecánico, no interpretativo.
El manejo de errores. Las excepciones de PL/SQL se convierten en bloques try/catch estructurados. RAISE_APPLICATION_ERROR se convierte en respuestas de error tipadas con códigos de estado HTTP que los sistemas downstream pueden consumir realmente.
El acceso a datos. El SQL embebido se convierte en llamadas a API. SELECT FROM contractors WHERE... se convierte en this.api.getContractors(filters). La consulta sigue llegando a las mismas tablas de Oracle, pero a través de una capa REST gobernada en lugar de un acoplamiento directo a la base de datos.
Qué permanece igual
Cada regla de validación. Si el PL/SQL requiere un monto positivo, el TypeScript también.
Cada cálculo. Si el PL/SQL calcula el impuesto como amount * rate / 100, el TypeScript realiza la misma aritmética con idéntica precisión.
Cada rama condicional. Si el PL/SQL tiene CASE WHEN status = 'APPROVED' THEN..., el TypeScript lleva la misma estructura condicional.
Cada paso del flujo de trabajo. Si los pedidos superiores a $50K necesitan aprobación del VP antes de que el estado pueda cambiar, el nuevo código aplica la misma restricción. El comportamiento es idéntico porque las reglas son idénticas.
Qué desbloquea la migración
La nueva arquitectura no es solo un cambio de lenguaje. Habilita capacidades que Oracle Forms nunca pudo ofrecer:
- Pruebas unitarias. Cada validación se convierte en una función que puede probarse de forma independiente. Forms hacía que la cobertura de pruebas significativa fuera prácticamente imposible.
- Control de versiones. El TypeScript vive en Git. Cada cambio tiene un commit, un autor y un diff. PL/SQL dentro de archivos .fmb no tenía nada de eso.
- Exposición vía API. La lógica que estaba atrapada dentro de la base de datos se vuelve invocable desde aplicaciones móviles, sistemas de socios o agentes de IA.
- Desarrollo en paralelo. Múltiples ingenieros trabajan en diferentes módulos simultáneamente sin pisarse los archivos mutuamente.
Las advertencias honestas
¿Cada línea se traduce limpiamente? No. Oracle Forms tiene particularidades — commits implícitos, flujo de pantalla dirigido por el navegador, posicionamiento por coordenadas de canvas — que no tienen equivalentes directos modernos. Esas requieren decisiones arquitectónicas durante la migración, y las tomamos deliberadamente.
Pero la lógica de negocio central — las reglas, cálculos, validaciones y flujos de trabajo de los que la empresa realmente depende — se traduce de forma confiable. Las matemáticas son matemáticas. Una restricción sobre un límite de crédito es una restricción sobre un límite de crédito, independientemente del lenguaje que la aplique.