Fin de mantenimiento SAP: la resolución de la UE que cambia las reglas (no las fechas)

SAP

En octubre de 2024 escribí «El fin se acerca», avisando de las fechas del fin de mantenimiento de SAP Business Suite 7 (31 de diciembre de 2027 para el mantenimiento estándar, 2030 para el extendido). Han pasado casi dos años y esas fechas no se han movido ni un día. Lo que sí ha cambiado es todo lo que rodea la decisión de quedarte o no en esa fecha límite.

El fin se acerca

El 9 de julio de 2026 la Comisión Europea cerró su investigación de competencia sobre determinadas prácticas de mantenimiento y soporte de SAP (caso AT.40823), haciendo jurídicamente vinculantes una serie de compromisos ofrecidos por SAP durante los próximos diez años. Es importante ser preciso aquí: no es una declaración de infracción, la Comisión no dice que SAP haya vulnerado la ley, y SAP no lo reconoce. Es una decisión de compromisos (artículo 9 del Reglamento 1/2003), que convierte en obligatorio lo que SAP ha ofrecido para resolver las preocupaciones de competencia.

Qué investigaba la Comisión

La investigación se abrió en septiembre de 2025 y se centraba en cómo SAP gestiona el mantenimiento y soporte de su ERP on-premise. La Comisión identificó cuatro prácticas problemáticas:

  • Obligar al cliente a contratar el soporte de SAP para todo su landscape SAP, sin poder combinar proveedores distintos para partes distintas.
  • Impedir cancelar el mantenimiento de licencias que ya no se usan (el famoso shelfware), obligando a seguir pagando por algo que no se utiliza.
  • Extender de forma sistemática el plazo mínimo inicial de las licencias, plazo durante el cual no se puede cancelar el soporte.
  • Cobrar comisiones de reincorporación y pagos retroactivos (back maintenance) a quien vuelve a contratar soporte tras un periodo sin él, en algunos casos equivalentes a lo que habría pagado si nunca se hubiera ido.

A qué productos aplica

Aquí conviene distinguir dos capas. La decisión de la Comisión se refiere formalmente al ERP on-premise: ese es el objeto exacto del caso AT.40823. SAP, sin embargo, ha anunciado que implementará estos compromisos globalmente para todos sus productos on-premise, no solo el ERP. En la práctica, eso incluye CRM, SRM, HCM y el resto de soluciones de la Business Suite 7, pero conviene tener claro que ese alcance ampliado es una decisión voluntaria de SAP, no una obligación legal impuesta por la Comisión.

Qué se compromete SAP a cambiar

Los compromisos aceptados por la Comisión, y que ya son de obligado cumplimiento, incluyen:

  • Los clientes podrán dividir su landscape SAP en instalaciones comerciales (commercial installations) independientes y elegir un proveedor de soporte distinto, o ninguno, para cada una. Cada instalación comercial debe poder operar como una unidad consistente, con alineamiento entre licencias y sistemas técnicos. Esto no significa que cualquier sistema se pueda separar sin más: SAP distingue entre componentes que no están técnicamente integrados (por ejemplo, determinados escenarios de HCM, BW o SRM), que pueden separarse con mayor facilidad, y otros estrechamente integrados con el core ERP, donde SAP no recomienda la división y donde hacerlo corre por cuenta y riesgo del cliente. La integración técnica real entre productos, detallada en la SAP Note 3776551 (requiere usuario S), es uno de los factores que determina si una separación es viable.
  • Se podrán cancelar licencias y su mantenimiento asociado en casos concretos: productos en fase final de soporte, proyectos de implementación fallidos por responsabilidad de SAP, insolvencia, una reducción de plantilla superior al 10% en dos años, o venta de una parte del negocio. Esto no es un derecho general para deshacerse de shelfware, son supuestos tasados.
  • Mayor acceso a los contratos de métrica única (single-metric), una forma alternativa de calcular las cuotas de licencia y mantenimiento.
  • Clarificación de las condiciones sobre el plazo inicial de las licencias, sin que cada nueva compra reinicie ese plazo. Una división del landscape en varias instalaciones comerciales tampoco reinicia ese plazo.
  • Eliminación de las comisiones de reincorporación y reducción del pago retroactivo, que queda limitado al menor de dos importes: el 50% de lo que se habría pagado durante el periodo sin soporte, o el equivalente a seis meses de cuota.
  • Una estructura interna de resolución de conflictos para cuando un cliente considere que SAP no está aplicando bien estos compromisos.

Esta última estructura es distinta del monitoring trustee, la figura independiente que la Comisión Europea pone para supervisar que SAP cumple los compromisos en general y que le reporta de forma periódica. La estructura interna, en cambio, es un primer cauce para reclamaciones concretas, cliente por cliente, sin tener que acudir directamente a la Comisión.

Lo que todavía no se sabe es cuánta independencia real tendrá esta estructura respecto a la parte comercial de SAP. Y hay un punto especialmente delicado: uno de los supuestos para cancelar licencias es que un proyecto de implementación haya fallado por responsabilidad de SAP. En la práctica, en la mayoría de implementaciones interviene también un partner, y demostrar que la responsabilidad es de SAP y no del partner (o compartida) no va a ser sencillo. Ahí es donde esta estructura interna tendrá que demostrar si funciona de verdad o si se queda en papel.

Lo que esto no cambia

Aquí es donde conviene ser preciso, porque en LinkedIn ya he visto lecturas que van más allá de lo que dice la resolución. Las fechas de fin de mantenimiento (2027 estándar, 2030 extendido) siguen exactamente igual. Esta resolución no es una prórroga, es una regulación de cómo se gestiona el mantenimiento mientras esas fechas siguen vigentes. Y los compromisos se refieren al mantenimiento y soporte de productos on-premise, no regulan el mantenimiento de las soluciones cloud de SAP.

Y hay un matiz importante que conviene aclarar: una vez terminado el mantenimiento oficial de SAP, cada empresa siempre ha podido buscarse la vida (con soporte de terceros o auto-mantenimiento), eso no es nuevo. Lo que cambia de verdad es lo que pasa antes de esa fecha, mientras todavía estás dentro del periodo de mantenimiento activo. Hasta ahora, si querías dejar el soporte SAP antes de tiempo, te encontrabas precisamente con las trabas que investigó la Comisión: las restricciones para separar partes del landscape y contratar distintos proveedores, las limitaciones para cancelar licencias sin usar, la extensión del plazo mínimo con nuevas compras y unas condiciones de reincorporación que podían borrar buena parte del ahorro conseguido. Lo nuevo no es que ahora se pueda vivir sin soporte SAP, eso ya se podía después de la fecha límite. Lo nuevo es que ahora se puede hacer antes de tiempo y sin las penalizaciones que lo hacían inviable en la práctica.

Qué significa para un CIO o un arquitecto

Michael Bloch, responsable de Licencias, Servicio y Soporte en DSAG (la asociación de usuarios SAP de habla alemana), lo resume bien: esto no reduce la presión de decidir, la reordena. El año decisivo sigue siendo 2027, porque es cuando hay que tener claro el landscape de destino. Lo que cambia es que ahora hay más herramientas para llegar a esa decisión sin pagar de más por el camino.

En la práctica, yo empezaría por tres cosas.

  • Primero, una revisión honesta del shelfware: qué licencias se están pagando y cuáles se utilizan realmente. Los compromisos no permiten cancelar libremente cualquier licencia infrautilizada, pero amplían los supuestos y mecanismos con los que reducir ese coste.
  • Segundo, entender que elegir soporte de terceros para una parte del landscape no es una decisión aislada. Hay que analizarla junto con la estrategia contractual y de transformación cloud de la compañía, porque puede cambiar el encaje económico de otros programas o acuerdos con SAP.
  • Tercero, tener en cuenta los plazos si se piensa aprovechar esto de cara a 2027: una solicitud de división del landscape se resuelve en un máximo de seis meses, y el cambio entra en vigor en los cortes trimestrales (1 de enero, abril, julio u octubre), no de forma inmediata. Quien quiera tenerlo listo para la fecha límite no debería empezar a mirarlo en diciembre de 2027.

Mi lectura

Mi mayor duda no es si la resolución es positiva para el cliente (lo es, da más opciones y más transparencia), sino si va a generar el efecto contrario al que busca. Dar más margen para quedarse cómodo en on-premise, con mantenimiento más predecible y flexible, puede convertirse precisamente en el argumento que necesitaba quien ya venía posponiendo la migración a S/4HANA. La fecha límite sigue ahí, pero ahora es más fácil convencerse de que se puede esperar un poco más.

Y sin embargo, creo que hay algo positivo en esto que no debería quedarse en segundo plano. Hasta ahora la decisión sobre on-premise era una olla a presión: o migrabas al ritmo que marcaba SAP, o te quedabas expuesto sin margen real de maniobra antes de la fecha límite. No nace un tercer camino, el soporte de terceros ya existía. Lo que cambia es que ahora puede convertirse en una alternativa económicamente viable para muchos más clientes, sin las penalizaciones que antes lo hacían absurdo. No es ni migrar corriendo ni esperar pasivamente a que se apague la luz en 2027 o 2030, es poder gestionar el mantenimiento on-premise de forma activa mientras se decide con calma.

Referencias

Publicado

Deja un comentario