El reloj corre. El soporte mainstream de SAP ECC termina el 31 de diciembre de 2027 y, según la encuesta DSAG 2025 (la asociación de usuarios SAP de habla alemana), cerca del 50% de las empresas todavía tienen toda la migración a SAP S/4HANA por delante. Para un comité de dirección, eso significa que la decisión de migrar ya no es estratégica a largo plazo: es operativa y urgente. Quien arranque tarde se quedará sin partners disponibles, sin ventanas de proyecto razonables y, en el peor de los casos, ejecutando su ERP crítico sin soporte del fabricante.
Esta guía está pensada para directores de IT, CFOs y responsables de transformación que necesitan tomar una decisión informada: qué significa de verdad el deadline de 2027, qué enfoque de migración encaja con cada organización, qué es RISE with SAP y cómo planificar un proyecto que, según la complejidad, puede durar entre seis meses y más de dos años. Sin humo y con cifras trazables a fuentes reales.
El deadline de SAP ECC: qué significa realmente 2027 y 2030
La fecha que importa es el 31 de diciembre de 2027. Ese día finaliza el soporte mainstream de SAP ECC 6.0 y de SAP Business Suite 7. A partir de ahí, según confirman tanto la documentación de SAP como los análisis de Rimini Street y SEIDOR, existe una opción de mantenimiento extendido que prolonga el soporte hasta el 31 de diciembre de 2030, pero con condiciones que conviene leer con lupa.
Ese mantenimiento extendido no es gratis. Según Rimini Street, el mantenimiento extendido de ECC (enhancement packages 6 a 8) más allá de 2027 conlleva un recargo de aproximadamente 2 puntos porcentuales sobre la base de mantenimiento —cerca de un 9% adicional sobre lo que ya se paga— hasta finales de 2030. Dicho de otro modo: el "más tiempo" tiene un coste recurrente, y solo compra una prórroga de tres años, no una solución.
Hay una tercera vía para los casos más complejos. En el primer trimestre de 2025, según Rimini Street, SAP anunció la SAP ERP, private edition, transition option: un paquete dentro de RISE que extiende el soporte de ECC más allá de 2030, pero únicamente para clientes complejos seleccionados que firmen un acuerdo RISE. No es una puerta de escape general; es un puente contractual para grandes landscapes que no llegarán a tiempo.
¿Está la industria preparada para 2027?
No. Los datos de la encuesta DSAG 2025, recogidos por IT-Onlinemagazin, dibujan un panorama claro:
- Solo el 16% de las empresas usa S/4HANA en exclusiva.
- El 21% ha migrado partes de su landscape.
- El 14% ha comenzado el proceso de migración.
- Aproximadamente el 50% todavía tiene toda la migración por delante.
Y un dato especialmente revelador: el 37% de los encuestados indicó que probablemente usará el mantenimiento extendido de SAP, lo que en la práctica significa que asumen que su migración a S/4HANA no estará terminada para finales de 2027.
Si más de un tercio del ecosistema ya planea recurrir a la prórroga de pago, la conclusión para cualquier organización es directa: la oferta de consultores, arquitectos y ventanas de migración se va a saturar. Empezar pronto no es una cuestión de prudencia técnica, sino de disponibilidad de mercado.
La buena noticia es que la adopción de la nube se acelera. Según la investigación conjunta de ASUG y DSAG, el uso de S/4HANA Private Cloud subió al 33% de las empresas, frente al 11% del año anterior, y S/4HANA Public Cloud pasó del 6% al 13%. La tendencia es inequívoca: la migración no solo va hacia S/4HANA, sino mayoritariamente hacia el consumo en nube gestionada.
Greenfield, brownfield o selective data transition: cómo elegir el enfoque
No existe una única manera de migrar a S/4HANA. Según la SAP Community y SNP Group, hay tres enfoques principales de transición, y la elección condiciona el coste, la duración y el riesgo de todo el proyecto.
Brownfield: conversión del sistema existente
El brownfield, o conversión del sistema, transforma el SAP ECC actual en S/4HANA conservando datos históricos, configuración y desarrollos a medida. Es el camino de menor disrupción: los procesos de negocio se mantienen en gran medida tal cual están. Según la SAP Community y Basis Admin, suele ser el enfoque más rápido, completándose en 6 a 12 meses.
La contrapartida es que también se arrastra la deuda técnica: customizing acumulado durante años, procesos heredados que quizá ya no aportan valor y un modelo de datos que no se replantea. Encaja bien en organizaciones cuyos procesos funcionan, que han invertido mucho en personalización valiosa y que necesitan cumplir el deadline con el menor sobresalto operativo.
Greenfield: implementación nueva con best practices
El greenfield es una implementación desde cero. Se rediseñan los procesos sobre las SAP best practices y se construye un sistema limpio, dejando atrás el customizing innecesario. Es la opción más transformadora y la que mejor aprovecha las capacidades nativas de S/4HANA, pero también la que más esfuerzo de gestión del cambio y rediseño exige, y por tanto suele requerir más tiempo que un brownfield.
Encaja en empresas que quieren reinventar sus procesos, que han crecido por adquisiciones con sistemas dispares o cuyo ECC actual está tan personalizado que conservarlo sería perpetuar el problema.
Selective data transition (bluefield): lo mejor de ambos mundos
La selective data transition, también conocida como bluefield, es un enfoque híbrido que reutiliza selectivamente datos y procesos. Permite, por ejemplo, rediseñar las áreas que lo necesitan y conservar los datos maestros e históricos que aportan valor. Da un control granular sobre qué se migra, pero requiere herramientas especializadas y experiencia, y como greenfield suele necesitar más tiempo que una conversión brownfield directa.
Tabla comparativa de enfoques
| Criterio | Brownfield (conversión) | Greenfield (nueva implementación) | Selective data transition (bluefield) |
|---|---|---|---|
| Punto de partida | Sistema ECC existente | Sistema limpio desde cero | Híbrido |
| Procesos de negocio | Se conservan | Se rediseñan con best practices | Se rediseñan selectivamente |
| Datos | Se migran íntegros | Se cargan de forma selectiva | Reutilización selectiva |
| Duración típica | 6-12 meses (el más rápido) | Mayor que brownfield | Mayor que brownfield |
| Deuda técnica | Se arrastra | Se elimina | Se reduce de forma controlada |
| Perfil ideal | Procesos válidos, mínima disrupción | Transformación profunda, M&A | Control granular, datos críticos a preservar |
Fuentes: SAP Community, SNP Group y Basis Admin.
Para muchas organizaciones, la decisión de enfoque está íntimamente ligada a la estrategia de infraestructura que se quiera adoptar. Si el proyecto va a aprovecharse para salir del centro de datos propio, conviene plantear en paralelo la migración a la nube de la carga SAP, porque el destino (hyperscaler, nube privada gestionada o RISE) condiciona el diseño técnico desde el primer día.
¿Qué es RISE with SAP y cuándo conviene?
RISE with SAP es la oferta de SAP que empaqueta la migración y la operación en nube en un único contrato. Según la documentación de SAP y el blog de SAP-PRESS, RISE combina S/4HANA Cloud Private Edition con la SAP Business Technology Platform (BTP), SAP Business Network y SAP Signavio, todo ello desplegado sobre infraestructura de hyperscalers como Microsoft Azure, AWS y Google Cloud.
La propuesta de valor es la consolidación: en lugar de gestionar licencias, infraestructura, herramientas de procesos y red de negocio por separado, la organización contrata un servicio gestionado con un único interlocutor responsable del SLA. Para empresas que quieren salir del on-premise y reducir la carga operativa de su equipo de IT, es una vía atractiva.
¿Cuándo conviene RISE y cuándo no?
RISE encaja especialmente cuando:
- Se busca transformar a la vez el ERP y el modelo de infraestructura, evitando dos proyectos consecutivos.
- El equipo interno de Basis e infraestructura es reducido y se prefiere externalizar la operación.
- Interesa el acceso integrado a BTP, Signavio (para minería y rediseño de procesos) y Business Network desde el inicio.
- En el caso de landscapes muy complejos, se necesita la ya mencionada transition option para extender el soporte de ECC más allá de 2030.
Conviene analizarlo con más cuidado cuando la empresa ya tiene una estrategia cloud consolidada con un hyperscaler concreto y acuerdos propios, cuando existe un equipo interno potente que prefiere mantener el control de la operación, o cuando los requisitos de residencia de datos y personalización chocan con el modelo estandarizado de la nube privada gestionada. En esos casos, una migración a S/4HANA sobre infraestructura cloud propia puede ofrecer más flexibilidad, a cambio de asumir más responsabilidad operativa.
La recomendación práctica: no tratar RISE como una decisión binaria de "todo o nada", sino evaluarlo módulo a módulo frente a las alternativas, idealmente con un partner que no tenga incentivo en empujar un único modelo.
¿Cuánto dura y cuánto cuesta un proyecto de migración a S/4HANA?
Es la pregunta que toda dirección hace primero, y la respuesta honesta es: depende del tamaño, la complejidad y el enfoque. Pero sí hay rangos de referencia documentados.
Según el blog de SAP-PRESS e IgniteSAP, una migración a SAP S/4HANA suele durar entre 6 y 18 meses en términos generales, con estas franjas según el perfil de empresa:
| Perfil de organización | Duración estimada de la migración |
|---|---|
| Proyecto general / alcance acotado | 6-18 meses |
| Mediana empresa | 12-24 meses |
| Gran empresa / landscape complejo | 30+ meses |
| Planificación y alineación previa (adicional) | 4-6 meses |
Fuentes: SAP-PRESS Blog e IgniteSAP.
Dos matices importantes. Primero, esos 4 a 6 meses de planificación y alineación previa no son opcionales: ocurren antes del cronómetro del proyecto técnico y suelen marcar la diferencia entre un proyecto controlado y uno que descarrila. Segundo, el enfoque elegido pesa: un brownfield bien acotado puede cerrarse en la franja baja (6-12 meses según la SAP Community y Basis Admin), mientras que un greenfield transformador en una gran empresa se acerca con facilidad a los 30 o más meses.
En cuanto al coste, los rangos varían tanto por organización que cualquier cifra genérica induce a error. Las variables que realmente lo determinan son el número de usuarios y módulos, el volumen de desarrollos a medida que hay que reescribir o eliminar, el modelo de licenciamiento (RISE frente a licencias perpetuas más infraestructura) y el grado de rediseño de procesos. Por eso el coste no se estima de forma fiable sin un assessment previo del sistema actual. Lo que sí es seguro es el coste de no decidir: el recargo de ~9% del mantenimiento extendido y el riesgo creciente de quedarse sin recursos de implantación conforme se acerque 2027.
Cómo planificar el proyecto: hoja de ruta paso a paso
Una migración a S/4HANA no se improvisa. Esta es una hoja de ruta en seis fases que ordena el trabajo y reduce el riesgo.
Fase 1 — Assessment y readiness check
Ejecutar el SAP Readiness Check sobre el sistema ECC actual para inventariar customizing, add-ons, tamaño de base de datos, simplificaciones requeridas y compatibilidad. Es el diagnóstico que alimenta todas las decisiones posteriores. Sin esta fotografía, cualquier estimación de plazo y coste es adivinación.
Fase 2 — Decisión de enfoque y destino
Con el assessment en la mano, decidir entre brownfield, greenfield o selective data transition, y en paralelo el destino de infraestructura: RISE, hyperscaler con licencias propias o nube privada. Estas dos decisiones están acopladas y conviene tomarlas juntas.
Fase 3 — Business case y aprobación
Traducir el alcance a un caso de negocio: inversión, ahorro de mantenimiento extendido evitado, beneficios de proceso y plazo realista (recordando los 4-6 meses de planificación previa). Es el momento de alinear a dirección financiera y de operaciones antes de comprometer recursos.
Fase 4 — Diseño y limpieza de datos
Rediseñar los procesos objetivo (en greenfield y bluefield) y, en todos los casos, abordar la calidad y limpieza de datos. Migrar datos sucios a S/4HANA es uno de los errores más caros y frecuentes. Esta fase también determina qué desarrollos a medida se conservan, se reescriben o se retiran.
Fase 5 — Build, migración y pruebas
Construir el sistema, ejecutar las conversiones o cargas de datos y abordar las pruebas de forma exhaustiva: pruebas unitarias, de integración, de regresión y de aceptación de usuario, además de pruebas de rendimiento. Es buen momento para automatizar todo lo automatizable —ciclos de regresión, validaciones de datos, despliegues repetibles— apoyándose en prácticas de automatización de procesos que aceleran el testing y reducen el error humano en las cargas.
Fase 6 — Cutover, go-live y soporte
Planificar el cutover con una ventana realista, ejecutar el go-live y establecer un periodo de hypercare con soporte reforzado. La estabilización post-arranque es parte del proyecto, no un añadido.
Lista de comprobación previa al arranque
- Readiness Check ejecutado y analizado
- Enfoque (brownfield / greenfield / bluefield) decidido y justificado
- Destino de infraestructura definido (RISE vs. cloud propio)
- Inventario de desarrollos a medida con decisión de conservar / reescribir / retirar
- Estrategia de limpieza y migración de datos
- Plan de pruebas y de gestión del cambio
- Sponsor ejecutivo y gobierno del proyecto asignados
Errores frecuentes y factores críticos de éxito
Los proyectos de S/4HANA que se complican rara vez fallan por la tecnología; fallan por la planificación y las personas. Estos son los patrones que más se repiten.
Subestimar la planificación previa. Saltarse los 4-6 meses de alineación que documentan SAP-PRESS e IgniteSAP es la causa raíz de la mayoría de los desvíos de plazo. La prisa por "empezar a configurar" suele salir cara.
Migrar datos sin limpiarlos. Arrastrar datos maestros duplicados, registros obsoletos o estructuras inconsistentes contamina el sistema nuevo desde el día uno. La limpieza de datos no es una tarea técnica menor: es un proyecto en sí mismo.
Tratar el enfoque como una decisión técnica aislada. Elegir brownfield o greenfield sin alinear la decisión con la estrategia de procesos y de infraestructura lleva a soluciones incoherentes. El enfoque, el destino cloud y el rediseño de procesos son una sola conversación.
Confundir el deadline con margen. Con el 37% del ecosistema planeando ya el mantenimiento extendido según DSAG, la disponibilidad de consultores se estrechará. Quien planee arrancar "en 2027" probablemente no encontrará el equipo que necesita.
Descuidar la gestión del cambio. Un greenfield rediseña la forma de trabajar de cientos de personas. Sin formación y acompañamiento, el mejor sistema técnico se topa con la resistencia de los usuarios.
Factores críticos de éxito
- Sponsor ejecutivo visible y gobierno de proyecto claro.
- Assessment riguroso como base de todas las estimaciones.
- Calidad de datos tratada desde el inicio, no al final.
- Pruebas automatizadas y exhaustivas antes del cutover.
- Partner con experiencia real en migraciones del mismo perfil y sin sesgo hacia un único modelo de infraestructura.
Conclusión
El deadline de 2027 no es una recomendación: es una fecha con consecuencias económicas (el recargo de ~9% del mantenimiento extendido hasta 2030) y operativas (la escasez de recursos de implantación que ya anticipan los datos de DSAG). Con la mitad del ecosistema aún sin migrar y un tercio planeando recurrir a la prórroga de pago, la ventaja competitiva está en decidir pronto y bien: elegir el enfoque correcto —brownfield, greenfield o selective data transition—, valorar RISE with SAP frente a las alternativas con criterio y planificar con la disciplina de las seis fases.
En Technova Partners acompañamos a empresas en todo el ciclo: desde el readiness check y la decisión de enfoque hasta el cutover y la estabilización, con una mirada honesta sobre infraestructura cloud y automatización de pruebas. Si quieres una evaluación de tu sistema actual y una hoja de ruta a medida hacia S/4HANA, hablemos sobre tu proyecto de migración. El mejor momento para empezar a planificar fue ayer; el segundo mejor es hoy.
