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

El mantenimiento estándar de SAP ECC termina el 31 de diciembre de 2027, dentro de unos 15 meses. El mantenimiento ampliado opcional se extiende hasta finales de 2030 con una tarifa más alta (SAP News). Las migraciones complejas pueden alargarse fácilmente de 18 a 24 meses cuando empiezan las pruebas reales. Si todavía no ha elegido un camino, un go-live antes de la fecha límite ya es improbable.

Si usted es el CIO o el director del programa que toma esa decisión, tiene tres caminos: greenfield, brownfield o transición selectiva de datos. El trabajo que hay detrás de cada uno sigue los mismos cinco pasos. Ejecute primero el SAP Readiness Check y después elija.

Pasar de ECC a S/4HANA no es una actualización directa. Cambia la forma en que se almacenan los datos, cómo se contabilizan las transacciones y cómo trabajan los usuarios. En un proyecto en el que participé, un equipo hizo reconstruir decenas de informes personalizados exactamente como estaban en ECC. Nadie preguntó si seguían haciendo falta. Más tarde, la mitad no se usó nunca. La migración fue técnicamente limpia. El valor no.

Las diferencias que determinan el esfuerzo de la migración:

Área	SAP ECC	SAP S/4HANA
Base de datos	Cualquier base de datos compatible (Oracle, Db2, SQL Server, otras)	Solo SAP HANA
Modelo de datos financiero	Tablas separadas de FI, CO y rentabilidad, con tablas de totales	Universal Journal (tabla ACDOCA) como única fuente de posiciones
Datos maestros de clientes y proveedores	Registros separados de cliente y de proveedor	El interlocutor comercial (business partner) es obligatorio
Interfaz de usuario	SAP GUI	Aplicaciones SAP Fiori, con SAP GUI todavía disponible on-premise y en Private Edition
Despliegue	On-premise	On-premise, Private Edition (RISE with SAP) o Public Edition (GROW with SAP)
Extensiones	Programas Z y modificaciones	Clean core: API publicadas, ABAP Cloud on-stack o side-by-side en SAP BTP
Mantenimiento	EHP 6 a 8 con mantenimiento estándar hasta finales de 2027, ampliado hasta finales de 2030	SAP se compromete a dar mantenimiento hasta finales de 2040

Un cliente con el que trabajé preguntaba una y otra vez por qué sus procesos por lotes personalizados 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. La migración en sí estaba completa. Nadie se había preguntado si esos procesos seguían teniendo sentido en el nuevo modelo.

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

Decide

¿Qué camino de migración encaja con su situación?

Los sistemas heredados están fragmentados y quiere rediseñar los procesos

→Greenfield

Los procesos son sólidos, ECC es estable y el historial debe conservarse

→Brownfield

Varias entidades, quiere reutilizar parte y datos selectivos

→Bluefield

Greenfield: empezar desde cero

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

Úselo cuando los sistemas heredados están demasiado fragmentados para convertirlos con limpieza, o cuando la empresa quiere replantear los procesos en lugar de copiarlos.

Atención a la carga de cambio. Los usuarios pierden los flujos de trabajo que conocen. He visto empresas arrepentirse de 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

Su sistema ECC actual se convierte en el mismo sitio. La configuración, el código personalizado y el historial vienen con usted. La conversión técnica se ejecuta con el Software Update Manager (SUM) y su opción de migración de base de datos.

Úselo cuando los procesos están maduros, el historial de transacciones importa por cumplimiento normativo y no hay ninguna reestructuración importante en curso.

Atención a la deuda técnica que se arrastra. La complejidad heredada se viene con usted, salvo que la limpie de forma deliberada durante la conversión.

Transición selectiva de datos

A veces se vende como «bluefield». Se trasladan sociedades, unidades de negocio o tramos de tiempo concretos, no todo, normalmente con herramientas especializadas y un socio con experiencia en ellas. Encaja en grupos formados mediante fusiones o escisiones, o cuando años de historial ya no importan.

Úselo cuando quiera la libertad de procesos del greenfield con la continuidad de datos del brownfield allí donde cuenta.

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

Criterio	Greenfield	Brownfield	Selectiva
Rediseño de procesos	Total, según el estándar de SAP	En gran medida se conserva	Se elige por unidad
Datos históricos	No se trasladan (o solo partidas abiertas y saldos)	Se trasladan por completo	Alcance seleccionado
Tiempo hasta el go-live	Más largo	Más corto	Depende del alcance
Deuda técnica	Eliminada	Se arrastra	Reducida en el alcance migrado
Impacto del cambio	Alto	Menor	Moderado
Ideal para	Sistemas heredados fragmentados, rediseño profundo	ECC estable y bien mantenido	Fusiones, escisiones, despliegues por fases

La secuencia de la migración

1. 01

   Evaluar

   Ejecute el SAP Readiness Check. Haga un inventario del código personalizado, los add-ons y las interfaces.

2. 02

   Clasificar los datos

   Segmente los datos en calientes, templados y fríos. Los datos fríos no tienen que migrar.

3. 03

   Depurar

   Resuelva duplicados, incoherencias y campos vacíos. Siempre lleva más tiempo del previsto.

4. 04

   Adaptar el código

   Ejecute las comprobaciones del ABAP Test Cockpit. Reduzca el código Z, no se limite a portarlo.

5. 05

   Probar y cutover

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

1. Evaluación y preparación

Empiece aquí. Siempre. El SAP Readiness Check analiza su sistema ECC e informa sobre elementos de simplificación, compatibilidad de add-ons, código personalizado, volúmenes de datos y dimensionamiento.

Las sorpresas suelen ser los add-ons y el código personalizado. Algunos clientes con los que he trabajado tenían cientos de objetos personalizados dentro del alcance, y a la mayoría le sorprende cuánto código inactivo aparece. Mejor descubrirlo en la semana dos que en el mes doce.

Compruebe a la vez los requisitos técnicos previos. La conversión parte de SAP ERP 6.0 con cualquier paquete de mejoras. El sistema debe ser Unicode, o bien se planifica una conversión en dos pasos. Los sistemas dual-stack deben separarse antes. Los datos maestros de clientes y proveedores deben convertirse en interlocutores comerciales antes de la conversión. Este último punto sorprende a más equipos que cualquier otro.

2. Análisis y clasificación de datos

Mida sus datos antes de moverlos y clasifíquelos:

1. Calientes: se usan con frecuencia y hacen falta para el procesamiento en vivo.
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 necesitan pasar a S/4HANA. Archívelos. Los equipos que se saltan este paso llevan al sistema nuevo un desorden que ralentiza tanto la migración como el rendimiento.

3. Depuración y archivado de datos

Este paso lleva más tiempo del que admite cualquier plan. Registros de proveedores duplicados. Unidades de medida incoherentes. Datos maestros de clientes a medio rellenar. Estos problemas existen en todo sistema 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 archivado de datos. Los equipos que se saltan la depuración descubren los problemas durante el cutover, cuando ya no hay tiempo para corregirlos como es debido. Mi artículo sobre por qué fracasa la migración de datos en SAP profundiza en este paso.

4. Adaptación del código personalizado

Ejecute las comprobaciones de preparación para S/4HANA del ABAP Test Cockpit (ATC), que comparan su código con los elementos de simplificación de SAP. El resultado muestra qué necesita una corrección de sintaxis, qué necesita una sustitución funcional y qué debería retirarse.

El objetivo es tener menos código Z, no solo código Z que funcione. Cada objeto personalizado que se traslada encarece todas las actualizaciones futuras. Mi guía de clean core explica cómo clasificar lo que queda.

5. Pruebas, formación y cutover

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

El ensayo no es opcional. Deja al descubierto desajustes de tiempos, validaciones que faltan y fallos de interfaces que solo aparecen cuando se ejecuta toda la secuencia. Los equipos que se lo saltan se topan con esos problemas el fin de semana del go-live.

Las herramientas de SAP que esperaría ver en cualquier plan de migración:

Herramienta	Qué hace	Cuándo usarla
SAP Readiness Check	Elementos de simplificación, add-ons, código personalizado, dimensionamiento	Antes de elegir el camino
ABAP Test Cockpit (ATC)	Detecta el código personalizado que dejará de funcionar	Adaptación del código personalizado
SAP Signavio	Muestra cómo se ejecutan realmente los procesos, no cómo se documentaron	Antes de congelar el diseño
SAP LeanIX	Mapea aplicaciones e interfaces	Diseño de la integración
Software Update Manager (SUM)	Ejecuta la conversión técnica	Conversión brownfield
SAP S/4HANA Migration Cockpit	Carga datos maestros y transaccionales	Migración de datos greenfield

Para SAP ERP 6.0 con paquetes de mejoras 6 a 8, el mantenimiento estándar termina el 31 de diciembre de 2027. El mantenimiento ampliado opcional se extiende hasta el 31 de diciembre de 2030 con un recargo de dos puntos porcentuales sobre la base de mantenimiento. Los paquetes de mejoras anteriores salieron del mantenimiento estándar a finales de 2025.

Más allá de 2030 solo hay una vía estrecha. La opción de transición de SAP ERP, private edition de SAP cubre de 2031 a 2033. Se aplica únicamente a sistemas grandes trasladados a SAP ERP, private edition sobre SAP HANA antes de finales de 2030, y solo con el plan max success de SAP. Trátela como una excepción, no como un plan.

En cuanto a la duración, las migraciones completas de sistemas complejos pueden alargarse de 18 a 24 meses o más cuando empiezan las pruebas reales. Para empresas medianas y grandes, de 12 a 18 meses o más es un plazo realista para una conversión bien preparada. Un programa greenfield grande que abarque varias entidades puede durar de 24 a 36 meses.

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 ahoraDe 18 a 24 meses cuando empiezan las pruebas reales
3. 2030Termina el mantenimiento ampliadoOpcional, con un recargo de dos puntos
4. 2033Termina la opción de transiciónPrivate edition, solo para sistemas grandes

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

Así que la cuenta es sencilla. Si empieza hoy una evaluación compleja, el go-live llegará en 2028. Presupueste el mantenimiento ampliado y use el tiempo para depurar datos y retirar código personalizado, en lugar de esperar. Para poner a prueba sus opciones, pruebe mi evaluación de migración.

¿Cuál es la diferencia entre la migración greenfield y brownfield de ECC a S/4HANA?

Greenfield es una implementación nueva: no se arrastra ninguna configuración heredada ni código personalizado, los procesos se diseñan según el estándar de SAP y solo se cargan los datos que necesita. Brownfield convierte su sistema ECC existente y conserva la configuración, el código personalizado y el historial. Es más rápido y menos disruptivo, pero la deuda técnica viene incluida. La transición selectiva de datos se sitúa entre ambos.

¿Cuál es la fecha límite de la migración de SAP ECC a S/4HANA?

Para SAP ERP 6.0 con paquetes de mejoras 6 a 8, el mantenimiento estándar termina el 31 de diciembre de 2027. El mantenimiento ampliado opcional se extiende hasta el 31 de diciembre de 2030 con un recargo de dos puntos porcentuales sobre la base de mantenimiento. Existe una opción de transición para 2031 a 2033, pero solo para sistemas grandes trasladados a SAP ERP, private edition sobre SAP HANA antes de finales de 2030.

¿Qué le indica el SAP Readiness Check?

Analiza su sistema ECC e informa sobre los elementos de simplificación que afectan a su configuración, la compatibilidad de los add-ons, el impacto en el código personalizado, los volúmenes de datos y el dimensionamiento de HANA. Ejecutarlo pronto cambia la conversación sobre el alcance, porque los equipos descubren con frecuencia add-ons y código personalizado de los que no sabían que dependían.

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

Una conversión bien preparada para una empresa mediana o grande suele durar de 12 a 18 meses o más. Los programas complejos con varias entidades pueden alargarse de 18 a 24 meses cuando empiezan las pruebas reales, y los programas greenfield grandes de 24 a 36 meses. La depuración de datos es el motivo más habitual de que los plazos se desvíen.

¿Qué es el Universal Journal (ACDOCA) y por qué importa en la migración?

El Universal Journal es la tabla única de posiciones, ACDOCA, que reúne los datos de contabilidad financiera, controlling y rentabilidad que ECC guardaba en tablas separadas. El código personalizado y los informes que leen las estructuras antiguas, como COEP o las tablas de rentabilidad, requieren revisión. Algunos necesitan pequeños ajustes; otros, un rediseño.

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

La conversión parte de SAP ERP 6.0 con cualquier paquete de mejoras. El sistema debe ser Unicode, o bien se usa un enfoque en dos pasos. Los sistemas dual-stack deben separarse antes. Los datos maestros de clientes y proveedores deben convertirse en interlocutores comerciales. Ejecute el SAP Readiness Check y las comprobaciones de código personalizado del ATC antes de comprometer fechas.

¿Debería 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 personalizado y procesos complejos pasan a S/4HANA Cloud Private Edition con RISE with SAP, que admite la conversión del sistema existente. GROW with SAP usa la Public Edition, que es una implementación nueva con procesos estándar y extensiones solo mediante API publicadas. Encaja en empresas dispuestas a adoptar el estándar de SAP.