Plazos de migración a S/4HANA y plan de proyecto por ruta

En mi experiencia, los plazos de una migración a S/4HANA desde SAP ECC son de 12 a 18 meses para una conversión brownfield y de 18 a 24 meses para una implementación greenfield. Una selective data transition lleva de 12 a 18 meses. El plan de proyecto sigue las seis fases de SAP Activate, y la fase que más a menudo se desborda es el código a medida.

Respuesta corta: empiece el plan con el SAP Readiness Check y dedique a los datos entre el 30 y el 40 % del esfuerzo. En un brownfield, planifique tres conversiones de prueba y cuente con un downtime de cutover de entre un fin de semana y una semana.

Este artículo es el detalle de plazos y planificación que hay detrás de mi guía de migración de ECC a S/4HANA, que cubre las rutas y las fechas límite de ECC. Si va a implementar SAP desde cero en lugar de salir de ECC, mi guía de plazos de implementación de SAP cubre ese caso, con la duración de cada fase.

La ruta marca la duración. Mi regla: greenfield cuando viene de otros sistemas o hay que definir procesos nuevos. Brownfield cuando los procesos están definidos y funcionan, y selectiva cuando hay que redefinir los procesos de algunas áreas.

Esto es lo que dura cada ruta en los programas que he visto, y lo que suele alargarla:

Ruta	Plazo típico	En torno a qué se construye el plan	Qué suele alargarlo
Brownfield (conversión del sistema)	De 12 a 18 meses	Convertir el sistema ECC existente con el Software Update Manager y repetir conversiones de prueba	La adaptación del código a medida y la conversión a business partner
Greenfield (nueva implementación)	De 18 a 24 meses	Diseño Fit-to-Standard, construcción y ciclos repetidos de carga de datos	Talleres de Explore que se convierten en largas listas de requisitos, y la depuración de datos
Selective data transition	De 12 a 18 meses	Acordar qué sociedades, unidades e histórico se trasladan, y después herramientas especializadas	La definición del alcance de datos y la dependencia de socios especializados

El calendario importa tanto como la ruta. Para ECC en los enhancement packages 6 a 8, el mantenimiento estándar termina el 31 de diciembre de 2027 (SAP News). Un brownfield que empiece este mes sale en vivo entre octubre de 2027 y abril de 2028, y un greenfield que empiece ahora llega en 2028.

Por eso la mayoría de los planes que se escriben hoy necesitan algo de mantenimiento ampliado en el presupuesto. Inclúyalo desde el principio, no como una sorpresa en el segundo año.

RISE with SAP es un paquete comercial, no una ruta. Un brownfield o una migración selectiva bajo RISE aterriza en SAP Cloud ERP Private, el nombre actual que usa SAP para lo que muchos todavía buscan como S/4HANA Cloud Private Edition. Los 6 a 9 meses que indico para GROW with SAP y los 9 a 18 meses para RISE son para implementaciones nuevas, no para salidas de ECC.

SAP Activate es el método de entrega de SAP para S/4HANA. Tiene seis fases: Discover, Prepare, Explore, Realize, Deploy y Run (SAP Activate).

Una migración usa las mismas fases. Lo que cambia es el trabajo dentro de cada una.

El plan de proyecto de migración

1. 01

   Discover

   Readiness Check, decisión de ruta y caso de negocio.

2. 02

   Prepare

   Plan, gobierno, equipo y primer sandbox.

3. 03

   Explore

   Fit-to-Standard o diseño delta, lista WRICEF acordada.

4. 04

   Realize

   Construcción, código a medida, cargas de datos, conversiones de prueba.

5. 05

   Deploy

   Ensayo general, cutover y go-live.

6. 06

   Run

   Hypercare, estabilización y desmantelamiento de ECC.

Esto es lo que contiene cada fase en una migración, y dónde difieren las rutas:

Fase	Qué ocurre en una migración	Cómo difieren las rutas
Discover	SAP Readiness Check, decisión de ruta, caso de negocio, primera visión del código a medida y de los datos	La selectiva necesita aquí un primer alcance de datos
Prepare	Plan, gobierno, equipo, responsabilidad sobre los datos, sandbox	El brownfield ejecuta una primera conversión en sandbox; el greenfield prepara el sistema y el calendario de talleres
Explore	Talleres Fit-to-Standard o diseño delta, lista WRICEF acordada, mapeo de datos	El greenfield pasa aquí más tiempo; el brownfield trabaja los simplification items que aplican
Realize	Construcción, adaptación del código a medida, ciclos de carga de datos, rondas de pruebas	El brownfield ejecuta conversiones de prueba; el greenfield ejecuta ciclos de carga, normalmente con el Migration Cockpit
Deploy	Ensayo general, cutover, go-live	La ventana de downtime depende de la ruta, del volumen de datos y del enfoque
Run	Hypercare, estabilización	Desmantelar ECC y archivar lo que conservó

WRICEF significa workflows, informes, interfaces, conversiones, ampliaciones y formularios. Es la lista de todo lo que construye más allá del estándar de SAP, y es la cifra que hay que vigilar.

En los 21 programas SAP que he dirigido o rescatado, el mayor error es no planificar bien al inicio de la implementación. En Prepare, acuerde quién es responsable de la depuración de datos, qué código a medida se retira y cuándo se hace cada conversión de prueba y cada ensayo. Esas fechas se convierten en la columna vertebral del plan.

Brownfield: planifique en torno a las conversiones de prueba

Un plan brownfield se construye en torno al ciclo de conversión. El Software Update Manager convierte el sistema, y cada ejecución de prueba le dice cuánto durará la real y qué se rompe.

En un brownfield planifico tres conversiones de prueba antes del cutover. Cada una debe ejecutarse sobre una copia reciente de producción, para que los tiempos signifiquen algo. La última debe comportarse como el go-live: misma secuencia, mismas personas, mismas comprobaciones.

El plan de la propia SAP para su enfoque downtime-optimized es parecido. Prevé una ejecución en sandbox, una ejecución de aseguramiento de calidad, una verificación de carga sobre un clon y un ensayo general (SAP Learning). SAP señala que técnicamente son posibles menos ejecuciones, pero que aumentan el riesgo.

Greenfield: planifique en torno al diseño y las cargas de datos

En un greenfield el tiempo se va en Explore. Los talleres Fit-to-Standard deciden cuánto del estándar de SAP adopta usted, y cada brecha se convierte en un objeto WRICEF que hay que construir, probar y mantener.

Los datos se trasladan en ciclos de carga, normalmente con el SAP S/4HANA Migration Cockpit. Planifique varios ciclos de carga completos, cada uno seguido de una conciliación que firma el negocio. Mi guía paso a paso del Migration Cockpit cubre las tablas de staging, los objetos de migración y el proceso de carga.

Selectiva: planifique en torno al alcance de datos

Un plan selectivo empieza con un alcance de datos. Qué sociedades, unidades de negocio y años de histórico se trasladan, y qué procesos se rediseñan.

Ese alcance determina las herramientas, el socio especializado y los ciclos de prueba. Si lo cambia tarde, el plazo cambia con él.

En mi experiencia, el código a medida es la fase que más a menudo se desborda. También es el costo oculto que más se olvida en una migración, y lo trato en mi guía de costos de migración a S/4HANA.

Estos son los puntos que yo vigilaría, por orden:

1. Código a medida. Los equipos lo dimensionan a partir de un informe y descubren su tamaño real cuando empieza la remediación. En un programa, el análisis con smartShift redujo los objetos a medida de 18.000 a 3.200. Primero retire, después adapte.
2. Objetos a medida que la evaluación no detectó. En mi experiencia, los objetos a medida que el SAP Readiness Check no detecta son los que duelen después. Lea mi guía del SAP Readiness Check antes de tratar su resultado como su alcance.
3. Datos. La migración de datos supone entre el 30 y el 40 % del esfuerzo. Cuando la depuración no tiene responsable, empieza tarde y luego aprieta los ciclos de prueba. Mi artículo sobre por qué fracasa la migración de datos en SAP profundiza en ello.
4. Explore. Los presupuestos se resienten en Explore, a medida que crece la lista WRICEF. Cuando el proveedor controla el alcance, nadie del lado del proveedor tiene motivos para frenar ese crecimiento.
5. Ensayos recortados para ganar tiempo. Un ensayo suprimido para proteger la fecha suele costar más tiempo el fin de semana del go-live del que ahorró.

Mi opinión: fije la fecha de go-live al final de Explore, cuando se conocen la lista WRICEF y el alcance del código a medida. Una fecha fijada en el kickoff es una conjetura con una presentación al consejo adjunta.

El downtime de cutover que he visto va de un fin de semana a una semana. Influyen el volumen de datos, el enfoque de conversión, el número de entidades e interfaces que salen en vivo a la vez y la rapidez con la que el negocio puede validar.

Para un brownfield, SAP ofrece un enfoque de conversión downtime-optimized en el Software Update Manager. Traslada parte de la conversión y la migración de datos al tiempo de actividad, mientras producción sigue funcionando.

No es tiempo gratis. SAP enumera ejecuciones de prueba adicionales, una planificación más compleja, congelaciones de customizing y de desarrollo antes del downtime, y un experto formado en el enfoque.

Así que acuerde el downtime que el negocio puede aceptar antes de elegir el enfoque técnico. Después demuéstrelo en las conversiones de prueba, no el fin de semana del go-live. Mantenga el cutover lejos del cierre mensual y de la temporada alta.

Un plan vale lo que valen las hipótesis que lo sostienen. Estas son las preguntas que yo haría antes de que nadie firme:

1. ¿Qué ruta asume el plan, y qué en los resultados de nuestro Readiness Check la respalda?
2. ¿Cuántos objetos a medida quedan en el alcance tras el análisis de uso, y cuántos se retirarán?
3. ¿Quién es responsable de la depuración de datos, y en qué fase empieza?
4. ¿Cuántas conversiones de prueba o ciclos de carga están previstos, y con qué datos?
5. ¿Qué downtime asume el plan, y qué ejecución de prueba lo demuestra?
6. ¿Cuándo se fija la fecha, y qué le ocurre si la lista WRICEF crece en Explore?

Pida al socio referencias de programas como el suyo y su diseño de alto nivel. Si las respuestas son genéricas y no específicas de su negocio, trátelo como una señal de alarma.

Ejecute el SAP Readiness Check este trimestre. Ponga los hallazgos sobre código a medida y datos delante del CFO y del director del programa antes de que nadie se comprometa con una fecha de go-live.

Después construya el plan hacia atrás desde la ventana de cutover que puede aceptar, con tres conversiones de prueba en un brownfield o los ciclos de carga que necesite su ruta. Para poner a prueba primero la propia ruta, pruebe mi evaluación de migración greenfield o brownfield.

Ayudo a las organizaciones a construir y someter a prueba planes de migración como este. Si quiere una opinión independiente, póngase en contacto.

¿Cuánto dura una migración a S/4HANA?

En mi experiencia, una conversión brownfield desde ECC dura de 12 a 18 meses, una implementación greenfield de 18 a 24 meses y una selective data transition de 12 a 18 meses. El código a medida es la fase que más a menudo se desborda, y la migración de datos supone entre el 30 y el 40 % del esfuerzo.

¿Cuáles son las fases de un plan de proyecto de migración a S/4HANA?

El plan sigue SAP Activate: Discover, Prepare, Explore, Realize, Deploy y Run. En una migración, Discover contiene el Readiness Check y la decisión de ruta, Realize contiene el código a medida, las cargas de datos y las conversiones de prueba, y Deploy contiene el ensayo general y el cutover.

¿Cuántas conversiones de prueba necesita una migración brownfield a S/4HANA?

En un brownfield planifico tres conversiones de prueba antes del cutover. Para su enfoque downtime-optimized, SAP prevé una ejecución en sandbox, una ejecución de aseguramiento de calidad, una verificación de carga y un ensayo general, y advierte que menos ejecuciones aumentan el riesgo.

¿Cuánto dura el downtime del cutover en S/4HANA?

El downtime de cutover que he visto va de un fin de semana a una semana. Depende del volumen de datos, del enfoque de conversión y de cuántas entidades e interfaces salen en vivo a la vez. La conversión downtime-optimized de SAP traslada parte del trabajo al tiempo de actividad, pero requiere más ejecuciones de prueba y más planificación.

¿Podemos terminar una migración a S/4HANA antes de que acabe el soporte de ECC en 2027?

El mantenimiento estándar de ECC en los enhancement packages 6 a 8 termina el 31 de diciembre de 2027. Un brownfield iniciado en octubre de 2026 sale en vivo entre octubre de 2027 y abril de 2028, y un greenfield en 2028. La mayoría de los programas que empiezan ahora deberían presupuestar algo de mantenimiento ampliado.

¿Qué es lo que más retrasa los proyectos de migración a S/4HANA?

En mi experiencia, el código a medida es lo que más a menudo se desborda, seguido de una depuración de datos que empieza tarde y de una lista WRICEF que no deja de crecer en Explore. No planificar bien al inicio del programa es la raíz de la mayoría de estos problemas.