El 31 de diciembre de 2027 termina el mantenimiento estándar de SAP BW 7.5. Queda poco más de un año, y muchas empresas están decidiendo su siguiente paso.
SAP apuesta por SAP Business Data Cloud, con Datasphere como pieza central. Sin embargo, muchas organizaciones prefieren ir con cautela y optar por lo conocido: SAP BW/4HANA. Mantiene la filosofía de BW, aprovecha el conocimiento del equipo y tiene soporte garantizado hasta 2040. Datasphere queda como una evolución posterior o como un proyecto propio, cuando el negocio esté preparado y tenga el reto de un nuevo desarrollo.
Requisitos técnicos de partida
Conversión in-place (sobre el mismo sistema): BW 7.5 SP05 o superior, ya sobre SAP HANA.
Conversión remote o shell (sistema nuevo): desde BW 7.0, con cualquier base de datos.
Revisión de HANA 2.0: la que exija la versión destino de BW/4HANA, que hay que comprobar en el PAM de SAP.
Herramientas necesarias: SAP Readiness Check, BW/4HANA Starter Add-on y Transfer Cockpit.
Estrategia en tres fases
1. Antes de la migración (la clave)
Diagnóstico con el Readiness Check, el análisis de código propio y el uso real de informes.
Limpieza: comprimir cubos, depurar los históricos de cambios de los DSO, vaciar las PSA y eliminar objetos sin uso y restos de flujos 3.x.
Adaptación: rehacer las conexiones DB Connect, pasar las fuentes SAP a ODP, sustituir InfoPaquetes por DTP y corregir rutinas y código Z.
Banco de pruebas: guardar datos e informes de referencia para validar el resultado.
Ensayo completo en un sandbox, copia de producción, para medir la parada real.
2. La migración
Conversión de objetos con el Transfer Cockpit, modo B4H y conversión técnica con SUM.
Secuencia desarrollo → calidad → producción, con una copia de seguridad antes de cada paso irreversible.
3. Después de la migración
Adaptar los informes que desaparecen (plantillas web y BEx Analyzer).
Comprobar con el banco de pruebas que los resultados coinciden.
Conclusión
El éxito no se decide el día de la migración, sino en los meses anteriores. Cada objeto limpiado o adaptado antes es un posible fallo menos, menos horas de proceso y menos ajustes después. Cuanto mejor preparado llegue el sistema, menor será el impacto en el negocio y menor el riesgo de sobrecostes.
La prioridad no es retirar SAP BW de inmediato, sino identificar el producto y las versiones utilizadas, establecer su horizonte real de mantenimiento y determinar qué dependencias deberán conservarse o sustituirse. A partir de ese diagnóstico, la organización puede optar o combinar las siguientes vías: (1) Ganar tiempo mediante mantenimiento extendido, (2) Evolucionar hacia SAP BW/4HANA o (3) Modernizar progresivamente con SAP Business Data Cloud y SAP Datasphere.
La decisión debe basarse en pruebas de transferencia funcional, seguridad, rendimiento y compatibilidad, no solo en la copia de los datos.
Si tu organización dispone de una plataforma SAP BW, es posible que hayas oído que “se acerca el fin de su vida útil”. Antes de tomar una decisión, identifica el producto y las versiones utilizadas, dónde están instalados y qué aplicaciones, procesos e interfaces dependen de ellos.
El fin del mantenimiento no provoca que el sistema deje de funcionar automáticamente. Implica un cambio en la cobertura de soporte, la disponibilidad de correcciones y, según el contrato, el coste y las condiciones del servicio. El impacto concreto depende del producto, la versión, los componentes instalados y las condiciones contractuales.
Fin del mantenimiento: no todas las versiones tienen el mismo horizonte
Debemos distinguir SAP BW NetWeaver independiente, SAP BW/4HANA y las implementaciones BW embebidas sobre SAP ERP ECC o SAP S/4HANA.
SAP BW 7.5 independiente: el mantenimiento principal termina el 31 de diciembre de 2027. Existe una opción de mantenimiento extendido hasta finales de 2030, sujeta a condiciones.
SAP BW/4HANA: SAP establece un horizonte general de mantenimiento hasta 2040. Este horizonte no garantiza que cada versión concreta reciba mantenimiento hasta esa fecha; es necesario comprobar el ciclo de vida de la versión instalada y planificar las actualizaciones correspondientes.
BW Embebido: su horizonte de mantenimiento depende del ciclo de vida del sistema SAP ERP ECC o SAP S/4HANA que lo contiene, por lo que debe comprobarse conjuntamente con el producto y la versión del sistema anfitrión.
SUGERENCIA: Para comprobar posibles actualizaciones de estas fechas, consulta las notas SAP 2741041, 2934895 y 2952947, así como el Product Availability Matrix (PAM) de SAP BW.
Estrategia: asegurar continuidad y definir el destino
Ante el horizonte de 2027 para SAP BW 7.5, la organización debe definir cuanto antes una estrategia que combine continuidad operativa, destino tecnológico, calendario, costes, responsables y criterios de validación.
Las rutas deben evaluarse según el tiempo disponible, el grado de reutilización requerido, el destino tecnológico, el coste de la transición y la capacidad de validar la funcionalidad transferida:
Mantenimiento extendido hasta 2030, como continuidad temporal mientras se ejecuta la transformación.
SAP BW NetWeaver en private cloud edition (PCE), previa comprobación de las condiciones de elegibilidad y cobertura de la oferta. La opción de transición para 2031–2033 está sujeta a requisitos y restricciones específicos; migrar BW a una nube privada no concede por sí solo esa cobertura. Se debe contar con un BW 7.5 SPS24 como mínimo, con base de datos SAP HANA.
Conversión a SAP BW/4HANA, cuando se quiera conservar y evolucionar sobre una arquitectura BW.
Modernización hacia SAP Business Data Cloud / SAP Datasphere, mediante coexistencia o sustitución progresiva de las funciones actuales.
SUGERENCIA: Para definir la hoja de ruta, consulta las versiones actualizadas de las notas SAP 3590297 y 3768400, así como la documentación de SAP Business Data Cloud.
Herramientas: elegir según lo que se quiere trasladar
Si el destino final es SAP Business Data Cloud / SAP Datasphere, SAP ha desarrollado varios mecanismos con objetivos diferentes:
Data Product Generator (DPG): aprovisiona datos desde proveedores BW admitidos hacia el Object Store de SAP Datasphere mediante suscripciones. Cada suscripción identifica el InfoProvider de SAP BW que se replicará en SAP Business Data Cloud, materializa sus datos en una tabla local de SAP Datasphere y, una vez activada, puede ejecutarse cuando sea necesario.
Query Template Generator (QTG): transfiere la semántica admitida de las consultas y sus dependencias, lo que puede reducir parte del esfuerzo de reconstrucción.
BW/4HANA Model Transfer e Import Entities: permiten reutilizar consultas y modelos de soporte procedentes de BW/4HANA.
Shell y Remote Conversion hacia BW Bridge: ambas opciones permiten trasladar determinados modelos y procesos BW. Shell transfiere los metadatos sin los datos existentes, mientras que Remote Conversion incorpora también la transferencia de datos.
Import Entities desde S/4HANA, tablas remotas y Replication Flows: permiten integrar datos y, según el mecanismo, semántica del origen para construir modelos en Datasphere.
Una transferencia técnica correcta no garantiza que se conserve toda la funcionalidad. Por ejemplo, QTG puede omitir funciones no admitidas y el modelo transferido no incorpora automáticamente los cambios posteriores realizados en BW. Además, las transformaciones y las rutinas ABAP requieren un análisis independiente.
BW Bridge permite conservar el procesamiento BW en un entorno cloud, pero no convierte automáticamente esa lógica en procesamiento nativo de SAP Datasphere.
Si se tiene SAP BPC o BW-IP sobre BW 7.5, soluciones de planificación y consolidación, ninguno de estos mecanismos lo traslada. El destino natural es SAC Planning o SAP Group Reporting.
SUGERENCIA: Para profundizar en estos mecanismos, consulta las guías de SAP sobre DPG y QTG, BW Bridge e Import Entities, así como las versiones actualizadas de las notas SAP 3724724 y 3774419.
Plan de transición: validar antes de retirar
El proyecto debería comenzar con un inventario de las versiones de los componentes, las fuentes de datos, las consultas, las cargas, las rutinas, las autorizaciones, las interfaces y las aplicaciones de planificación o consolidación.
Después, conviene probar flujos representativos y comparar cifras, filtros, jerarquías, unidades, procesos delta, controles de seguridad y rendimiento. Si el origen también cambia de SAP ERP ECC a SAP S/4HANA, deben comprobarse individualmente los extractores y el Business Content afectados.
Se debe tener presente que los principales elementos que se “romperán” serán los elementos de SAP Analysis for Office y SAP BusinessObjects o BEx Analyzer, si aun se utiliza. Son los consumidores directos de la consultas BW.
Aplazar esta evaluación puede dejar a la organización con menos margen para resolver incompatibilidades, sustituir interfaces o reconstruir lógicas que no se pueden transferir vía ningún mecanismo conocido.
La retirada del sistema BW original debe producirse únicamente cuando se hayan sustituido y validado sus funciones y dependencias. Una copia de los datos en SAP Datasphere no demuestra por sí sola que la migración haya concluido: también deben verificarse la lógica, la seguridad, el rendimiento y las integraciones.
SUGERENCIA: Por último revisar las versiones actualizadas de la notas SAP 2500202, 2548065 y 3774419.
Cada vez es más estable la compatibilidad de las aplicaciones cliente de la plataforma SAP BusinessObjects BI con fuentes de datos de SAP BW, especialmente con consultas BEx. Pero no todas las herramientas cliente SAP BO BI son compatibles, por igual, con todas las características de estas fuentes de datos.
Cada vez es más estable la compatibilidad de las aplicaciones cliente de la plataforma SAP BusinessObjects BI con fuentes de datos de SAP BW, especialmente con consultas BEx. Pero no todas las herramientas cliente SAP BO BI son compatibles, por igual, con todas las características de estas fuentes de datos.
En la nota SAP de referencia encontraremos un fichero Excel en el que se detalla la compatibilidad de los siguientes clientes de la plataforma Business Intelligence de SAP 4.1 y 4.2: «Universos UNX», «Web Intelligence«, Dashboards, «Crystal Reports Enterprise», «Analysis, edition for OLAP». Adicionalmente, también se incluye la compatibilidad con SAP Lumira (Desktop), «Anlysis, edition for MS Office» y Design Studio.
La arquitectura de todos los componentes o productos SAP, con futuro, vienen siendo revisados y redefinidos para que funcionen utilizando el potencial de SAP HANA Database de la mejor manera. Así, inicialmente fueron introducidos los “aceleradores”, los cuales básicamente replican las tablas más relevantes de una aplicación en HANA, obteniéndose un mejor tiempo de respuesta.
La arquitectura de todos los componentes o productos SAP, con futuro, vienen siendo revisados y redefinidos para que funcionen utilizando el potencial de SAP HANA Database de la mejor manera. Así, inicialmente fueron introducidos los “aceleradores”, los cuales básicamente replican las tablas más relevantes de una aplicación en HANA, obteniéndose un mejor tiempo de respuesta.
Posteriormente hemos venido viendo soluciones “powered by SAP HANA” o simplemente “on SAP HANA”, caracterizadas por llevar, con mínimos cambios, los modelos de datos de las aplicaciones a SAP HANA y por consiguiente, el procesamiento de los datos es ejecutado en memoria obteniéndose importantes mejoras en los tiempos de respuesta.
El cambio más disruptivo que se está dando por SAP HANA es la irrupción de una nueva generación de aplicaciones, las denominadas “edition for SAP HANA”. La cual prescinde de todos los elementos u objetos que tuviese la aplicación original e impiden que sea más eficiente y veloz en SAP HANA. El primero y más relevante representante “edition for SAP HANA” es SAP BW 7.5, del cual destacamos los siguientes cambios:
La clásica interface SAP GUI del denominado Data Warehousing Worbench es sustituida por el denominado BW Modelling tolos in Eclipse.
Las funcionalidades o herramientas para el modelado BW han sido adaptadas en el entorno de modelado SAP HANA. Por el momento, hay algunos objetos que deben ser definidos en el Data Warehousing Workbench.
Algunos objetos ya no son soportados y serán sustituidos por uevos tipos de objetos especialmente diseñados para SAP HANA. En este enlace puedes ver estos cambios: aquí.
SAP Business Explorer (BEx) ya no será soportado nunca más (esto ya lo han dicho más de alguna vez. :-I). Las consultas o queries serán definidas con las herramientas de modelado BW de SAP HANA. Para la visualización de datos se recomienda el uso de Analysis for Office o Design Studio (o SAP BusinessObjects Lumira).
La fuerza de la costumbre nos lleva a seguir utilizando términos que no son los adecuados, el caso más recurrente en el mundo SAP es el de BI, acrónimo de Business Intelligence, muchas veces utilizado cuando se desea referir a Business Warehouse (BW).
La fuerza de la costumbre nos lleva a seguir utilizando términos que no son los adecuados, el caso más recurrente en el mundo SAP es el de BI, acrónimo de Business Intelligence, muchas veces utilizado cuando se desea referir a Business Warehouse (BW).
Cuando se habla de análisis de datos, se debe diferenciar la capa de los datos de la capa de visualización y presentación de la información. La capa de datos para el análisis, por mucho tiempo, era solo un repositorio central o data warehouse, el cual agrupa y consolida la información de distintas fuentes. Hoy por hoy, las capas de datos puede ser la base de datos de distintos sistemas transaccionales, ficheros de datos o medios/redes sociales, sin la necesidad imprescindible de utilizar un almacén de datos.
SAP denominó a su plataforma de análisis de datos como SAP Business Intelligence, la cual contenía inicialmente SAP Business Warehouse como repositorio central y los componentes de SAP Business Explorer (BEx) para la presentación de información. Pasado los años y desde la llegada de Business Objects, SAP ha tratado de corregir esta situación, un ejemplo es la nota 2348720, la cual señala lo siguiente:
Formerly, SAP Business Warehouse was temporarily called SAP Business Intelligence and was referenced to as ‘SAP BI’. The ‘BI’ (Business Intelligence solutions) component in the support launchpad is used for SAP BusinessObjects Business Intelligence products (eg. SAP BusinessObjects Business Intelligence Platform, Design Studio, Lumira, Roambi, Crystal Reports, Dashboard, Web Intelligence) and is not related to SAP Business Warehouse.
Pero será difícil no encontrarnos con expresiones tales como “se busca experto en SAP BI” o “los datos están en BI” cuando sólo se refieren a SAP BW.
