Inventario real
Cuántos formularios hay, cuáles se usan de verdad y cuáles quedaron muertos. En la mayoría de los sistemas, entre el 30% y el 40% de los formularios no se abre hace años: migrarlos sería pagar por nada.
Pasar un sistema Forms 6i, 10g u 11g a Oracle APEX sin frenar la operación, conservando la lógica PL/SQL que ya funciona y sin rehacer el modelo de datos.
El sistema más grande que migré: un organismo público, de Oracle Forms 6i a 11g/12c, con la operación funcionando durante todo el proyecto. El método que describo más abajo — inventario real, olas por módulo y convivencia de los dos sistemas — es el que hizo posible ese plazo.
Un sistema Oracle Forms bien hecho puede llevar quince años en producción sin fallar. Eso no es el problema. El problema aparece alrededor: el navegador dejó de soportar Java, cada puesto nuevo necesita una configuración artesanal, el personal que conocía el código se fue, y cualquier cambio menor se vuelve un proyecto.
La reacción habitual es la más cara: tirar todo y empezar de cero en alguna tecnología de moda. Eso significa volver a escribir años de reglas de negocio que hoy funcionan correctamente, y descubrir en producción las excepciones que el sistema viejo ya tenía resueltas.
Migrar a APEX es el camino intermedio: la base de datos sigue siendo la misma, los packages PL/SQL se conservan y lo que cambia es la capa de presentación, que pasa a ser web, sin plugins ni instalaciones en cada máquina.
El cliente Java ya no correCada actualización del navegador o del sistema operativo rompe el acceso, y mantener una máquina "que funciona" es la solución de todos.
Nadie quiere tocar el códigoLa persona que lo escribió ya no está y no hay documentación. Cada cambio se estima en semanas por miedo, no por complejidad.
Hace falta acceso remotoSucursales, vendedores o proveedores necesitan entrar al sistema y hoy solo se puede desde la red interna.
La versión quedó sin soporteForms 6i y 10g ya no tienen soporte de Oracle: ante un incidente grave no hay a quién reclamar.
Nunca propongo un apagado total. Los dos sistemas conviven contra la misma base de datos hasta que el último módulo esté probado.
Cuántos formularios hay, cuáles se usan de verdad y cuáles quedaron muertos. En la mayoría de los sistemas, entre el 30% y el 40% de los formularios no se abre hace años: migrarlos sería pagar por nada.
Separo qué reglas viven en triggers del formulario y cuáles ya están en packages. Lo que está en la base se conserva tal cual; lo que está atrapado en el formulario se mueve a PL/SQL, donde APEX puede reutilizarlo.
No empiezo por el ABM simple. Empiezo por el formulario con más pantallas, validaciones e impresiones, porque ahí aparecen los problemas reales. Si ese funciona, el resto es volumen.
Módulo por módulo, con los usuarios probando cada entrega sobre datos reales. Forms y APEX trabajan en paralelo sobre la misma base, así que nadie queda sin sistema si algo se atrasa.
Migración de usuarios y permisos, reemplazo de los reportes, capacitación corta al equipo y acompañamiento durante los primeros cierres de mes, que es cuando aparece lo que nadie previó.
WebUtil. Si el sistema abre archivos del disco del usuario, imprime en una impresora fiscal o lee un lector de códigos, eso no se traduce solo. Cada caso necesita su reemplazo: carga de archivos del navegador, generación de PDF desde la base, o un componente aparte.
Los reportes. Oracle Reports suele ser la parte más subestimada. Muchos informes se resuelven con Interactive Reports de APEX, pero los formatos legales o de impresión precisa necesitan otra estrategia, definida antes de arrancar y no sobre la marcha.
Las integraciones. Los sistemas viejos suelen tener conexiones invisibles: un job que exporta a un archivo, una base enlazada, un proceso que otro sector ejecuta cada noche. Buscarlas es parte del relevamiento, no una sorpresa de la última semana.
El rendimiento. APEX corre dentro de la base. Una consulta que tardaba tres segundos en Forms y se llamaba una vez por pantalla puede volverse un problema al mostrarse en una grilla paginada. Ahí entra el trabajo de tuning, que es donde paso la mitad del tiempo.
Depende de la cantidad de formularios activos y de cuánta lógica esté dentro del formulario en vez de la base. Un sistema de 30 a 40 formularios en uso real suele llevar entre tres y seis meses trabajando por olas, con entregas parciales desde el primer mes. El relevamiento inicial, que es lo que permite dar un plazo serio, lleva una o dos semanas.
No. APEX vive dentro de la misma base Oracle, así que el modelo de datos, los packages, las vistas y los permisos se conservan. Si la versión de la base es muy antigua puede hacer falta actualizarla para contar con una versión de APEX moderna, y eso se evalúa al principio.
De a partes, y es lo que recomiendo. Forms y APEX pueden funcionar en paralelo contra la misma base mientras dure la transición: los usuarios van pasando por módulo y el sistema viejo se apaga recién cuando el último quedó probado en producción.
Se revisan uno por uno. La mayoría se reconstruye con Interactive Reports o con salida PDF generada desde la base. Los que tienen formato legal estricto o impresión sobre formularios preimpresos se resuelven aparte, y ese alcance se define antes de arrancar.
Sí. Trabajo con clientes de todo el país en forma remota, y presencial en Tucumán y alrededores cuando el proyecto lo requiere, sobre todo en la etapa de relevamiento y en la puesta en producción.