20 años de código Z: por qué la remediación a escala gana a SPAU objeto por objeto
SPDD/SPAU objeto por objeto no escala en sistemas con décadas de desarrollo. La remediación automatizada de código a medida reduce el riesgo antes de tocar producción.
· 7 min de lectura
El Readiness Check ya hizo su trabajo: puso sobre la mesa el volumen real de código a medida que una utility acumuló en veinte años de operación sobre SAP. La pieza anterior de esta serie explicó por qué ese diagnóstico —y no una estimación de consultoría— es la fuente real del alcance. Ahora viene la pregunta que decide si ese alcance se convierte en un cronograma realista o en un cuello de botella: ¿cómo se remedia ese código, objeto por objeto o a escala?
El camino estándar: preciso, pero lineal
SAP provee las herramientas para esta tarea, y son sólidas. SPDD sirve para adaptar las modificaciones sobre objetos de diccionario ABAP; SPAU y SPAU_ENH, para las modificaciones sobre objetos de repositorio después de ejecutar el Software Update Manager. Sobre esa base, el ABAP Test Cockpit (ATC) ejecuta los checks de S/4HANA y devuelve una lista de hallazgos vinculados a notas SAP que explican cómo resolver cada uno.
Es un proceso técnicamente correcto y bien documentado. El problema no es su precisión: es su forma. SPDD, SPAU y SPAU_ENH revisan objeto por objeto, y el ATC entrega hallazgos que un desarrollador debe interpretar y resolver uno a uno, apoyándose en la nota SAP correspondiente a cada simplification item. SAP mismo provee estas herramientas como checks técnicos útiles, aunque ofrecen una visibilidad parcial y fragmentada frente a lo que exige un codebase grande (smartShift, 2026).
Para un sistema con pocos años de desarrollo propio, ese ritmo objeto por objeto es manejable. Para una utility o una empresa de oil & gas de LATAM con dos décadas de reportes Z, user exits y enhancements construidos sobre el marco regulatorio local, el mismo proceso deja de ser una tarea de semanas y se convierte en un cuello de botella que amenaza el cronograma completo del proyecto de conversión.
Por qué veinte años de código Z rompen el modelo manual
La diferencia no es solo de velocidad. Un análisis automatizado a escala combina motores de evaluación propios con los checks de ABAP Test Cockpit para S/4HANA, y con eso identifica con precisión qué código legado necesita remediarse para alinearse con el nuevo modelo de datos de S/4HANA (smartShift, 2026). Esto no reemplaza al ATC: lo usa como una de sus entradas, pero procesa el resultado a nivel de todo el codebase en lugar de dejar que cada hallazgo se interprete de forma aislada.
Esa diferencia importa especialmente en un sistema legado grande: incluso en entornos empresariales con millones de líneas de código a medida, un análisis automatizado puede entregar resultados en días en lugar de meses (smartShift, 2026). Para un proyecto de conversión con fecha límite de soporte —como la que esta serie viene siguiendo desde su primera pieza— esa diferencia de tiempo no es un detalle de eficiencia: es la diferencia entre un cronograma viable y uno que se desborda antes de llegar a pruebas.
No es solo velocidad: es también alcance
Un análisis a escala no solo remedia más rápido lo que hay que remediar. También identifica qué parte del código a medida ya no se usa. Investigación de ASUG señala que tener demasiadas personalizaciones en instancias legadas es el principal desafío que enfrentan las organizaciones durante las migraciones a S/4HANA (smartShift, 2026), y buena parte de ese volumen suele ser código obsoleto, duplicado o simplemente sin uso.
Retirar con seguridad ese código inactivo reduce el tamaño real del proyecto de conversión: menos código para migrar significa menos esfuerzo de pruebas, menor costo y una fecha de salida a producción más corta (smartShift, 2026). Un proceso objeto por objeto rara vez llega a este nivel de depuración, porque su lógica es corregir lo que aparece, no cuestionar si ese objeto debería seguir existiendo.
Lo que esto significa para meter-to-cash
En una utility, el código a medida no está distribuido de forma pareja por todo el sistema: se concentra, con frecuencia, exactamente en los procesos que sostienen facturación, corte y reconexión, y en la lógica que traduce el marco regulatorio local a reglas de negocio dentro de IS-U. Ese es el código más sensible a remediar mal, y también el que más responsabilidad exige antes de tocar producción.
Un proceso de remediación que se demora meses en lugar de días no solo retrasa el cronograma del proyecto: extiende la ventana en la que el sistema legado, con soporte contando regresivamente hacia 2027, debe seguir sosteniendo esa operación diaria sin margen adicional. Cuanto más rápido y más completo sea el diagnóstico de qué código realmente necesita atención, más control tiene el equipo del proyecto sobre esa ventana.
Lo que sigue
Con el código a medida remediado, queda la pregunta que decide si la conversión técnica realmente sale bien: cuánto tiempo puede el negocio permitirse fuera de línea. La siguiente pieza de esta serie entra en ese terreno: el negocio no puede apagarse un fin de semana, y la ventana de downtime disponible es la que termina definiendo el éxito de la conversión técnica.
Fuentes
- smartShift — SAP Custom Code Analysis (Automated), 2026: https://smartshift.com/solution/sap-upgrade-code-analysis/
- smartShift — Automated SAP Custom Code Analysis & Remediation, 2026: https://smartshift.com/solution/sap-custom-code-analysis-smartshift/
- SAP Community — SAP S/4HANA System Conversion: Custom code adaptation process: https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/sap-s-4hana-system-conversion-custom-code-adaptation-process/ba-p/13337309
¿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.
