Modernizar Oracle Forms a APEX: estrategia, errores comunes y cómo hacerlo sin detener la operación

Oracle Forms sigue en producción en una cantidad enorme de empresas e instituciones públicas de Latinoamérica. Funciona, los usuarios lo conocen y la lógica de negocio acumulada en veinte años está ahí. El problema no es que falle: es que cada año cuesta más mantenerlo, depende de Java en el cliente, no corre en móvil, y las personas que lo conocen se van. APEX es la salida natural porque vive en la misma base de datos y reutiliza la mayor parte de lo que ya tienes. Esta guía explica cómo abordarlo sin convertirlo en un proyecto de tres años.

Por qué APEX y no “cualquier framework web”

Tres razones prácticas:

1. La lógica ya está en PL/SQL. Un sistema Forms maduro tiene triggers, paquetes y procedimientos en la base de datos. APEX los llama directamente. Reescribir todo en Java o .NET implica reescribir también esa lógica, o exponerla por servicios: el doble de trabajo.
2. Sin costo de licencia adicional. APEX es parte de toda edición de Oracle Database. No hay servidor de aplicaciones que licenciar ni runtime por usuario.
3. Mismo modelo de seguridad. Esquemas, roles y VPD siguen aplicando. La autenticación se integra con LDAP/Active Directory o SSO.

APEX no es la respuesta cuando la empresa decidió salir de Oracle Database por completo. Ahí la conversación es otra.

Fase 1: inventario y clasificación

Antes de abrir el Page Designer, necesitas saber qué tienes. Para cada forma y reporte:

• Nombre, módulo y descripción funcional en una línea.
• Uso real: cuántas veces se ejecuta por mes. En sistemas Forms antiguos, entre el 30 % y el 50 % de las formas no se usan. Esas se descartan, no se migran. Si no tienes métricas, instrumenta el WHEN-NEW-FORM-INSTANCE con un insert a una tabla de auditoría durante dos meses.
• Complejidad: número de bloques, triggers con lógica (no los de navegación), program units locales, uso de HOST, OLE, WEB.SHOW_DOCUMENT, impresión directa.
• Lógica en el cliente: triggers con reglas de negocio dentro del .fmb que no existen en la base de datos. Es lo más costoso de migrar porque hay que extraerla primero.
• Dependencias: reportes asociados, formas que llaman a otras formas, librerías .pll compartidas.

El resultado es una matriz de valor (uso × criticidad) contra esfuerzo (complejidad). Las formas de alto uso y baja complejidad van primero; dan resultados visibles en semanas y entrenan al equipo.

Fase 2: mover la lógica a la base de datos

Este es el paso que decide si el proyecto cuesta 1x o 3x.

Todo lo que esté en triggers de Forms y sea regla de negocio (validaciones, cálculos, flujos de estado) se extrae a paquetes PL/SQL en la base de datos. Los triggers de Forms quedan como simples llamadas. Beneficios:

• Forms sigue funcionando igual durante la transición (llama al paquete en lugar de tener la lógica inline).
• APEX llamará exactamente el mismo paquete. Una sola implementación, probada en producción antes de que exista la primera página APEX.
• Los reportes, integraciones REST y procesos batch también pueden usarla.

Herramientas que ayudan: el Forms2XML de Oracle convierte .fmb a XML y permite buscar triggers con lógica mediante scripts; los Oracle Forms Application Analysis reports (APEX tiene un asistente de migración que los consume) generan el inventario automáticamente. El asistente no genera páginas usables, pero el inventario sí sirve.

Fase 3: diseñar APEX, no copiar Forms

El error más caro es intentar que la pantalla APEX se vea igual que la forma. Forms es un paradigma de bloques maestro-detalle con navegación por teclado y campos densos; la web funciona distinto. Lo que funciona:

Patrón en Forms	Equivalente en APEX
Bloque de consulta + bloque de datos	Interactive Report o Interactive Grid con filtros por columna
Maestro-detalle en una pantalla	Form + Interactive Grid editable en la misma página, o Form maestro con región de detalle
LOV (lista de valores)	Popup LOV con búsqueda, o Select List para listas cortas
Botón “Ejecutar consulta”	Desaparece: el reporte consulta al cargar y filtra en vivo
Navegación con GO_BLOCK/GO_ITEM	Ninguna: la página web no tiene foco de bloque; se rediseña el flujo
CALL_FORM encadenados	Páginas modales (modal dialog) o navegación con parámetros
Validaciones en WHEN-VALIDATE-ITEM	Validations de página que llaman al paquete PL/SQL
Impresión con Reports	APEX con Oracle REST Data Services + plantillas (APEX Office Print, BI Publisher o JasperReports según el caso)

Define una plantilla de aplicación (tema, estilo, estructura de navegación, componentes estándar) antes de migrar la primera forma. Todas las pantallas la siguen. Sin esto, cada desarrollador inventa su diseño y el resultado parece seis sistemas distintos.

Fase 4: convivencia Forms-APEX

El sistema no se migra en un fin de semana. Durante meses, algunos módulos están en APEX y otros en Forms, sobre la misma base. Para que no sea un caos:

• Misma autenticación. Si Forms usa usuarios de base de datos, APEX puede usar el esquema de autenticación de base de datos; si quieres pasar a LDAP/SSO, hazlo primero en APEX y luego en Forms, o mantén un mapeo temporal.
• Navegación cruzada. Desde el menú de Forms se puede abrir una página APEX con WEB.SHOW_DOCUMENT pasando un token; desde APEX se puede abrir Forms por URL con ?config=. No es elegante, pero mantiene al usuario en un solo flujo mientras dura la transición.
• Un solo paquete de lógica. Nunca dos implementaciones de la misma regla. Si corriges un bug, se corrige para ambos.
• Bloqueo de registros. Forms bloquea pesimistamente (SELECT FOR UPDATE al editar); APEX usa bloqueo optimista (compara un checksum al guardar). Si ambos editan la misma tabla, define qué pasa: lo habitual es aceptar el modelo optimista y manejar el conflicto con un mensaje claro.

Fase 5: migrar por lotes, con usuarios reales

Cada lote (4 a 8 formas relacionadas) sigue el mismo ciclo de dos a tres semanas:

1. Reunión de 1 hora con los usuarios del módulo para entender qué hacen realmente (no qué dice la forma).
2. Prototipo navegable en APEX en los primeros 3 días.
3. Ajustes con los usuarios, construcción completa, validaciones y reportes.
4. Pruebas con casos escritos. Datos de producción copiados a un ambiente de pruebas (APEX corre en la misma base, así que un ambiente de pruebas es solo otra base o otro PDB).
5. Despliegue a producción con APEX export versionado en Git. La forma antigua se oculta del menú pero no se borra hasta un mes después.

Un sistema de 40 a 60 formas suele completarse en 4 a 6 meses con un desarrollador y medio, sin detener la operación en ningún momento.

Errores que encarecen el proyecto

• Migrar las formas que nadie usa. Volver al inventario. Descartar es gratis.
• Dejar lógica en Forms “por ahora”. Esa lógica no se puede probar desde APEX y termina duplicada.
• Reportes a última hora. Los reportes de Oracle Reports suelen ser la mitad del esfuerzo real. Inventaríalos desde el día uno y decide la herramienta de salida (PDF, Excel) antes de migrar la primera forma.
• No versionar. APEX exporta a archivos SQL que pueden y deben estar en Git. Sin eso, no hay forma de saber qué cambió ni de volver atrás.
• Un solo workspace para todo. Separa desarrollo, pruebas y producción en bases o PDBs distintos. Desarrollar en producción “porque APEX lo permite” es la forma más rápida de perder datos.
• Olvidar la seguridad. Autorización por página y por componente, protección de URL (session state protection), y revisión con el APEX Advisor antes de cada despliegue.

Qué esperar al final

Un sistema que corre en cualquier navegador y en móvil sin Java en el cliente, con la misma base de datos, la misma lógica PL/SQL probada, versionado en Git, y un equipo interno que lo entiende porque participó en cada lote. La licencia de Forms y el servidor WebLogic dedicado a Forms pueden retirarse al cerrar el último lote.

---

Si tienes un sistema Forms y no sabes por dónde empezar, el inventario y la matriz de priorización son un trabajo de una a dos semanas que te dice cuánto migrar, en qué orden y cuánto cuesta, antes de comprometer presupuesto.