Migración de ECC a S/4HANA: rutas, pasos y plazos de SAP ECC

Una migración de ECC a S/4HANA lleva su sistema SAP ERP de SAP ECC 6.0 a SAP S/4HANA, con una nueva base de datos, un nuevo modelo de datos financieros y una nueva interfaz de usuario. La decisión que tiene delante es qué ruta seguir y si puede salir en vivo antes de que termine el mantenimiento estándar de ECC el 31 de diciembre de 2027.

Respuesta corta: greenfield si viene de otros sistemas o necesita procesos nuevos, brownfield si sus procesos están definidos y funcionan, selective data transition si solo algunas áreas necesitan rediseño. En mi experiencia, brownfield lleva de 12 a 18 meses, greenfield de 18 a 24 meses y selective data transition de 12 a 18 meses. Ejecute el SAP Readiness Check antes de comprometerse con cualquiera de ellas.

Pasar de ECC a S/4HANA no es una simple actualización. Cambia cómo se almacenan los datos, cómo se contabilizan las transacciones y cómo trabajan los usuarios.

En un proyecto en el que trabajé, un equipo hizo reconstruir decenas de informes a medida exactamente como estaban en ECC. Nadie preguntó si seguían haciendo falta. Después, la mitad de ellos nunca se usó.

La migración fue técnicamente limpia. El valor, no.

SAP ECC significa SAP ERP Central Component. Es el núcleo de SAP ERP 6.0, una de las aplicaciones centrales de SAP Business Suite 7, y cuando alguien dice «SAP ECC» casi siempre se refiere a ECC 6.0. Gestiona finanzas, controlling, compras, ventas y producción sobre cualquier base de datos que SAP admita, desde Oracle hasta SQL Server y Db2.

La primera razón para migrar es el mantenimiento. Para SAP ERP 6.0 en los enhancement packages 6 a 8, el mantenimiento estándar termina el 31 de diciembre de 2027. Los sistemas en el enhancement package 5 o anterior salieron del mantenimiento estándar a finales de 2025 (SAP).

SAP S/4HANA es el sucesor, y SAP se ha comprometido a mantenerlo hasta finales de 2040.

La segunda razón es el tiempo. Si empieza hoy, en octubre de 2026, una conversión brownfield, el go-live llega entre finales de 2027 y la primavera de 2028. Si empieza hoy un greenfield, sale en vivo en 2028.

Así que, para la mayoría de los clientes de ECC, la pregunta ya no es si migrar. Es qué ruta seguir y cuánto mantenimiento ampliado presupuestar mientras lo hace.

También trato este tema en un vídeo de mi canal de YouTube (en inglés).

Estas son las diferencias que generan la mayor parte del esfuerzo de migración:

Área	SAP ECC	SAP S/4HANA
Base de datos	Cualquier base de datos admitida (Oracle, Db2, SQL Server y otras)	Solo SAP HANA
Modelo de datos financieros	Tablas separadas de FI, CO y rentabilidad, con tablas de totales	Universal Journal (tabla ACDOCA) como fuente única a nivel de partida individual
Maestro de clientes y proveedores	Registros separados de clientes y proveedores	El business partner es obligatorio
Número de material	18 caracteres	Hasta 40 caracteres, si activa la longitud ampliada
Gestión de crédito	Gestión de crédito de SD	SAP Credit Management (FIN-FSCM)
Interfaz de usuario	SAP GUI	Apps de SAP Fiori, con SAP GUI aún disponible on-premise y en Private Edition
Despliegue	On-premise	On-premise, Private Edition (RISE with SAP) o Public Edition (GROW with SAP)
Ampliaciones	Programas Z y modificaciones	Clean Core: APIs liberadas, ABAP Cloud on-stack o side-by-side en SAP BTP
Mantenimiento	EHP 6 a 8: estándar hasta finales de 2027, ampliado hasta finales de 2030	Comprometido hasta finales de 2040

SAP registra cada una de estas diferencias como un simplification item y las publica en la Simplification List de cada versión de S/4HANA. Algunas son obligatorias para todos los clientes, como el business partner. Otras solo importan si usa la función, y el SAP Readiness Check le indica cuáles se aplican a su sistema.

Un cliente europeo del sector manufacturero con el que trabajé en 2023 preguntaba una y otra vez por qué sus jobs batch a medida habían dejado de funcionar tras la conversión. La lógica dependía de estructuras de tablas de ECC que S/4HANA había cambiado. Nadie se había preguntado si esos jobs seguían teniendo sentido en el nuevo modelo.

La migración mueve los datos. La verdadera pregunta es qué hace usted con las decisiones de diseño que hereda.

Mi regla para elegir es breve. Greenfield cuando viene de otros sistemas o cuando hay que definir procesos nuevos. Brownfield cuando sus procesos están definidos y funcionan, y selective data transition cuando hay que redefinir los procesos de algunas áreas.

Decide

¿Qué ruta de ECC a S/4HANA encaja con su situación?

→Greenfield

Viene de otros sistemas, o hay que definir procesos nuevos

→Brownfield

Los procesos están definidos y funcionan

→Selective data transition

Solo algunas áreas necesitan redefinir sus procesos

Greenfield: una implementación nueva

Una implementación nueva de S/4HANA. No se arrastra ninguna configuración heredada, los procesos se diseñan sobre el estándar de SAP y solo se cargan los datos que necesita.

Es la opción natural si parte de su negocio funciona hoy con sistemas que no son de SAP. He visto empresas lamentar no haber preparado a sus usuarios para lo distinto que se siente un sistema greenfield. Si la planificación de la adopción empieza en la formación, ya es tarde.

Brownfield: conversión del sistema

Brownfield es una conversión del sistema. Su sistema ECC actual se convierte en el mismo sitio, y la configuración, el código a medida y el histórico vienen con usted. La conversión técnica se ejecuta con el Software Update Manager (SUM) y su Database Migration Option.

SAP publica una Conversion Guide for SAP S/4HANA para cada versión, con los requisitos previos y el orden de los pasos técnicos. Lea la de su versión de destino antes de planificar fechas. El riesgo es la deuda técnica que arrastra, porque la complejidad heredada se traslada con usted salvo que la depure de forma deliberada.

Selective data transition

Selective data transition traslada sociedades, unidades de negocio o tramos temporales de datos elegidos, no todo. Requiere herramientas especializadas y un socio con experiencia en ello. Algunos proveedores la venden como «bluefield».

Encaja en grupos donde finanzas funciona bien pero compras necesita un rediseño, o donde fusiones y escisiones han dejado procesos muy distintos conviviendo. Rediseña las áreas que lo necesitan y conserva el histórico donde importa.

Así se comparan las tres en las preguntas que suelen hacer los consejos de dirección:

Ruta	Cuándo elegirla	Plazo típico	Riesgo principal
Greenfield	Viene de otros sistemas, o hay que definir procesos nuevos	De 18 a 24 meses	Carga de cambio para los usuarios, y el histórico que se queda atrás
Brownfield	Los procesos están definidos y funcionan	De 12 a 18 meses	Deuda técnica y código a medida sin uso que se arrastran
Selective data transition	Hay que redefinir los procesos de algunas áreas	De 12 a 18 meses	Dependencia de herramientas y socios especializados, y una delimitación compleja de los datos

La ruta cambia el detalle, pero la secuencia es la misma. Estos son los cinco pasos que yo planificaría, en este orden.

La secuencia de migración

1. 01

   Readiness check

   Ejecute el SAP Readiness Check y confirme los requisitos técnicos previos.

2. 02

   Elegir y planificar

   Elija la ruta, fije el alcance y planifique todo el programa antes de empezar a construir.

3. 03

   Código a medida

   Averigüe qué se usa, retire el resto y adapte lo que queda.

4. 04

   Datos

   Clasifique, depure y archive antes de mover nada.

5. 05

   Probar y hacer el cutover

   Varias rondas de pruebas y al menos un ensayo completo de cutover.

1. Ejecute el readiness check

Empiece aquí. Siempre. El SAP Readiness Check analiza su sistema ECC e informa sobre simplification items, compatibilidad de add-ons, código a medida, volúmenes de datos y dimensionamiento.

Las sorpresas suelen ser los add-ons y el código a medida. Algunos clientes con los que he trabajado tenían cientos de objetos a medida en el alcance. Mejor descubrirlo en la segunda semana que en el duodécimo mes.

En una conversión brownfield, compruebe al mismo tiempo estos requisitos previos:

1. Versión: la conversión funciona desde SAP ERP 6.0 con cualquier enhancement package.
2. Unicode: el sistema debe ser Unicode, o tendrá que planificar una conversión en dos pasos.
3. Dual-stack: los sistemas dual-stack deben separarse primero.
4. Business partner: los maestros de clientes y proveedores deben convertirse a business partners antes de la conversión. Este punto sorprende a más equipos que ningún otro.

2. Elija la ruta y planifique el programa

Use los resultados del readiness check y mi regla anterior para elegir la ruta. Después planifique todo el programa, incluidos datos, pruebas y cutover, antes de que nadie empiece a construir.

En los 21 programas SAP que he dirigido o rescatado, el mayor error de migración que veo es no planificarla bien al inicio de la implementación. Decida en las primeras semanas quién es responsable de la depuración de datos, qué código a medida se retira y cuándo se hacen los ensayos de cutover. Esas decisiones salen caras si se toman tarde.

3. Adapte el código a medida

Ejecute las comprobaciones de S/4HANA en el ABAP Test Cockpit, que comparan su código con los simplification items de SAP. La app Custom Code Migration muestra los mismos resultados con datos de uso, para que vea qué se usa antes de corregir nada.

El objetivo es menos código Z, no solo código Z que funcione. En un programa, el análisis con smartShift nos llevó de 18.000 objetos a medida a 3.200.

Cada objeto a medida que arrastra encarece cada actualización futura. He visto empresas reducir un 40 % los plazos de actualización con principios de Clean Core, y mi guía de SAP Clean Core explica cómo clasificar lo que queda.

4. Prepare y traslade los datos

Clasifique, depure y archive antes de mover nada. Este paso lleva más tiempo del que prevé cualquier plan, así que tiene su propia sección más abajo.

5. Pruebe, forme y haga el cutover

Haga las pruebas por rondas: pruebas unitarias, de integración y de aceptación de usuario (UAT), y después al menos un ensayo completo de cutover. Incluya en las UAT tanto a usuarios clave como a usuarios ocasionales, porque encuentran problemas distintos.

El ensayo no es opcional. Saca a la luz desfases de tiempo, validaciones que faltan y fallos de interfaces que solo aparecen cuando se ejecuta toda la secuencia. Los equipos que se lo saltan se encuentran esos problemas el fin de semana del go-live.

En mi experiencia, la migración de datos supone entre el 30 y el 40 % del esfuerzo de implementación. También es la razón más habitual de que los plazos se retrasen.

Cómo se trasladan los datos depende de la ruta. En brownfield, SUM convierte los datos en el mismo sitio. En greenfield, carga los datos maestros y las partidas abiertas con el SAP S/4HANA Migration Cockpit, y en selective data transition las herramientas especializadas trasladan el alcance que haya elegido.

Sea cual sea la ruta, clasifique los datos antes de moverlos:

1. Calientes: de uso frecuente, necesarios para la operación diaria.
2. Templados: acceso ocasional, relevantes pero no a diario.
3. Fríos: históricos o sin uso, conservados solo para auditoría.

Los datos fríos no tienen por qué ir a S/4HANA. Archívelos. Registros de proveedores duplicados, unidades de medida incoherentes y maestros de clientes a medio rellenar existen en todos los sistemas ECC, y pasan intactos a S/4HANA si nadie los corrige antes.

Un cliente con el que trabajé dedicó cinco meses solo a la depuración y el archivo de datos. Mi artículo sobre por qué fracasa la migración de datos en SAP profundiza en este paso.

Estas son las cinco herramientas que he usado en programas de ECC a S/4HANA. Dos son de la propia SAP y tres vienen de proveedores especializados:

Herramienta	Fabricante	Qué hace	Dónde encaja
SAP Readiness Check for SAP S/4HANA	SAP	Informa sobre simplification items, compatibilidad de add-ons, impacto en el código a medida, volúmenes de datos y dimensionamiento	Antes de elegir la ruta
App Custom Code Migration	SAP	App de SAP Fiori que ejecuta las comprobaciones de S/4HANA del ABAP Test Cockpit y usa datos de uso para encontrar código sin uso; funciona en S/4HANA o en el entorno ABAP de SAP BTP	Delimitación y adaptación del código a medida
smartShift	smartShift Technologies	Análisis y transformación automatizados del código ABAP a medida para S/4HANA	Análisis y corrección del código a medida
SNP (plataforma Kyano)	SNP Group	Software de transformación de datos para selective data transition, comercializado bajo el enfoque «Bluefield» de SNP	Selective data transition, fusiones y escisiones
Natuvion	Natuvion Group	Software de conversión de datos y herramientas de cutover para transiciones a S/4HANA	Selective data transition y cutover

SNP y Natuvion son miembros fundadores de la Selective Data Transition Engagement community de SAP. Las otras herramientas de SAP que encontrará son SUM para la conversión brownfield y el Migration Cockpit para las cargas de datos greenfield.

Una herramienta no sustituye a las decisiones. Alguien de su lado tiene que acordar qué se retira.

Para SAP ERP 6.0 en los enhancement packages 6 a 8, el mantenimiento estándar termina el 31 de diciembre de 2027. El mantenimiento ampliado opcional va de 2028 al 31 de diciembre de 2030, con un recargo de dos puntos porcentuales sobre su base de mantenimiento actual (SAP News).

Más allá de 2030 hay una vía estrecha, la SAP ERP, private edition, transition option. Ofrece mantenimiento de 2031 a 2033 a los clientes que trasladan su sistema ECC a la nube privada de SAP como SAP ERP, private edition, sobre SAP HANA, bajo RISE with SAP. El sistema debe trasladarse antes del 31 de diciembre de 2030, tener al menos 2 TB y contar con el max success plan de SAP.

Así que 2033 no es una fecha límite general. Se aplica a sistemas grandes que ya han llevado ECC a la nube de SAP. Para todos los demás, ECC en infraestructura propia tiene 2027 como fecha del mantenimiento estándar y 2030 como fin del mantenimiento ampliado.

1. 2027Termina el mantenimiento estándar de ECC31 de diciembre, para SAP ERP 6.0 EHP 6 a 8
2. 2028Go-live probable si empieza ahoraBrownfield de 12 a 18 meses, greenfield de 18 a 24
3. 2030Termina el mantenimiento ampliadoOpcional, con un recargo de dos puntos
4. 2033Termina la transition optionSolo SAP ERP, private edition, sistemas de 2 TB o más

Fuente: SAP News, febrero de 2020 y agosto de 2025

La cuenta es sencilla. Presupueste al menos algo de mantenimiento ampliado y use ese tiempo para depurar datos y retirar código a medida, no para esperar.

El costo sigue los mismos factores que el plazo: la ruta, el volumen de código a medida, el estado de sus datos y cuántas sociedades salen en vivo. Solo los datos suponen entre el 30 y el 40 % del esfuerzo, por eso un buen plan de datos ahorra más dinero que cualquier negociación de tarifas. Mi guía de costos de migración a S/4HANA cubre qué determina el presupuesto de una migración, y mi guía de costos de implementación de SAP desglosa el presupuesto por tamaño de empresa.

Para ver cómo se desarrolló un programa, lea mi caso práctico de migración de ECC a S/4HANA. Para evaluar sus propias opciones, pruebe la evaluación de migración greenfield o brownfield.

Este artículo es la visión general. Cada guía de la lista responde a fondo a una pregunta.

1. Plazos de migración a S/4HANA y plan de proyecto: fase por fase, por ruta, con conversiones de prueba y cutover.
2. Costo de migración a S/4HANA: qué determina el presupuesto de una conversión, una nueva implementación o una transición selectiva.
3. SAP Readiness Check y evaluación de migración: qué le dice el check y qué no detecta.
4. SAP S/4HANA Migration Cockpit paso a paso: cargar datos con staging tables o transferencia directa.
5. RISE with SAP: nube pública o privada: qué edición encaja con sus procesos.
6. Contrato y precios de RISE with SAP: qué cubre la suscripción y qué negociar.
7. Cómo elegir un socio de migración a S/4HANA: las preguntas que hacer y las señales de advertencia.
8. Recuperación de proyectos SAP: cómo rescatar una migración que se ha desviado.

Dos herramientas ayudan con las cifras: la calculadora de costos de implementación de SAP y el estimador de migración de datos.

¿Qué es SAP ECC?

SAP ECC (SAP ERP Central Component) es el núcleo de SAP ERP 6.0, parte de SAP Business Suite 7. Cubre finanzas, controlling, logística y otros procesos centrales y funciona sobre varias bases de datos. SAP S/4HANA es su sucesor y solo funciona sobre SAP HANA.

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

En mi experiencia, una conversión brownfield lleva de 12 a 18 meses, una implementación greenfield de 18 a 24 meses y una selective data transition de 12 a 18 meses. La depuración de datos es la razón más habitual de que los plazos se retrasen, porque la migración de datos supone entre el 30 y el 40 % del esfuerzo de implementación.

¿Qué pasa con SAP ECC después de 2027?

Para SAP ERP 6.0 en los enhancement packages 6 a 8, el mantenimiento estándar termina el 31 de diciembre de 2027. Puede contratar mantenimiento ampliado opcional hasta el 31 de diciembre de 2030 por dos puntos porcentuales adicionales. De 2031 a 2033 el mantenimiento solo está disponible mediante la SAP ERP, private edition, transition option, para sistemas grandes trasladados a la nube privada de SAP antes de finales de 2030.

Brownfield o greenfield: ¿cuál es mejor?

Ninguno es mejor en general. Elija greenfield cuando viene de otros sistemas o hay que definir procesos nuevos, y brownfield cuando sus procesos están definidos y funcionan. Si solo algunas áreas necesitan rediseño, considere la selective data transition.

¿Qué es la selective data transition en SAP?

La selective data transition traslada a S/4HANA sociedades, unidades de negocio o tramos temporales de datos elegidos, en lugar de convertirlo todo o empezar de cero. Le permite rediseñar algunas áreas y conservar el histórico en otras. Requiere herramientas especializadas, como las de SNP o Natuvion, y un socio con experiencia.

¿Cuáles son los requisitos previos para convertir ECC 6.0 a S/4HANA?

La conversión funciona desde SAP ERP 6.0 con cualquier enhancement package. El sistema debe ser Unicode, o se usa un enfoque en dos pasos, y los sistemas dual-stack deben separarse primero. Los maestros de clientes y proveedores deben convertirse a business partners antes de la conversión.

¿Qué le dice el SAP Readiness Check?

Analiza su sistema ECC e informa sobre los simplification items que le afectan, la compatibilidad de add-ons, el impacto en el código a medida, los volúmenes de datos y el dimensionamiento de HANA. Ejecútelo pronto, porque los equipos encuentran con frecuencia add-ons y código a medida de los que no sabían que dependían.

¿Debo elegir RISE with SAP o GROW with SAP para una migración de ECC?

La mayoría de los clientes de ECC con mucho código a medida y procesos complejos van a S/4HANA Cloud Private Edition bajo RISE with SAP, que admite la conversión del sistema existente. GROW with SAP usa Public Edition, que es una implementación nueva con procesos estándar y ampliaciones solo mediante APIs liberadas. Encaja en empresas dispuestas a adoptar el estándar de SAP.