El mantenimiento de SAP ECC termina el 31 de diciembre de 2027: una subida de precio, no un apagón

El 31 de diciembre de 2027, SAP pone fin al mantenimiento estándar de SAP ECC 6.0 y de las demás aplicaciones principales de SAP Business Suite 7. El 1 de enero de 2028 no se apaga nada. Tu sistema sigue funcionando, tus usuarios siguen contabilizando facturas y SAP te seguirá vendiendo soporte. Lo que cambia es cuánto pagas por él y qué recibes.

La distinción importa, porque muchos de los consejos que circulan tratan 2027 como un precipicio. Para la mayoría de las empresas que siguen en ECC no lo es, y lo saben: el grupo más numeroso de usuarios de ECC que quedan planifica para 2030. El riesgo real es otro. El trabajo que de verdad decide la fecha (el ABAP a medida, las interfaces, los datos) se dimensiona tarde, y 2030 resulta tan justo como lo era 2027.

Esto va dirigido a los CIO y a los responsables de SAP de empresas medianas, la mayoría en mercados germanohablantes, que siguen con ECC y tienen que decidir cómo serán los próximos tres años.

A qué se ha comprometido realmente SAP

Las condiciones están en la página de estrategia de mantenimiento de SAP y se anunciaron por primera vez en febrero de 2020:

• Hasta el 31 de diciembre de 2027: mantenimiento estándar para las aplicaciones principales de Business Suite 7, SAP ERP 6.0 entre ellas, sobre los tres últimos enhancement packages. Si tu sistema está en un enhancement package anterior, revisa la SAP Note 2881788 (enlazada desde esa página) antes de construir un plan sobre la fecha de 2027.
• Del 1 de enero de 2028 al 31 de diciembre de 2030: mantenimiento ampliado opcional, con «una prima de dos puntos porcentuales sobre la base de mantenimiento». Dicho de forma sencilla, la tasa de mantenimiento que pagas hoy sube dos puntos.
• Si no contratas el mantenimiento ampliado: pasas automáticamente al mantenimiento específico del cliente. Lo que cubre se describe en la SAP Note 52505, enlazada desde la misma página. Léela antes de dar por hecho que basta.
• Para S/4HANA: SAP se ha comprometido a dar mantenimiento hasta finales de 2040.

Hay otra vía para un grupo más reducido. En agosto de 2025, SAP presentó la SAP ERP, private edition, transition option: una suscripción de duración limitada que lleva ECC de 2031 a 2033 dentro de la nube privada de SAP. Las condiciones son estrictas. «Los sistemas deben migrarse a SAP ERP, private edition sobre SAP HANA antes del 31 de diciembre de 2030.» HANA es la única base de datos admitida, la opción solo se ofrece junto con el plan max success para 2031 a 2033, y SAP fija un mínimo de 2 TB para los sistemas suscritos con ella. SAP dice que está pensada para «nuestros clientes de SAP ERP más grandes y complejos». Las «condiciones comercialmente equivalentes» que ofreció SAP eran para los clientes que se comprometieron con la private edition antes de finales de 2025.

Elijas el nivel que elijas, hazle una pregunta por escrito a SAP y a tu partner: qué cambios legales (fiscalidad, nóminas, formatos de facturación electrónica) seguirán llegando a tu sistema ECC, y hasta cuándo. Para una empresa alemana, esa respuesta por sí sola puede decidir si quedarse donde está es viable.

Qué está haciendo el resto del mercado

DSAG, la asociación de usuarios de SAP de habla alemana, elaboró su Investment Report 2026 con 198 participantes entre el 8 de diciembre de 2025 y el 21 de enero de 2026. De ellos, el 54% sigue con ECC o con la antigua Business Suite, frente al 68% en 2024.

En cuanto a los plazos, casi la mitad de los participantes prevé pasar a S/4HANA antes de finales de 2030, lo que, como señala DSAG, supone pagar el mantenimiento ampliado. Otro 37% quiere hacer el cambio antes de finales de 2027, y solo un 4% apunta a 2033 y a la transition option de la private edition.

El presidente de DSAG, Jens Hungershausen, explicó los motivos sin rodeos: la escasez de perfiles, los proyectos de transformación en paralelo y los presupuestos limitados están retrasando los calendarios, «aunque eso suponga mayores costes de mantenimiento».

Los compradores públicos también se mueven. Nuestro propio recuento de anuncios de licitaciones públicas de la UE da unos 200 procedimientos de migración a S/4HANA por semestre a lo largo de 2025 y 2026, y más de 300 en 2026 a principios de octubre, la mayoría en Alemania. El trabajo se está haciendo. Se reparte en un horizonte más largo de lo que sugieren los titulares sobre 2027.

Dónde está realmente el trabajo

La conversión técnica de ECC a S/4HANA está bien respaldada por herramientas de SAP y de sus partners. Si tienes un ECC poco personalizado con un puñado de interfaces estándar, tu integrador lo ha hecho muchas veces y la mayor parte de lo que sigue no es problema tuyo.

Pasa a ser problema tuyo en proporción a cuánto hayas construido tú.

ABAP a medida: donde se retrasan los proyectos

S/4HANA no es ECC sobre una base de datos nueva. Partes del modelo de datos han cambiado. Clientes y proveedores pasan a ser interlocutores comerciales (business partners). Los asientos de finanzas y de inventario se consolidaron en menos tablas, más anchas. Algunas transacciones y funciones se eliminaron o se sustituyeron.

El código a medida que lee tablas directamente, depende de una exit que se ha movido o da por supuesto en silencio un orden de clasificación (HANA no garantiza ninguno salvo que la consulta lo pida) puede pasar una comprobación de sintaxis y aun así hacer lo que no debe. Ese último tipo es el que duele, porque aparece en las pruebas de integración o después del arranque, no en el análisis del código.

El proceso que funciona:

1. Mide primero el uso. Activa el registro de uso en producción (el ABAP call monitor, transacción SCMON) y déjalo funcionando durante un cierre de ejercicio completo. En los sistemas con muchos años, una parte considerable de los objetos a medida a menudo no se ejecuta nunca. El código que nadie ejecuta se borra, no se migra.
2. Pasa las herramientas de análisis por lo que queda. Las comprobaciones de SAP encuentran posibles problemas. No pueden decirte cuáles importan al negocio.
3. Clasifica cada objeto. Retirarlo, sustituirlo por funcionalidad estándar, corregirlo donde está o reconstruirlo fuera del núcleo. Una decisión por objeto, con un responsable de negocio con nombre y apellidos.
4. Prueba por proceso, no por objeto. Cambiar el código es la parte barata. Demostrar que el ciclo de pedido a cobro y el cierre mensual siguen dando las mismas cifras es la parte cara.

Los proyectos se retrasan aquí por un motivo aburrido: nadie contó a tiempo. El volumen de código a medida solo se conoce de forma aproximada, quienes lo escribieron a menudo ya se han ido, y los hallazgos de verdad llegan en el segundo ciclo de pruebas, cuando la fecha ya se ha anunciado internamente.

Interfaces, y PI/PO con el mismo reloj

ECC rara vez está solo. IDocs al almacén, llamadas RFC y BAPI desde la planta, ficheros planos al banco y al asesor fiscal, un portal de clientes que lee una vista de base de datos que alguien creó en 2011. Hay que encontrar, probar y, en algunos casos, reconstruir cada una de ellas.

Si esas interfaces pasan por SAP Process Integration o Process Orchestration, hay un segundo plazo en las mismas fechas. El Architecture Center de SAP dice que PI/PO se acerca al «final del mantenimiento estándar en 2027», que los clientes pueden ampliar el mantenimiento hasta 2030 y que después termina el soporte de SAP. SAP dirige a los clientes de PI/PO hacia SAP Integration Suite, que incluye una evaluación de migración y herramientas de migración guiadas por asistente.

Las herramientas ayudan con los objetos estándar. No te dicen qué interfaces siguen sirviendo para algo, y la lógica de mapeo a medida sigue necesitando que una persona la lea. Construye el inventario a partir de la configuración del middleware, los registros y los procesos programados, no de un cuestionario. Después planifica juntos el traslado del ERP y el del middleware. Si se hacen uno detrás del otro, cada interfaz se prueba dos veces.

Migración de datos

En una conversión de sistema, tus datos se trasladan con el sistema, y su calidad también. La conversión a interlocutores comerciales suele ser el primer choque: clientes duplicados, proveedores que también son clientes, direcciones en campos de texto libre, números fiscales en el sitio equivocado. Todo eso hay que limpiarlo antes de la conversión, no durante.

En una implantación nueva extraes, depuras, transformas y cargas, y la parte difícil es la conciliación. Finanzas da el visto bueno cuando cuadran los saldos y las partidas abiertas, no cuando termina el proceso de carga. Construye la migración como código repetible que puedas ejecutar una docena de veces sobre datos cada vez más limpios, comparando automáticamente los resultados en cada ejecución.

En cualquiera de las dos vías, archiva primero lo que ya no necesitas. Menos datos significan ejecuciones de conversión más cortas y una ventana de parada más corta.

Extensiones con núcleo limpio

La tentación en un proyecto con fecha límite es arrastrar todas las modificaciones y prometer que se ordenará más adelante. Ese más adelante no llega.

El nombre que SAP da a la alternativa es clean core: dejar el sistema estándar sin modificar y construir las extensiones sobre interfaces que SAP publica y mantiene estables, ya sea dentro de S/4HANA o a su lado en SAP Business Technology Platform. No todo puede estar limpio el primer día. La regla que de verdad se puede cumplir es más sencilla: no se construye nada nuevo a la manera antigua. Cada modificación que evitas ahora es una que no tendrás que volver a probar en cada actualización futura.

Un marco de decisión

Hay tres caminos realistas, y un cuarto que recibe menos atención.

Arrancar en S/4HANA antes del 31 de diciembre de 2027. Encaja con las empresas que ya han empezado, tienen un sistema mayoritariamente estándar y tienen un partner reservado. Desde hoy son quince meses, y pocos departamentos financieros aceptarán un paso a producción en mitad del cierre del ejercicio. Si no has hecho el análisis del código a medida, este probablemente no es tu camino.

Pagar el mantenimiento ampliado y arrancar antes de 2030. Es hacia donde va la mayor parte del mercado. El coste es la prima de dos puntos; confirma con SAP cómo se aplica si arrancas a mitad del periodo. El riesgo es tratar 2030 como se trató 2027: como algo lejano hasta que de repente deja de serlo.

Acogerse a la transition option de la private edition hasta 2033. Eso significa un contrato RISE with SAP, HANA, tu sistema trasladado a SAP ERP, private edition antes del 31 de diciembre de 2030, el plan max success y el mínimo de 2 TB. Para una empresa mediana, rara vez es la forma más barata de ganar tiempo.

Dejar SAP. Para algunos fabricantes y distribuidores medianos, un ERP más pequeño es una opción real. El trabajo de interfaces y de datos no se reduce. Pasa a ser la mayor parte del proyecto.

Los próximos seis meses, elijas lo que elijas

De aquí a finales de marzo de 2027, todo esto compensa en cualquiera de los caminos:

1. Confirma tu punto de partida. Enhancement package, base de datos, contrato de mantenimiento. Pide por escrito a tu equipo de cuenta de SAP las condiciones del mantenimiento ampliado que se te aplican.
2. Activa ya el registro de uso, para que recoja el cierre del ejercicio 2026.
3. Haz un análisis del código a medida y sal de él con una cifra, no con una impresión: cuántos objetos, cuántos se usan y cuántos tocan las partes del modelo de datos que han cambiado.
4. Construye el inventario de interfaces, incluido todo lo que pasa por PI/PO, con un responsable y una decisión para cada interfaz.
5. Empieza a depurar los datos maestros, primero clientes y proveedores.
6. Deja de añadir modificaciones. Desde hoy, el desarrollo nuevo sigue el clean core.
7. Mete la subida del mantenimiento de 2028 en el presupuesto de 2027 como un coste conocido y no como una sorpresa.
8. Reserva capacidad: el partner, tu equipo interno de SAP y los desarrolladores que se ocupan de los sistemas que rodean a SAP. La escasez de perfiles es uno de los motivos que dan los miembros de DSAG para el retraso de los calendarios.

Contando hacia atrás desde un arranque en 2030: ciclos de pruebas y ensayos del paso a producción en 2030, desarrollo y corrección en 2029, diseño y depuración de datos en 2028, análisis ahora. Hay menos holgura de la que parece.

Dónde conseguir ayuda

No somos una consultoría funcional de SAP ni hacemos conversiones a S/4HANA; trabajamos junto al partner que las hace, en el inventario y la reconstrucción de las interfaces, el código de migración de datos y su conciliación, y las aplicaciones construidas alrededor de ECC que tienen que sobrevivir al traslado. Ese trabajo se describe en nuestra página de modernización de ERP, y el mantenimiento de sistemas heredados cubre los sistemas que se quedan donde están hasta que hagas el traslado. Si quieres tener contado el ecosistema que rodea a tu ERP antes de firmar un programa, escribe a office@c9group.dev.