La fecha de 2027 lleva años marcada en el calendario de muchas organizaciones que todavía utilizan SAP ECC o, más ampliamente, aplicaciones principales de SAP Business Suite 7.
SAP mantiene el soporte estándar de estas aplicaciones hasta finales de 2027. Después, las empresas podrán optar por mantenimiento extendido hasta finales de 2030, sujeto a condiciones adicionales. SAP, además, ha comprometido la disponibilidad de mantenimiento para SAP S/4HANA hasta 2040.
Esto convierte los próximos meses y años en un periodo especialmente relevante para las empresas que todavía no han definido su transición.
Sin embargo, migrar a S/4HANA no debería abordarse únicamente como una actualización tecnológica. En proyectos complejos, una planificación insuficiente puede terminar provocando retrasos, sobrecostes, pérdida de funcionalidades e incluso conflictos entre cliente, integrador y proveedores.
2027 no significa que SAP ECC deje de funcionar
Uno de los primeros puntos que conviene aclarar es que alcanzar el final del mantenimiento estándar no implica que los sistemas dejen automáticamente de funcionar.
El problema es otro.
A partir de 2028, las organizaciones que necesiten más tiempo podrán contratar mantenimiento extendido para determinadas aplicaciones de Business Suite 7 hasta finales de 2030. SAP indica que este servicio supone un incremento de dos puntos porcentuales sobre la base de mantenimiento correspondiente.
Por tanto, retrasar una migración puede tener consecuencias económicas y operativas que conviene valorar con antelación.
Antes de migrar, hay que saber qué existe
Uno de los mayores errores consiste en comenzar un proyecto de transformación sin conocer con precisión el entorno SAP actual.
Antes de definir una migración debería realizarse un inventario técnico y funcional que permita conocer, entre otros elementos:
- módulos utilizados;
- desarrollos propios y objetos Z;
- interfaces con sistemas externos;
- personalizaciones realizadas a lo largo de los años;
- volumen y calidad de los datos;
- procesos críticos del negocio;
- sistemas dependientes de SAP;
- licencias y usuarios existentes.
Cuanto más antiguo sea el entorno, mayor puede ser la acumulación de desarrollos, excepciones y modificaciones que dificulten posteriormente la transición.
Elegir correctamente el modelo de migración
No todas las organizaciones necesitan seguir el mismo camino hacia S/4HANA.
Una empresa puede optar por una conversión del sistema existente, una nueva implantación o estrategias híbridas en las que se trasladan determinados procesos y datos.
La elección tiene importantes consecuencias técnicas, económicas y contractuales.
Mantener una gran cantidad de personalizaciones históricas puede reducir inicialmente el esfuerzo de transformación, pero también trasladar problemas antiguos al nuevo entorno. Por el contrario, rediseñar procesos puede aportar mayor simplificación, aunque aumenta la necesidad de análisis, pruebas y gestión del cambio.
Por ello, la estrategia debe quedar claramente definida antes de comprometer plazos y presupuestos.
El contrato es tan importante como la tecnología
Muchos conflictos en proyectos SAP no surgen exclusivamente por un error técnico, sino por expectativas diferentes sobre lo que debía entregar cada parte.
El contrato debería definir con precisión cuestiones como:
- alcance del proyecto;
- entregables;
- responsabilidades del cliente y del integrador;
- criterios de aceptación;
- migración y depuración de datos;
- desarrollos incluidos;
- integraciones;
- pruebas;
- soporte durante el go-live;
- gestión de cambios;
- calendario e hitos;
- tratamiento de retrasos.
Las expresiones ambiguas pueden convertirse posteriormente en uno de los principales focos de discusión.
La migración de datos merece especial atención
Los datos suelen representar uno de los mayores riesgos de cualquier transformación ERP.
No basta con trasladarlos técnicamente de un sistema a otro. Hay que verificar su integridad, consistencia, correspondencia y utilidad en los nuevos procesos.
Datos duplicados, registros incompletos o criterios diferentes entre el sistema antiguo y el nuevo pueden provocar errores que aparecen únicamente después de la puesta en producción.
Por ello, deberían definirse previamente las reglas de transformación y los controles que permitirán validar el resultado.
Las pruebas deben dejar evidencias
Las pruebas funcionales y las pruebas de aceptación del usuario son esenciales antes de un go-live.
Además de detectar errores, cumplen otra función importante: generar evidencias sobre el estado real del proyecto.
Planes de prueba, incidencias, resultados, correos, tickets, actas y decisiones de aceptación pueden ser fundamentales si posteriormente surge una controversia sobre si determinadas funcionalidades se entregaron correctamente.
Esperar hasta el último momento aumenta el riesgo
SAP ha dado a sus clientes un horizonte amplio de transición, pero eso no significa que todas las empresas puedan esperar hasta 2027 para comenzar.
SAP también recomienda avanzar en otras transiciones relacionadas con su ecosistema antes de esa fecha, como el paso de SAP Solution Manager hacia SAP Cloud ALM.
Cuanto más compleja sea la organización, mayor será la necesidad de planificación.
La transición a S/4HANA debería entenderse como un proyecto empresarial, no simplemente como un cambio de versión.
Revisar ahora el entorno técnico, los contratos, los datos, las personalizaciones y las responsabilidades puede reducir significativamente el riesgo de que la presión del calendario transforme una migración necesaria en un proyecto problemático.
Contáctanos en luis@luisvilanova.es