Cuando tus Z se vuelven deuda: la conversación incómoda antes de migrar a S/4
La migración SAP S/4HANA no es solo “cambiar de versión”. En la práctica es una auditoría brutal de tus procesos reales, tus datos y, sobre todo, de todas esas personalizaciones que un día fueron “necesarias” y hoy frenan cada mejora.
Sin embargo, cuando se aborda como un proyecto técnico (mover sistemas) en vez de un cambio de producto operativo (cómo trabaja el negocio), aparecen los clásicos síntomas: retrasos, pruebas interminables, integraciones frágiles y debates eternos sobre qué mantener.
Decisiones críticas antes de una migración SAP S/4HANA
Si tu objetivo es reducir riesgo y ganar velocidad, define primero las decisiones que bloquean al resto. La migración SAP S/4HANA se vuelve manejable cuando clarificas alcance, enfoque y principios de arquitectura.
1) Elegir el enfoque: greenfield, brownfield o híbrido
Los tres enfoques existen en el mundo real, pero no significan lo mismo para tu organización:
- Greenfield: re-implementación. Máxima oportunidad de simplificar y estandarizar, pero exige disciplina de negocio y gestión del cambio.
- Brownfield: conversión del sistema existente. Puede ser más rápida, pero si “te llevas la casa con la humedad”, la deuda viaja contigo.
- Híbrido: combina conversiones y re-diseños por dominios (por ejemplo, finanzas primero). Además, suele encajar cuando hay filiales con madurez distinta.
2) Tolerancia al cambio vs. tolerancia al riesgo
Esta parte es incómoda: muchas empresas dicen querer estandarizar, pero se comportan como si cada excepción fuera sagrada. Por lo tanto, conviene fijar un “principio de producto”: qué procesos deben ser estándar y cuáles justifican diferenciación real.
3) Qué hacer con las personalizaciones (Z) y extensiones
En una migración SAP S/4HANA, el volumen de Z no es el problema; el problema es no saber cuáles aportan valor. Clasifica por categorías: eliminar (obsoleto), reemplazar por estándar, refactorizar o externalizar como extensión.
Si estás en ese debate, te puede ayudar este enfoque de plataforma y mantenibilidad: SAP Clean Core extensiones: Guía Esencial 2025. Además, alinea muy bien con lo que SAP promueve como estrategia de extensibilidad.
Arquitectura y plataforma: lo que acelera (o frena) tu migración SAP S/4HANA
La plataforma no es un “detalle” del equipo técnico. Define la capacidad de evolucionar sin re-trabajo. En especial, la migración SAP S/4HANA suele fallar cuando se subestima el impacto de integraciones y del modelo operativo.
Integración: menos spaghetti, más productos de integración
Si hoy integras “punto a punto” con interfaces frágiles, S/4HANA no te va a salvar. Sin embargo, sí es un buen momento para ordenar el mapa: APIs, eventos, colas, patrones por dominio y control de versiones.
Para aterrizar patrones y decisiones, revisa: Integración SAP BTP S4HANA: Guía Esencial 2025.
Extensibilidad en SAP BTP: dónde sí tiene sentido
Externalizar ciertas capacidades (workflows, automatización, apps satélite, integración) suele mejorar mantenibilidad, pero no es “gratis”: exige gobierno, identidad, entornos y ciclo de vida bien montado.
Si buscas un punto de partida pragmático, esta referencia ayuda a evitar improvisación: Arquitectura mínima SAP BTP: Guía Esencial 2025.
Datos, pruebas y cutover: donde se gana o se pierde la migración SAP S/4HANA
La migración SAP S/4HANA se rompe normalmente en tres sitios: calidad de datos, pruebas orientadas a proceso y una ventana de cutover mal diseñada. Además, todo se agrava si el negocio llega tarde a validar.
Gestión de datos: depurar primero, migrar después
Una idea clave: migrar datos “tal cual” es una forma de cristallizar problemas. Define reglas de calidad, propietarios y un backlog de remediación. Por lo tanto, convierte la limpieza de datos en un trabajo incremental, no en un infierno de última hora.
Pruebas: centradas en procesos end-to-end
Probar “transacciones” aisladas no te da confianza real. En su lugar, define escenarios de negocio completos (order-to-cash, procure-to-pay, record-to-report) con datos representativos y criterios de aceptación acordados.
Cutover: diseña un plan repetible
El cutover no es un checklist estático. Es un ensayo general que debe repetirse y medirse. Además, documenta dependencias (integraciones, usuarios clave, ventanas de extracción/carga) y define un plan de rollback realista.
Gobernanza y roles: el antídoto contra el “proyecto eterno”
La migración SAP S/4HANA se acelera cuando hay una gobernanza que decide rápido y con criterios. Sin embargo, “gobernanza” no es más comités: es claridad de responsabilidades y definición de estándares.
Modelo operativo mínimo recomendado
- Product owner de proceso: decide prioridades y acepta cambios funcionales.
- Arquitectura: define estándares (integración, extensibilidad, datos) y evita decisiones locales que rompen el conjunto.
- Seguridad y compliance: valida identidades, segregación de funciones y trazabilidad desde el inicio.
- Equipo de pruebas: diseña escenarios end-to-end y automatiza lo repetible cuando aporta valor.
Además, conviene alinear esta gobernanza con guías oficiales de SAP. Referencias útiles: SAP Help Portal y SAP Community (documentación, notas, prácticas compartidas).
Preguntas Frecuentes
¿Cuánto tarda una migración SAP S/4HANA?
Depende del enfoque (greenfield/brownfield/híbrido), del volumen de integraciones y de la deuda de personalización. Lo realista es estimar por fases y validar con un assessment técnico-funcional.
¿Es mejor convertir (brownfield) o re-implementar (greenfield)?
Brownfield suele reducir cambio inicial, pero arrastra complejidad existente. Greenfield permite simplificar más, pero exige rediseño de procesos y mayor gestión del cambio. Un enfoque híbrido por dominios es común cuando hay restricciones mixtas.
¿Qué hago con mis desarrollos Z durante la migración?
Clasifica por valor y criticidad: eliminar, reemplazar por estándar, refactorizar o mover a extensiones fuera del core. La decisión correcta se apoya en principios de Clean Core y en mantenibilidad a largo plazo.
Conclusiones
Una migración SAP S/4HANA exitosa no se gana con “más esfuerzo”, sino con mejores decisiones: enfoque, arquitectura, datos e integraciones bajo control. Si lo tratas como un cambio de producto operativo, el proyecto deja de ser una caja negra y se convierte en un plan medible.
- Define el enfoque correcto: greenfield, brownfield o híbrido deben responder a tu tolerancia al cambio y a la deuda real del sistema.
- Reduce deuda antes de moverla: personalizaciones y datos sucios multiplican el coste; prioriza eliminar/simplificar y estandarizar.
- Diseña plataforma e integración: una arquitectura de extensiones y un mapa de integraciones sólido evitan fragilidad y re-trabajo.
Por lo tanto, si tu siguiente paso es preparar un assessment y un roadmap con criterios claros (no solo fechas), empezar por estas decisiones te ahorra meses de fricción y te acerca a valor real en S/4HANA.