Una CDS, cuatro miradas: el reporting de SAP Group Reporting… y casi cualquier otra fuente de SAP


Quien oye hablar de SAP Group Reporting por primera vez suele imaginar una batería de informes y consultas listas para usar. No es así. SAP Group Reporting es la herramienta de S/4HANA que automatiza el proceso de elaboración de los Estados Financieros consolidados.

El estándar incluye las CDS del modelo de datos virtual (VDM) sobre las que se construye el reporting. Estas CDS se pueden ampliar, o tomarse como base de otras nuevas, para incorporar dimensiones o datos maestros adicionales, estándar o custom. Las Best Practices y la instalación estándar aportan además algunos libros de Analysis for Office y varias aplicaciones Fiori. Pero todo esto no basta para cubrir el reporting básico que se pide en cualquier implantación o, simplemente, nada de eso resulta útil en la mayoría de las circunstancias.

NOTA: CDS (Core Data Services): Es una definición lógica de los datos y de su semántica (qué representan, cómo se relacionan y cómo se consumen). No almacena datos: el sistema la traduce a lenguaje SQL y ejecuta estas instrucciones directamente en la capa de la base de datos.

Alternativas para el reporting

En nuestra opinión, hay cuatro vías para cubrir los informes y las visualizaciones de los datos de consolidación (también aplicable sobre cualquier otra fuente SAP).

HerramientaFacilidad de usoCapacidad gráficaIntegración con ExcelNavegación por jerarquíasUso recomendado
SAP Analysis for Office●●●●●●○○○○●●●●●●●●●●Análisis operativo y conciliaciones
Aplicaciones Fiori●●●○○●●○○○●●●○○●●●●○Consulta rápida integrada en S/4HANA
SAP Analytics Cloud (Live)●●●○○●●●●●●●○○○●●●●●Informes de dirección, semestrales y anuales
Web Intelligence●●●●○●●●●○●●●●○●●●○○Informes formateados y distribución masiva
Herramientas no SAP (Power BI, Tableau…)●●●○○●●●●●●●●○○●○○○○Solo como referencia: suelen manejar mal todo tipo de jerarquías SAP
Escala de 1 a 5, según nuestra experiencia.

Nota: no se incluye SAC con Import Connection. Salvo que haya que combinar los datos de GR con otras fuentes, realizar cálculos complejos o que exista un problema de rendimiento por una granularidad elevada (número de dimensiones utilizadas), no se justifica replicar los datos en distintas plataformas.

Analysis for Office (AfO). Se adopta con facilidad porque funciona sobre Excel. Si defines jerarquías, se navega muy bien por ellas. Es práctico e inmediato. Tiene gráficos, pero de calidad limitada.

Aplicaciones Fiori. El estándar incluye varias aplicaciones analíticas basadas en consultas CDS, como Group Data Analysis, con y sin reglas de reporting. Para tus propias consultas, defines la CDS de tipo query y la localizas con el Explorador de consultas (Query Browser). Desde ahí la ejecutas y puedes crear un tile o mosaico en el Launchpad de Fiori, con acceso similar al de cualquier otra aplicación Fiori. Los gráficos son limitados y los datos se pueden exportar a Excel.

SAP Analytics Cloud. Hay que distinguir entre Live Connection e Import Connection.

  • Live: consume la misma query que AfO y Fiori, así que el modelo de datos y las jerarquías se comportan igual, con mucha agilidad. El rendimiento depende de la CDS, por lo que es recomendable diseñar una específica para SAC con las dimensiones, medidas y textos estrictamente necesarios.
  • Import: obliga a replicar el modelo, los datos y las jerarquías, lo que duplica el esfuerzo de construcción y mantenimiento.

La calidad gráfica es muy superior a la del resto. En cambio, es poco práctico para analizar al detalle la operativa de la consolidación. Encaja mejor en informes semestrales o anuales, donde pesan más los gráficos que las tablas.

Web Intelligence. Es la alternativa en la que menos se piensa hoy, pero es viable. La versión BI 2025 mejora la conectividad BICS, que permite consumir las consultas de CDS, e incorpora gráficos nuevos y más opciones de exportación. En formato de informe y exportación a Excel, WebI no tiene rival.

Una única fuente

Las cuatro vías pueden convivir en la misma implantación y usar la misma fuente lógica: una CDS de tipo query. No hace falta replicar los datos en BW, SAC o Datasphere (salvo que exista la necesidad de ampliar o complementar la información).

Al activar la CDS, el sistema genera una query transitoria con el prefijo 2C más el nombre de su SQL view. Por ejemplo, si defino una CDS con el nombre ZGR_CONSO_MAT_10_SAC y el identificador de SQL view ZCCSMAT10SAC, se genera la query 2CZCCSMAT10SAC. Se llama transitoria porque no se persiste, es decir, no existe como un objeto físico, el motor analítico la construye al vuelo a partir de la CDS.

  • Fiori la localiza por el nombre de la CDS.
  • AfO, SAC Live y Webi la consumen por su nombre 2C*.

Por debajo, todas estas herramientas ejecutan exactamente la misma consulta.

Cómo viaja el dato: cinco capas

  1. Presentación. Fiori, SAC, AfO o WebI muestran los datos y permiten navegar por ellos. Pueden añadir cálculos propios, como fórmulas en WebI, medidas calculadas en SAC o miembros locales en AfO, pero la lógica principal de la consulta la resuelve el motor analítico.
  2. Protocolo. Transporta la petición: de tipo InA (HTTP y JSON) para Fiori y SAC, y de tipo BICS (RFC) para AfO y WebI.
  3. Motor analítico (BW embebido). Ejecuta la query 2C*: jerarquías, agregaciones, cálculos, variables y autorizaciones.
  4. ABAP CDS. Es el modelo semántico: la CDS de tipo query definida sobre otra CDS de tipo cube, en este ejemplo I_MatrixConsolidationReportC. Solo contiene definiciones, no datos.
  5. Base de datos (HANA). Lee físicamente los datos a través de las vistas SQL encadenadas hasta la tabla ACDOCU.

Aviso práctico: no cambies el sqlViewName de una CDS en uso. Al cambiarlo cambia el nombre 2C*, y se rompen los libros de AfO y los modelos de SAC que apuntan a él.

Si el dato no necesita transformaciones ni combinarse con otras fuentes, la CDS es la mejor alternativa.

Conclusión

El reporting no viene resuelto con SAP Group Reporting: hay que diseñarlo. La clave no es elegir una herramienta, sino diseñar bien las CDS de tipo query desde el inicio, según lo que requiere el proyecto. Con una CDS sólida, se puede proponer una herramienta según el perfil del usuario:

  • El consolidador, AfO;
  • El controller, Fiori;
  • La dirección, SAC;
  • La distribución, Webi.

Y todos consultan la misma fuente.

Este enfoque no es exclusivo de SAP Group Reporting: cualquier dato de S/4HANA expuesto mediante una CDS de tipo query puede seguir el mismo camino.

SAP PaPM, ese gran desconocido, héroe del reparto


¿Cómo repartimos los costes y cómo explicamos la rentabilidad? Ante esta necesidad, seguro que inmediatamente, pensamos en una solución a medida con ABAP, BW o, más recientemente, Datasphere o SAC.

Hay otra opción que conviene valorar: SAP Profitability and Performance Management (PaPM). Es una aplicación para modelar cálculos y procesos de negocio complejos, con funcionalidades específicas de asignación de costes y análisis de rentabilidad. Su alcance incluye también escenarios fiscales y de precios de transferencia operativos (los importes que unas sociedades de un grupo cobran a otras por productos o servicios).

Un ejemplo: repartir los costes centrales de una constructora entre sus proyectos según empleados, insumos, maquinaria o servicios consumidos, y analizar cómo cambia el margen de cada uno.

No es un producto nuevo. La versión 1.0 salió en 2015 y la 3.0 en 2018 (versión vigente en on-premise). Además, toma el relevo funcional de SAP BusinessObjects Profitability and Cost Management (PCM) en costes y rentabilidad, incluido el cálculo basado en actividades. PCM 10.0 está en mantenimiento específico de cliente desde enero de 2024, y SAP recomienda PaPM como alternativa. Incluso proporciona contenido para migrar reglas de PCM a PaPM.

¿Qué opciones existen hoy?

  • PaPM 3.0 on-premise (add-on NXI 300): se instala sobre NetWeaver 7.50, S/4HANA, BW/4HANA o ERP 6.0 EHP8, siempre sobre SAP HANA Database. Su mantenimiento sigue al de la plataforma que lo contiene.
  • PaPM Cloud: disponible desde 2021, ofrece dos aplicaciones de modelado: Standard Model, orientado a repartos con grandes volúmenes, y Universal Model, que requiere una activación específica.

On-premise sigue evolucionando. La SP28, publicada en septiembre de 2026, incorpora un Runtime Analysis Cockpit, nuevos tipos de particionado (Hash y Hash-Range), soporte de CDS View entities en conexiones y carga masiva de instancias de proceso desde Excel.

Sin embargo, el roadmap concentra las innovaciones más destacadas en Cloud, con fuerte apuesta por la IA. Está previsto, por ejemplo:

  • Asistencia en el mantenimiento de reglas de derivación en Universal (Q4 2026).
  • Asistencia en la configuración de funciones de reparto en Standard (Q2 2027).
  • Un LLM entrenado por SAP para este dominio (Q3 2027).

Son funcionalidades previstas y sujetas a cambios.

Alternativas SAP y no-SAP

Dentro de SAP, según la complejidad de los requisitos, existen alternativas con alcances distintos: Universal Allocation en S/4HANA y los repartos de SAC Planning. También pueden construirse soluciones a medida con ABAP, BW, SAC o Datasphere. En ese caso, hay que valorar bien su coste de diseño y mantenimiento.

Fuera de SAP destacan Oracle Enterprise Profitability and Cost Management y CCH Tagetik Profitability Analysis, ambas con capacidades específicas de asignación de costes y análisis de rentabilidad.

Antes de desarrollar otro reparto a medida, contrasta tus reglas, volúmenes y necesidades de trazabilidad con las soluciones disponibles. Y pregúntate: ¿la solución propuesta ayudará a explicar el negocio hoy y mañana?

Fuentes oficiales

La nube puede esperar; el mantenimiento de tus sistemas SAP on-premise, no

La migración a la nube no elimina la necesidad de mantener actualizados nuestros sistemas SAP on-premise. Fechas de mantenimiento de S/4HANA, BW/4HANA y ECC.


Toda la atención parece estar en las soluciones cloud de SAP. Mientras hablamos de nuevas plataformas y proyectos de transformación, nuestros sistemas on-premise siguen necesitando atención regular.

Tener prevista una migración a la nube no elimina esa necesidad. Hasta completar la transición, esos sistemas siguen soportando operaciones, cierres financieros y procesos de negocio.

¿Por qué mantenerlos actualizados?

Las actualizaciones incorporan correcciones de errores y de seguridad. SAP publica notas de seguridad el segundo martes de cada mes y recomienda aplicar Support Package Stacks al menos una vez al año. Los parches críticos requieren una evaluación específica según su urgencia y aplicabilidad.

Pero actualizar también exige comprobar compatibilidades. Si utilizamos un add-on, una solución sectorial o un componente específico, debemos verificar que sea compatible con la versión y el stack de destino. La revisión debe incluir dependencias técnicas, integraciones y pruebas de los procesos afectados. La Product Availability Matrix (PAM), Maintenance Planner y las notas de versión son referencias esenciales.

¿Dónde estamos con las principales plataformas?

  • SAP S/4HANA: estar en S/4HANA no garantiza mantenimiento indefinido. Desde la versión 2023, cada release tiene siete años de mantenimiento estándar (la 2023, hasta finales de 2030). El compromiso hasta 2040 exige ir evolucionando entre versiones.
  • SAP BW/4HANA: el mantenimiento estándar de 2.0 terminó el 31/12/2025; el de 2021 finaliza el 31/12/2027 y el de 2023, el 31/12/2030. La siguiente versión planificada es BW/4HANA 2027, prevista para noviembre de 2027.
  • SAP BW 7.5 y NetWeaver 7.5: mantenimiento estándar hasta el 31/12/2027, con ampliación opcional hasta 2030.
  • SAP ERP 6.0/ECC: las versiones sin EHP y con EHP1–EHP5 terminaron su mantenimiento estándar el 31/12/2025. EHP6, EHP7 y EHP8 lo mantienen hasta el 31/12/2027, con ampliación opcional y de pago hasta el 31/12/2030. Pasar de EHP7 a EHP8 no amplía esas fechas.

Conviene revisar dos cosas por separado: si la versión sigue en mantenimiento y si la instalación incorpora las actualizaciones necesarias.

Antes de cerrar el próximo presupuesto o calendario de proyectos, revisemos el inventario de versiones, los parches pendientes y las compatibilidades. Asignemos responsables y ventanas de pruebas y actualización.

La estrategia cloud también debe contemplar cómo mantenemos los sistemas que nos llevan hasta ella.

Anexo 1. SAP S/4HANA: versiones y mantenimiento

VersiónRelease S4CORELanzamientoFin mant. estándarFin mant. ampliado opcional
1511100201531/12/2020—
1610101201631/12/2021—
1709102201731/12/202231/12/2025
1809103201831/12/202331/12/2025
1909104201931/12/202431/12/2025
2020105202031/12/2025—
2021106202131/12/2026—
2022107202231/12/2027—
2023108202331/12/2030—
2025109202531/12/2032—
«—»: sin ampliación general confirmada. Versiones on-premise; Public Edition sigue otro calendario. SAP Safekeeper: servicio de pago solo para clientes RISE with SAP (1503, 1605 y 1709–2020, desde el 01/01/2026, máximo 27 meses por release).

Anexo 2. SAP BW/4HANA: versiones y mantenimiento

VersiónRelease DW4CORELanzamientoFin mant. estándarFin mant. ampliado opcional
1.0100201631/12/2021—
2.0200201931/12/2025—
2021300202131/12/2027—
2023400202331/12/2030—
2027 (planificada)PendienteNov 2027 (previsto)Dic 2034 (previsto)—
Fechas de BW/4HANA 2027 sujetas a cambio. El compromiso con la familia hasta 2040 no amplía el mantenimiento de cada versión instalada.

Anexo 3. SAP ERP 6.0 / ECC: versiones y mantenimiento

VersiónRelease SAP_APPLFin mant. estándarFin mant. ampliado opcional
ERP 6.0 sin EHP60031/12/2025—
ERP 6.0 EHP160131/12/2025—
ERP 6.0 EHP260231/12/2025—
ERP 6.0 EHP360331/12/2025—
ERP 6.0 EHP460431/12/2025—
ERP 6.0 EHP560531/12/2025—
ERP 6.0 EHP6606 (616 on HANA)31/12/202731/12/2030
ERP 6.0 EHP761731/12/202731/12/2030
ERP 6.0 EHP861831/12/202731/12/2030
La ampliación de EHP6–EHP8 hasta 2030 requiere contratación adicional (+2% sobre la base de mantenimiento). ERP 6.0 sin EHP y EHP1–EHP5 pasaron a mantenimiento específico del cliente.

Referencias

  1. SAP News – New SAP S/4HANA Release and Maintenance Strategy
  2. SAP News – SAP Aligns Mainstream Maintenance Commitments
  3. SAP – SAP BW/4HANA 2023 FP04 What’s New (junio 2026)
  4. SAP Support – Maintenance strategy S/4HANA y Business Suite 7
  5. SAP Support – Support Package Stacks
  6. SAP Support – Support Package Stack Strategy
  7. SAP Support – SAP Security Notes / Patch Day
  8. SAP Support – SAP Product Versions
  9. SAP Product Availability Matrix (PAM)
  10. SAP Maintenance Planner

De SAP BW 7.5 a SAP BW/4HANA, la otra opción: claves para una buena estrategia de migración


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.

SAP BusinessObjects BI 2025, 2027, 2029,…


SAP BusinessObjects no ha «muerto»: SAP mantiene la plataforma on-premise con versiones nuevas cada dos años y un compromiso de mantenimiento hasta, al menos, finales de 2031. Lo que sí termina es BI 4.3: su mantenimiento estándar acaba el 31 de diciembre de 2026. La cuestión no es necesariamente abandonar BO: también puedes actualizarlo y contar con nuevas funcionalidades y soporte asegurado. Y si actualizas, el momento es ahora y el destino, BI 2025.

BO no ha «muerto»: solo hay que actualizarlo

Durante años se ha especulado sobre el final de BusinessObjects. La realidad es la contraria: SAP sigue invirtiendo en la plataforma on-premise y ha fijado una hoja de ruta larga.

  • BI 2025 está disponible desde el 12/03/2025.
  • BI 2027 está prevista para el primer trimestre de 2027, y BI 2029 dos años después.
  • SAP garantiza mantenimiento estándar hasta, al menos, finales de 2031.
  • Web Intelligence, los universos .unx, Crystal Reports y la plataforma BI concentran la inversión: son los componentes más usados.

Lo que se acaba es una versión concreta, BI 4.3:

  • Fin del mantenimiento estándar: 31/12/2026 (Nota SAP 3763590).
  • Desde el 01/01/2027 entra en Customer-Specific Maintenance (CSM). Sin corrección de errores ni nuevas actualizaciones; solo parches de seguridad de severidad alta y muy alta durante 2027 (Nota SAP 3486924).
  • Los Support Packages 1 a 4 de BI 4.3 ya están fuera de soporte y SP5 hasta el 31 de diciembre de 2026. SAP recomienda pasar a BI 2025.

Actualizar no es cambiar de herramienta. Es mantener la misma plataforma, los mismos informes y los mismos usuarios con soporte asegurado y acceso a nuevas funcionalidades. La alternativa, seguir en BI 4.3 a partir de 2027, es operar una plataforma crítica sin corrección de errores y con cobertura de seguridad limitada.

¿Por qué no esperar a BI 2027?

Esperar a BI 2027 obliga a operar varios meses sin ganar nada a cambio. Según el PAM, BI 2027 figura como «Not yet available», con disponibilidad estimada en el primer trimestre de 2027 y mantenimiento estándar hasta el 31/12/2029. BI 2025 tiene mantenimiento estándar hasta el 31/12/2027.

Calendario de mantenimiento de SAP BusinessObjects: BI 4.3 hasta 31/12/2026, CSM en 2027, BI 2025 hasta 31/12/2027 y BI 2027 hasta 31/12/2029
BI 2025 ya cubre todo 2027; esperar a BI 2027 deja la plataforma varios meses solo con el CSM de BI 4.3.
  • Meses sin corrección de errores. Desde el 01/01/2027 hasta terminar un proyecto de actualización a BI 2027, la plataforma estaría en CSM.
  • El esfuerzo está en salir de 4.3, no en la versión de destino. Java 17, Tomcat como único servidor de aplicaciones, nueva licencia y componentes eliminados: ese trabajo es el mismo para BI 2025 que para BI 2027.
  • El salto de BI 2025 a BI 2027 será menor. Desde BI 2025, SAP publica versiones cada dos años, sin Support Packages intermedios y con Patches acumulativos cada 6-8 semanas.
  • Estabilidad. Las primeras versiones de una release necesitan maduración. BI 2025 lleva en el mercado desde marzo de 2025 y acumula más de diez Patches.
  • BI 2027 consolida la estrategia de BI 2025. SAP anticipa que BI 2027 solo admitirá Tomcat (PAM BI 2025): quien ya esté en BI 2025 sobre Tomcat llegará preparado.

La recomendación es actualizar ahora a BI 2025 y planificar BI 2027 cuando esté estabilizada.

Principales características de BI 2025

BI 2025 renueva sobre todo Web Intelligence y el BI Launch Pad.

ÁreaNovedadQué aporta
Web IntelligenceNuevos elementos de informe (widgets) generados en el navegadorTabla con scroll y micro-gráficos, más de 20 tipos de gráfico, celdas de texto enriquecido e imagen
Web IntelligenceFiltros integrados en el documentoCalendario, rango de fechas, slider, lista, combo, toggle y botones mostrar/ocultar
Web IntelligenceFormato WIDX (Web Intelligence Document eXtract)Informe interactivo sin conexión: sin instalación, sin login y sin licencia adicional. Exportable, programable y publicable
Web IntelligenceTooltip personalizadoMuestra contenido del informe filtrado por el valor seleccionado
Web IntelligenceData Mode y exportaciónTransformaciones con fórmula, variables de cubo, Right Join; exportación de cubos a Excel y CSV
BI Launch PadKPI TilesPartes de informes ancladas en la página de inicio: 5 por usuario, hasta 10 configurables
BI Launch PadUsabilidadColumnas configurables, último acceso visible, temas Horizon, opción de ocultar el grupo Everyone al enviar
AdministraciónControl desde la CMCPreferencias de usuario gobernadas por el administrador, límites de favoritos y recientes
AdministraciónSeguridadTrusted Authentication por URL autorizadas, sin shared secret; test del Authorization Server
AdministraciónAutomated Merge ToolBackup y restauración de la configuración de la capa web en cada upgrade
PlataformaBase técnicaJava 17 (SapMachine), Tomcat 9, Windows Server 2022/2025.
ConectividadFuentes de datosDatabricks vía OAuth, MongoDB BI Connector, PostgreSQL 16, Oracle 23ai; consultas directas a cubos de Analysis Services y Essbase

También cambia el ciclo de entrega: una versión cada dos años y Patches acumulativos cada 6-8 semanas, sin Support Packages.

Consideraciones antes de actualizar

La actualización es sencilla si se revisan antes siete puntos.

  1. Sistema operativo. BI 2025 solo se certifica en Windows Server 2022 y 2025, de 64 bits.
  2. Actualización directa o máquina nueva. Desde cualquier BI 4.3 SPx se puede actualizar sobre la misma máquina, sin SP mínimo. Este camino conserva el repositorio CMS, los CUID, los permisos y la configuración. Con una máquina nueva hay que transportar el contenido con Promotion Management, recrear servidores y APS, y crear una base de datos de auditoría nueva.
  3. Componentes eliminados. Inventariar antes del cambio lo que desaparece en BI 2025 (Nota SAP 3560025): universos .unv y Universe Design Tool, universos multi-fuente; Analysis edition for OLAP, Live Office, Crystal Reports for Enterprise, BI Mobile; Query y Document as a Web Service, integración con SharePoint; WACS y SAP NetWeaver como servidor de aplicaciones (Nota SAP 3581113).
  4. Nueva licencia. Las claves de BI 4.x no son válidas en BI 2025 (Nota SAP 2282189). Hay que solicitarlas en SAP for Me antes de la ventana; sin ellas, parte de los servidores queda deshabilitada (no significa un coste adicional).
  5. Java 17 y autenticación. BI 2025 pasa de SAP JVM 8 a SapMachine 17. Conviene validar los desarrollos con SDK y la autenticación Kerberos.
  6. Copias de seguridad. Copia del host y backup de la base de datos del CMS y de la auditoría en el mismo momento, con los servicios detenidos, además del File Repository y de la configuración web.
  7. Orden y pruebas. Antes de dar por cerrado el cambio, probar un conjunto representativo de informes: refresco, prompts, programaciones, publicaciones y enlaces OpenDocument.

Un último detalle: evitar BI 2025 Patch 8, afectado por una incidencia de comunicación del clúster CMS (Nota SAP 3724948), y aplicar siempre el último Patch disponible.

Conclusión

BusinessObjects tiene recorrido hasta, al menos, 2031. Quedarse en BI 4.3 a partir de 2027 es asumir riesgo sin beneficio; actualizar a BI 2025 ahora asegura soporte, desbloquea WIDX (visualizar documentos WebI sin conexión en un navegador Chrome), los nuevos widgets y los KPI Tiles, y deja la plataforma preparada para BI 2027.

Referencias