El multiplicador de carga: qué arrastra cada ruta a S/4HANA
Brownfield arrastra cada línea de código Z existente; Bluefield permite dejar código atrás. Cómo pesa el custom code de IS-U en el esfuerzo de remediación hacia S/4HANA.
· 6 min de lectura
El mismo código Z no pesa igual según la ruta que se elija para llegar a S/4HANA. No es una diferencia de opinión entre consultores: es un multiplicador medible entre las tres estrategias que tiene sobre la mesa una utility de América Latina con IS-U profundamente customizado — Brownfield, Bluefield/Selective Data Transition y Greenfield. Esa es la variable que determina el presupuesto real de remediación, no el tiempo de proyecto que aparece en la lámina de kickoff.
El multiplicador, ruta por ruta
En un Brownfield —técnicamente una conversión de sistema— la base de datos migra a HANA y la capa de aplicación se actualiza en un evento técnico coordinado, pero las configuraciones, la data histórica y los desarrollos propios (programas Z, user exits, enhancements) se convierten hacia adelante prácticamente en bloque (Diligent Global, 2025). Eso reduce la disrupción del negocio en el corto plazo, pero significa que todo objeto custom —esté vigente, obsoleto o duplicado— entra a la fase de remediación como candidato a revisión. El multiplicador, aquí, se aplica sobre el inventario completo.
En un Bluefield o Selective Data Transition, la lógica se invierte: la migración selectiva permite evaluar críticamente qué personalizaciones son realmente necesarias y eliminar el código custom innecesario que de otra forma saturaría el sistema nuevo (SAP Community, 2024). El multiplicador no desaparece —sigue existiendo remediación—, pero se aplica sobre una base que el equipo ya depuró antes de migrar, no después.
Tres rutas, tres multiplicadores distintos sobre la misma base de código. Y la elección entre ellas rara vez se hace mirando ese multiplicador: se hace mirando el cronograma.
Por qué el multiplicador no es simétrico en la práctica
Esta es precisamente la razón por la que, como se planteó en la pieza anterior de esta serie, las utilities con IS-U profundamente customizado tienden a inclinarse hacia Brownfield: perciben que “menos movimiento” significa “menos riesgo”. Lo que ese cálculo suele subestimar es el costo que ese mismo volumen de código arrastrado impone más adelante, en la fase de remediación técnica.
El custom code remediation se ha convertido en uno de los flujos de trabajo más intensivos en recursos de cualquier conversión a S/4HANA, independientemente de la ruta elegida (SmartShift, 2026). La diferencia entre rutas no es si hay que remediar —siempre hay que remediar— sino cuántos objetos entran al análisis y con qué criterio se descartan.
En Brownfield, cada programa Z, cada user exit y cada enhancement debe escanearse contra el nuevo modelo de datos, y una parte significativa requiere ajuste (SmartShift, 2026). Las herramientas estándar para esta fase —el Readiness Check y el ABAP Test Cockpit (ATC)— identifican y resuelven incompatibilidades entre el código existente y el modelo de datos simplificado de S/4HANA, integrándose con las ABAP Development Tools para ejecutar la adaptación directamente sobre el código (SAPinsider, 2026). El ATC es la herramienta; el volumen de objetos que debe pasar por ella es lo que define el esfuerzo real — y ese volumen es exactamente lo que cambia según la ruta.
Para una utility con años de desarrollos alrededor del ciclo meter-to-cash de IS-U —ajustes de facturación, integraciones de eventos, reglas de tarifa propias—, esa diferencia de criterio no es cosmética. Es la diferencia entre remediar un inventario completo de objetos heredados o remediar solo el subconjunto que el negocio confirma que sigue siendo indispensable.
Los mismos problemas que este banco editorial ha documentado en el ciclo M2C de utilities LATAM —ajustes masivos por datos inconsistentes, reclamos elevados por errores de facturación, operaciones comerciales reactivas que golpean el flujo de caja— suelen tener su origen en capas de personalización acumuladas durante años sobre IS-U. Gobernar ese flujo y estabilizarlo con integración por eventos ayuda a operar mejor hoy, pero no resuelve la pregunta de fondo: cuánto de ese código seguirá siendo necesario cuando la plataforma cambie.
El horizonte de soporte también entra en la ecuación del multiplicador. SAP mantiene el mantenimiento estándar de SAP Business Suite 7 y SAP ERP 6.0 hasta el 31 de diciembre de 2027, con una fase opcional de mantenimiento extendido hasta 2030 (SAP Support Portal, 2026). No es solo una fecha de vencimiento de soporte: es también la ventana disponible para decidir con qué volumen de custom code se quiere llegar a la conversión, y con qué multiplicador se va a trabajar en cada ruta.
El punto de decisión real
El error frecuente no es elegir Brownfield —para una utility con customizaciones críticas y probadas, puede ser la ruta correcta—, sino elegirlo sin dimensionar el multiplicador que esa elección activa sobre la base de código existente. Estimar el esfuerzo de remediación como si fuera equivalente entre rutas es subestimar sistemáticamente el proyecto Brownfield y sobrestimar el Bluefield.
La utility que dimensiona ese multiplicador antes de comprometerse con una ruta —no después— llega a la fase de remediación con un presupuesto de esfuerzo realista, en lugar de uno optimista.
Para los casos donde ni un Brownfield puro ni un Greenfield completo encajan del todo, existe un puente técnico específico entre ambos extremos. De eso trata la siguiente pieza de esta serie.
Fuentes
- SAP Community — Choosing the Right Path for Your S/4HANA Transformation, 2024: https://community.sap.com/t5/financial-management-blog-posts-by-members/choosing-the-right-path-for-your-s-4hana-transformation-greenfield/ba-p/13877169
- SAP Support Portal — Strategy: End of mainstream maintenance SAP Business Suite 7 / SAP ERP 6.0, 2026: https://support.sap.com/en/offerings-programs/strategy.html
- SmartShift — Effective SAP Custom Code Remediation: What You Need to Know, 2026: https://smartshift.com/blog/custom-code-remediation-in-sap
- Diligent Global — Greenfield vs. Brownfield vs. Hybrid: The Impact on Custom ABAP Code Migration to S/4HANA, 2025: https://diligentglobal.com/blogs/different-approaches-to-custom-code-migration-greenfield-brownfield-hybrid/
- SAPinsider — Technical Guide: Using ABAP Test Cockpit for SAP S/4HANA Transition, 2026: https://sapinsider.org/articles/technical-guide-using-abap-test-cockpit-for-sap-s-4hana-transition/
¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?
Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusión técnica y estratégica.
