Un plan de transición a S/4HANA suele tener fecha para el assessment, para las pruebas y para el corte. Rara vez tiene una para dimensionar los desarrollos a la medida que ya existen, y eso es lo que termina moviendo la fecha de salida.
No es un descuido. Es que ese inventario no vive en un solo lugar: está repartido entre el sistema, la memoria del equipo y la cola de peticiones que sigue entrando.
1. Por qué el alcance técnico se subestima
Cuando se arma un plan de transición, lo que se dimensiona primero es lo que tiene dueño visible: los módulos estándar, la base de datos, las pruebas funcionales. Todo eso tiene responsable y aparece en el cronograma.
El trabajo técnico sobre lo que ya existe no tiene ese dueño. Está repartido entre quien escribió un desarrollo hace seis años, quien mantiene una interfaz que nadie documentó y quien atiende la cola del día a día.
Por eso el error no es de estimación, sino de inventario. No se subestima el esfuerzo: se omite la lista.
2. Los seis frentes
Los tres primeros son código y conexiones. Los tres últimos son salidas y demanda, que es donde el negocio nota la falla primero.
Los seis, en resumen:
- Desarrollos a la medida que hay que remediar. Lo que corría en ECC no siempre corre en S/4HANA.
- Desarrollos que nadie usa y nadie se atreve a borrar. Migrarlos cuesta; comprobar que no se usan, también.
- Integraciones con sistemas externos. Cada una depende del calendario de un tercero.
- Formularios, impresiones y salidas. No se ven como desarrollo y son lo primero que el negocio reclama.
- Reportes y extracciones. Se multiplican con los años y casi nunca están inventariados.
- La cola que sigue entrando durante el proyecto. Se congela al arrancar y se descongela completa al terminar.
La columna de la derecha de la guía es la que conviene usar. Para cada frente propone una forma de medirlo con datos que ya están en tu sistema, sin pedirle nada a nadie.
3. Qué hacer con el inventario
El objetivo no es un número total, sino separar tres montones: lo que hay que remediar, lo que se puede no migrar y lo que se puede posponer sin riesgo.
Ese segundo montón suele ser el más grande y el que nadie mira. Un entorno con quince años de operación acumula desarrollos que dejaron de usarse y siguen ahí porque borrarlos exige comprobar que nada depende de ellos. Comprobarlo cuesta menos que migrarlos.
Y hay una razón de calendario para hacerlo temprano. El mantenimiento estándar de ECC 6.0 con los paquetes de mejora 6 a 8 termina el 31 de diciembre de 2027, con mantenimiento extendido hasta 2030 por un recargo aproximado de dos puntos porcentuales sobre la base. Para los paquetes 0 a 5, el mantenimiento estándar terminó el 31 de diciembre de 2025 y no hay extensión disponible.
Sobre WSP International
WSP International es una firma tecnológica mexicano-americana con más de 25 años de operación ininterrumpida en el ecosistema SAP. Participa en la ejecución técnica dentro del equipo de migración del cliente, no en la dirección del proyecto. Cuenta con registro REPSE vigente.
Nota: WSP International no tiene relación alguna con WSP Global Inc., firma canadiense de ingeniería e infraestructura.