Cutover, hypercare y el día después: gobernar un ECC ya convertido

Con el código a medida remediado, el downtime acotado y la regresión automatizada confirmando que veinte años de proceso siguen funcionando, llega el go-live. Pero el go-live no es la meta de esta serie: es el punto donde empieza una responsabilidad distinta. Un ECC recién convertido a S/4HANA puede volver a acumular la misma deuda técnica que motivó la conversión, si nadie gobierna lo que entra al core a partir de ese día.

El cutover no cierra el proyecto, abre un régimen distinto

Todo el trabajo de esta serie —convertir en vez de reimplementar, medir el alcance con el Readiness Check, remediar código a escala, acotar el downtime, probar con regresión dirigida por riesgo— tiene un objetivo final que rara vez se dice en voz alta: llegar al día después con un sistema que sea más fácil de mantener limpio que el que se dejó atrás. Ese objetivo no se logra en el cutover. Se logra, o se pierde, en los meses siguientes, cuando el equipo vuelve a la operación normal y la presión por resolver un problema urgente empuja hacia el atajo de siempre: modificar el core directamente.

Para una utility o una empresa de oil & gas de LATAM, esa presión es constante. La facturación, el corte y reconexión, y la atención de reclamos generan pedidos de cambio todo el tiempo. La pregunta que decide si la conversión valió la pena a largo plazo es: ¿esos cambios entran al sistema por un canal gobernado, o se cuelan como parches directos que, con los años, reconstruyen el mismo problema de código a medida sin control?

Un canal gobernado para el cambio: gCTS

gCTS —el Change and Transport System habilitado para Git— conecta el sistema de transporte de ABAP con repositorios Git externos; cuando un desarrollador libera una solicitud de transporte, gCTS la serializa como commit y la envía al repositorio, que se vuelve la fuente de verdad (SAP Community, 2026). Esto no cambia el flujo de trabajo diario del desarrollador ABAP —sigue liberando solicitudes de transporte como siempre—, pero agrega algo que el Change and Transport System clásico no tenía: historial de versiones, capacidad de comparar cambios y de revertir a un estado anterior.

Para un ECC recién convertido, esa trazabilidad no es una comodidad técnica: es la diferencia entre saber exactamente qué cambió en la lógica de facturación o de corte y reconexión desde el go-live, o depender de la memoria del equipo para reconstruir esa historia meses después.

Extensiones, no modificaciones: la disciplina de mantener el core limpio

El desarrollo ABAP moderno tiende hacia un enfoque Git-first mediante gCTS, mientras las extensiones complejas a medida se construyen como side-by-side en SAP BTP, integradas con SAP Cloud ALM para la gestión del cambio —un patrón que en S/4HANA Public Cloud es, además, obligatorio por diseño de la plataforma (ReleaseOwl, 2026). Esa distinción es la que sostiene un core limpio en el tiempo: cuando aparece la necesidad de una funcionalidad que el estándar no cubre, la disciplina no es modificar el core para resolverlo rápido, sino construirlo como una extensión desacoplada en BTP, que se conecta al sistema a través de APIs publicadas en lugar de tocar objetos internos.

SAP Cloud ALM cumple un rol específico en esta disciplina: ayuda a hacer las extensiones compatibles con clean core, evitando extensiones cuando es posible, extendiendo on-stack o side-by-side con BTP, y estableciendo una gobernanza que produce extensiones desacopladas (SAP Community, 2026). En la práctica, esto significa que cada solicitud de cambio pasa primero por la pregunta de si realmente necesita tocar el core, o si puede resolverse en la capa de extensión sin comprometer la estabilidad del sistema en la próxima actualización.

El hypercare: el período donde se decide el hábito

Las primeras semanas después del go-live —el período conocido como hypercare— son las que fijan el hábito que va a persistir. Si en esas semanas el equipo resuelve cada incidente con un parche directo al core porque «es más rápido», ese hábito se convierte en la norma. Si en cambio cada incidente se resuelve identificando primero si corresponde a una extensión BTP o a un cambio gobernado vía gCTS, ese hábito también se convierte en la norma —y es el que preserva, con el paso de los años, la limpieza que costó tanto lograr en la conversión.

Por qué esto cierra el círculo de meter-to-cash

A lo largo de esta serie, la lente constante ha sido la continuidad de facturación, corte y reconexión, atención de reclamos y mantenimiento de activos de red. El gobierno post-go-live es lo que sostiene esa continuidad después de que el proyecto de conversión terminó: un cambio de emergencia en la lógica de corte y reconexión que entra por gCTS queda documentado y es reversible; el mismo cambio metido directamente en el core, sin ese canal, es exactamente el tipo de modificación no rastreada que, en veinte años, terminó generando el volumen de código a medida que esta serie diagnosticó desde su primera pieza.

Convertir en vez de reimplementar preservó el histórico. Medir el alcance con el Readiness Check evitó presupuestar a ciegas. Remediar a escala resolvió el código heredado. Acotar el downtime protegió el corte productivo. Probar con regresión dirigida por riesgo confirmó que el proceso seguía funcionando. Pero es el gobierno del día después el que decide si todo ese trabajo se sostiene, o si el core vuelve, con los años, a ensuciarse otra vez.

Fuentes

• SAP Community — SAP gCTS Explained: Git, ABAP and DevOps Finally Together, 2026: https://community.sap.com/t5/technology-blog-posts-by-sap/sap-gcts-explained-git-abap-and-devops-finally-together/ba-p/14418355
• ReleaseOwl — SAP S/4HANA Public Cloud: The Paradigm Shift That Changes Everything, 2026: https://www.releaseowl.com/sap-s-4hana-public-cloud-the-paradigm-shift-that-changes-everything/
• SAP Community — Adapt Clean Core Principle Using SAP Cloud ALM, 2026: https://community.sap.com/t5/technology-blog-posts-by-members/adapt-clean-core-principle-using-sap-cloud-alm/ba-p/13688393