La conversación sobre SAP Build Work Zone casi siempre empieza mal. Alguien muestra la pantalla nueva, elogia el aspecto, y la decisión se vuelve estética. No lo es. Es un plazo.

SAP Enterprise Portal salió del mantenimiento estándar, y con él el Fiori Launchpad alojado en el portal. Quien tiene un portal heredado no está eligiendo migrar — está eligiendo cuándo. Y la diferencia entre elegir ahora y ser empujado después es cuánto se pierde en el camino.

Qué cambia de verdad

En el portal la unidad era la página: alguien montaba una, colocaba iViews dentro, y la navegación venía de una estructura de carpetas con permiso propio. En Work Zone la unidad es el espacio — un recorte por rol, no por tema — y dentro de él páginas con tarjetas.

Parece un cambio de nombre. No lo es. En el portal el permiso vivía en la estructura de navegación; en Work Zone viene del rol de negocio que asigna el espacio. Quien migró la pantalla sin migrar el modelo de permisos lo descubre el primer día en producción, cuando la mitad de los usuarios ve lo que no debería y la otra mitad no encuentra lo que necesita.

Lo que no cruza solo

Hay cuatro categorías de contenido en el portal heredado, y se comportan de forma muy distinta en la migración.

Aplicaciones Fiori y transacciones SAP GUI cruzan bien. Es el caso feliz: el catálogo ya existe, el destino ya está mapeado, y el trabajo es reorganizar, no reconstruir.

iViews de URL y contenido externo cruzan con ajuste. Se convierten en tarjetas de enlace o aplicaciones web, y lo que suele romperse es la autenticación — lo que funcionaba por sesión del portal ahora tiene que funcionar por token.

iViews Web Dynpro Java son el problema. No hay camino directo, porque el runtime que los ejecuta es del propio portal. Cada uno necesita una decisión: reescribir, sustituir por un estándar SAP o retirar. Aquí es donde revienta el cronograma, y es lo primero que conviene inventariar.

La personalización de tema y marca no cruza. Work Zone tiene su propio motor de temas, y lo que era CSS en el portal hay que rehacerlo en la herramienta nueva.

El orden que evita retrabajo

La secuencia importa más que la herramienta. Quien invierte los dos primeros pasos rehace todo dos veces.

Primero, inventariar lo que existe de verdad. No la lista de páginas del portal — la lista de lo que se usa. El registro de acceso de los últimos seis meses suele revelar que la mitad del portal no la abre nadie desde hace años, y migrar eso es pagar por cargar peso muerto.

Segundo, diseñar los espacios por rol. Antes de tocar ninguna pantalla. El espacio es el recorte de quien usa, no de quien construyó — y esa conversación es con el negocio, no con TI.

Tercero, rehacer el catálogo. Aquí conviene aprovechar para limpiar: un catálogo con diez años de excepciones acumuladas es el momento de racionalizar, porque arrastrar el desorden cuesta lo mismo que ordenarlo.

Cuarto, tratar los Web Dynpro Java uno a uno, con la decisión registrada. Reescribir, sustituir o retirar — y quien decide es el dueño del proceso, no el equipo técnico.

Quinto, correr en paralelo antes de apagar. Portal y Work Zone conviviendo unas semanas, con un grupo real usándolos, es lo que revela lo que el inventario no atrapó.

Dónde la IA ayuda de verdad

No en la migración en sí — es estructural, no interpretativa. Donde rinde es en el inventario: leer la estructura de navegación del portal, cruzarla con el registro de uso y proponer el mapeo inicial de espacios por rol es exactamente el tipo de trabajo voluminoso y repetitivo donde la lectura automática ahorra semanas.

Lo que no hace es decidir qué retirar. Esa decisión tiene dueño, y el dueño es el negocio.

El límite honesto

Work Zone no arregla un proceso malo. Si hoy la aprobación pasa por cuatro personas porque nadie confía en el control, pasará por cuatro personas con una interfaz más bonita. La migración es una buena ocasión para revisar eso — no es la revisión.

Y no es un proyecto de semanas. Un portal heredado con diez años de contenido, tratado con honestidad, es trabajo de meses — la mayor parte en decisión, no en configuración.

En Inove este tipo de migración entra en el mismo diseño de prácticas SAP en el que tratamos roles, catálogo y autorización: lo que decide el plazo no es la herramienta, es cuánto de lo que existe hoy alguien logra decidir retirar.

Preguntas frecuentes