¿Qué sobrevive al migrar de ECC a S/4HANA?

El plazo de 2027 no es la fecha para empezar una migración de ECC a S/4HANA. Es la fecha para haber terminado las decisiones difíciles, las reescrituras, los ensayos y las aprobaciones del negocio. Lo que descarrila los programas rara vez es la conversión estándar de SAP. Es el sistema privado construido alrededor de SAP durante veinte años: programas Z, includes modificados, user exits, BAdIs, trabajos en segundo plano, intercambios de archivos, formularios, informes y supuestos que nadie documentó.

Tratar ese patrimonio como un montón de ABAP que solo tiene que compilar produce un sistema técnicamente verde con un comportamiento de negocio roto. La evaluación debe establecer cuatro hechos distintos para cada objeto: si aún se ejecuta, si SAP sigue permitiendo su punto de ampliación, si alguien aún lo usa y si su resultado sigue siendo correcto. Cada pregunta necesita pruebas diferentes. Un solo análisis no responde las cuatro.

El plazo de 2027 cambia el orden del trabajo

El compromiso de mantenimiento publicado por SAP mantiene el soporte estándar de las aplicaciones principales de SAP Business Suite 7 hasta finales de 2027, con mantenimiento ampliado opcional hasta finales de 2030 para quienes lo contraten. Ese mantenimiento da margen, no un diseño de migración. Compras puede adquirir cobertura de soporte, pero no recuperar los años necesarios para entender una lógica de liquidación indocumentada o rehacer con seguridad una interfaz de almacén.

Por eso el primer hito sensato es una evaluación que produzca pruebas, no una diapositiva de arquitectura objetivo. Debe dejar un inventario de objetos, datos de uso reales, grupos de dependencias, impactos conocidos de simplificación, comportamientos de negocio comprobables y responsables con nombre. Si solo entrega un recuento de objetos personalizados por paquete, ha contado el problema sin describirlo.

Empiece mientras ECC aún representa la verdad. La carga de producción, el historial de trabajos, el tráfico de interfaces y los resultados financieros conciliados son mucho más útiles que los recuerdos recogidos después de una congelación. Cuando los equipos comienzan a apagar trabajos o cambiar integraciones para el programa, la referencia queda contaminada. He visto equipos intentar reconstruir el comportamiento de un cierre mensual a partir de actas porque nadie capturó una ejecución limpia cuando pudo hacerlo. Se puede evitar.

La fecha también cambia la secuencia. El análisis del código personalizado debe ir antes de fijar el alcance de conversión, porque sus conclusiones pueden alterar el destino. Una transacción ECC muy modificada puede convertirse en una ampliación de S/4HANA, un servicio separado, una capacidad estándar o retirarse. No se pueden estimar esos caminos con rigor hasta saber qué código y datos toca cada transacción.

El patrimonio personalizado supera el espacio Z

Una lista de objetos Z es un comienzo útil y una definición peligrosa del alcance. El comportamiento del cliente puede vivir en namespaces, modificaciones de objetos SAP, implementaciones de ampliación, código generado, variantes, reglas de workflow, contenido BRFplus, formularios, cadenas de trabajos, ramas por autorización y programas externos que llaman a RFC o leen archivos. Parte del código con mayores consecuencias no contiene ninguna transacción Z que un responsable de negocio reconozca.

Construya el inventario con varias fuentes y conserve las claves de unión. Los metadatos del repositorio muestran lo que existe. ATC y las comprobaciones de S/4HANA señalan patrones estáticos que chocan con la versión objetivo. SCMON y SUSG muestran procedimientos ejecutados durante un periodo representativo. ST03N ayuda a relacionar transacciones y usuarios. El historial de SM37 expone rutas batch. Cuando hay modificaciones, SPAU y SPDD muestran dónde se apartó el cliente de SAP. Catálogos de interfaces, destinos RFC, configuración IDoc y calendarios de transferencia cubren las rutas fuera del diálogo.

No lo fusione todo demasiado pronto en una puntuación de riesgo. Conserve por objeto al menos identidad del repositorio, paquete, componente, último cambio, relaciones entre llamador y llamado, ejecución observada, proceso, datos tocados, hallazgo de simplificación, mecanismo de ampliación, prueba y responsable. Un objeto sin uso observado puede ser un informe anual. Una utilidad invocada a menudo puede tener poco riesgo porque solo da formato a fechas. Frecuencia y consecuencia son ejes distintos.

El código alcanzado indirectamente es la categoría incómoda. Un user exit llamado por el proceso estándar puede no aparecer como transacción nombrada en las estadísticas. Un módulo de funciones quizá solo se ejecute mediante un RFC externo. Una rutina de formulario puede seleccionarse por customizing. El análisis de dependencias debe empezar en puntos de entrada del negocio y recorrer llamadas, tablas, mensajes, trabajos e interfaces. Contar objetos aislados oculta los grupos que deben moverse juntos.

También incluyo los artefactos operativos. Variantes de trabajos, destinos de impresión, rutas lógicas, activadores de eventos, certificados y usuarios técnicos no son ABAP, pero el comportamiento reconstruido suele depender de ellos. Un equipo que declara terminado el código mientras Basis reconstruye estas dependencias durante el cutover no ha terminado la evaluación.

Compilar demuestra menos de lo que muchos esperan

Una comprobación sintáctica limpia demuestra que el compilador acepta el programa en el entorno nuevo. No demuestra que lea los mismos registros, aplique el mismo orden, contabilice los mismos documentos, respete los mismos bloqueos o termine dentro de su ventana batch. La compatibilidad es una puerta necesaria y una prueba de negocio débil.

S/4HANA cambia modelos de datos y ofrece vistas de compatibilidad en algunos lugares para facilitar la transición. Eso puede mantener lecturas antiguas mientras oculta un problema de arquitectura. El código que lee una vista puede devolver datos plausibles y, aun así, evitar la API publicada o el modelo semántico esperado. La decisión correcta puede ser sustituir el acceso, retirar la ruta personalizada o mantenerla temporalmente con una fecha de caducidad. Un ATC verde no puede tomar esa decisión.

El comportamiento implícito de la base de datos también genera falsa confianza. Considere una rutina antigua como esta:

SELECT * FROM vbap
  INTO TABLE @DATA(items)
  WHERE vbeln = @order_number.

READ TABLE items INDEX 1 INTO DATA(first_item).

Sin ORDER BY, la base de datos no promete qué fila aparece primero. Si el código posterior trata el índice uno como la posición más antigua, un cambio de base o de plan de ejecución puede alterar el resultado sin error sintáctico. La reparación no consiste en añadir un orden arbitrario hasta que pase una prueba. El equipo debe recuperar la regla de negocio pretendida, expresarla y probar límites como posiciones rechazadas, renumeradas o borradas.

SQL nativo, hints de base de datos, supuestos sobre tablas pooled o cluster, actualizaciones directas de tablas SAP y patrones amplios de SELECT * merecen atención, pero no completan la evaluación. Las llamadas dinámicas, las rutinas cargadas de field symbols y las sentencias generadas pueden eludir un seguimiento estático simple. Combine los hallazgos automáticos con lectura enfocada alrededor de entradas con consecuencias graves. El análisis estático da un mapa, no explica por qué se construyó la carretera.

Los user exits y BAdIs son contratos

Una implementación de ampliación no puede juzgarse solo por el código que contiene. Su contrato real incluye cuándo la llama SAP, qué datos están completos entonces, si las actualizaciones ocurren en diálogo o update task, qué excepciones maneja quien llama y qué lógica estándar posterior puede sobrescribir cambios. Un BAdI sustituto con un nombre parecido puede tener otro contrato.

Los user exits y customer exits clásicos suelen contener poco código con mucho peso de negocio. Unas líneas pueden derivar un centro de beneficio, rechazar un pedido, cambiar precios o dirigir una aprobación. Durante la evaluación registre activador, estado de entrada, efectos secundarios, errores y consumidor posterior de cada implementación. Después asígnela al punto recomendado para la versión exacta y el modelo de despliegue. No suponga que una opción on-premise existe igual en cada objetivo.

El consejo popular de sustituir cada exit por un BAdI de inmediato es demasiado burdo. Suena moderno y ofrece una métrica fácil, pero el contenedor no determina la calidad del diseño. Parte de la lógica pertenece a una ampliación in-app publicada, otra a un servicio side-by-side, otra a configuración estándar y otra debería desaparecer. Mover lógica opaca a un hook más nuevo conserva la opacidad.

Las modificaciones de objetos SAP necesitan una decisión aún más dura. Pregunte por qué existía la modificación, si SAP proporcionó después esa capacidad y si el negocio aún depende de la diferencia. El trabajo en SPAU no debe ser un ritual de reaplicar todo cambio histórico. Cada modificación recuperada aumenta la carga de futuras actualizaciones, por lo que su responsable debe defenderla con pruebas actuales y un test que falle sin ella.

Documente la decisión como contrato: dado este evento y estado de negocio, la ampliación debe producir estos cambios o este error y no alterar estos campos protegidos. Esa frase sirve tanto si el destino es ABAP como configuración, Go o un workflow fuera del núcleo.

Los datos de uso necesitan un calendario de negocio

La evidencia de ejecución es esencial, pero una ventana no es representativa solo por ser larga. Los entornos SAP contienen cierres trimestrales, impuestos de fin de año, inventarios anuales, precios estacionales, extractos de auditoría y trabajos que solo aparecen en operaciones excepcionales. Decidir que un código no se usa requiere calendario de negocio y responsable, no solo la última fecha de ejecución.

Use SCMON para recoger uso por procedimiento y SUSG para agregar resultados destinados al análisis. Combine esas pruebas con historial de carga, calendarios batch y monitorización de interfaces. El periodo debe incluir deliberadamente los eventos importantes. Si no puede incluir uno anual, inspeccione las pruebas de la ejecución anterior y entreviste a quien concilia su resultado.

Clasifique candidatos como conservar, cambiar, retirar o sin resolver. No borre código sin resolver para mejorar un panel. Retirar exige tres pruebas: ninguna ejecución relevante, ninguna entrada configurada o indirecta y un responsable de negocio que acepte la eliminación. Archive la decisión y las dependencias para resolver objeciones tardías sin reiniciar el descubrimiento.

El uso también ayuda a seleccionar pruebas. El código frecuente aporta mucho tráfico, pero las rutas raras y de alto impacto necesitan casos preparados. Una liberación de crédito o corrección fiscal poco usada puede merecer más pruebas que un informe abierto cada mañana. Priorice por daño de un resultado incorrecto, dificultad de detección y capacidad de recuperación.

Otra trampa es la lógica duplicada. Dos programas Z pueden calcular el mismo concepto de manera distinta en diálogo y batch. El análisis de ejecución ve dos objetos activos. El análisis de negocio debe ver una regla en disputa. Saque esos desacuerdos a la luz antes de migrar. Reescribir ambos fielmente conservaría un defecto del conocimiento organizativo.

Los hallazgos de simplificación necesitan decisiones

SAP Readiness Check, Simplification Item Catalog y las comprobaciones ATC aportan pruebas esenciales, pero cada hallazgo aún necesita interpretación local. Un elemento de simplificación avisa de un cambio técnico o funcional. No sabe si su programa es obsoleto, si una vía compatible sirve durante la transición o qué resultado debe sobrevivir.

Registre por hallazgo el objeto, proceso, tratamiento propuesto, mecanismo objetivo, prueba que demuestra la decisión y persona que la acepta. Evite cierres como "ajustado" o "no aplica" sin pruebas. Seis meses después nadie sabrá si "no aplica" significaba código inalcanzable, falso positivo, proceso retirado o supuesto nunca comprobado.

Una secuencia práctica es esta:

1. Ejecute comprobaciones ATC de la versión objetivo sobre todo el alcance personalizado, incluidas modificaciones y namespaces.
2. Una hallazgos con uso observado y grupos de dependencias, en vez de revisar objetos por orden alfabético.
3. Siga cada grupo de alto impacto hasta una entrada de negocio y un responsable.
4. Elija retirar, mantener temporalmente, adaptar o rediseñar, dejando escrita la razón.
5. Adjunte evidencia ejecutable: regresión, resultado conciliado, intercambio grabado o excepción aprobada.

Esta secuencia evita un fallo común: los desarrolladores cierran miles de hallazgos locales mientras el programa omite un proceso entre sistemas. El número de hallazgos mide una cola de trabajo, no preparación. Un grupo con doce hallazgos y una prueba de paridad conocida puede ser más seguro que una rutina de contabilización dinámica que ninguna herramienta resuelve.

Mantenga las exenciones limitadas y fechadas. Si un hallazgo permanece porque se admite una vista de compatibilidad durante la transición, nombre el supuesto de versión y la condición de retirada. Las excepciones permanentes sin registro de diseño se convierten en la arqueología del próximo equipo.

Las interfaces fallan en los límites de propiedad

Evaluar una interfaz exige cubrir protocolo, semántica de payload y acuerdo operativo. Los equipos suelen inventariar RFC, IDoc, API y archivos y dar una interfaz por entendida al conocer el endpoint. Los fallos viven en significados de campos, secuencia, duplicados, acuses y la reparación manual usada cuando un lado no está disponible.

Empiece con intercambios observados y configuración, no con el nombre del catálogo. Registre iniciador, horario o evento, autenticación, versión del payload, forma del volumen, timeout, reintentos, idempotencia, supuesto de orden y responsable de conciliación. Para archivos, incluya nombres, codificación, separadores, totales de control, directorios y archivo histórico. Para IDoc, conserve tipo de mensaje, tipo básico, extensiones, perfiles de interlocutor, estados y trabajos que reprocesan fallos. Para RFC, encuentre llamadores externos además de destinos SAP.

El ABAP personalizado suele exponer un contrato de datos por accidente. Un consumidor puede depender de un campo no documentado, un texto concreto, blanco frente a cero o el orden de filas. S/4HANA puede aportar una API publicada más limpia, pero cambiar de endpoint no borra esos supuestos. Compare contratos campo a campo y decida si adapta el consumidor, coloca compatibilidad en el límite o versiona el intercambio.

La conciliación merece su propia prueba. Una respuesta HTTP correcta o un estado IDoc verde demuestra entrega hasta una fase técnica. No demuestra que ambos sistemas aceptaran el mismo evento exactamente una vez. Defina la clave de negocio, los totales o estados que comparan los operadores, el retraso aceptable y cómo repetir un elemento sin duplicar una contabilización. Capture excepciones actuales porque el proceso de reparación puede contener reglas ausentes del programa.

Pido a los equipos recorrer un fallo completo. Suponga que ECC escribe cada noche un archivo de precios, lo transfiere a un almacén y archiva el original. La transferencia agota el tiempo después de que el receptor guarde el archivo, pero antes de que ECC registre éxito. El reintento manda otra copia. Si el receptor identifica archivos solo por el nombre de llegada, importa ambos y cambia dos veces la valoración. La migración debe conservar o mejorar la detección de duplicados, no reproducir solo el camino feliz. Una prueba de paridad debe ejercitar timeout, repetición y conciliación.

Las interfaces también condicionan el cutover. Si un sistema externo no acepta el contrato nuevo el mismo día, defina una coexistencia acotada y quién la retirará. Evite capas bidireccionales con propiedad de estado confusa. Parecen flexibles en un plan y se vuelven permanentes cuando nadie puede probar qué lado mantiene el registro autorizado.

Trate cada consumidor sin documentar como riesgo abierto. Busque registros de red y gateway, actividad de usuarios técnicos, recogida de archivos y pregunte a los operadores qué extractos mueven a mano. Haga explícito el contrato antes de cambiar el productor. El peor momento para descubrir que una pequeña base de escritorio consume un informe Z es después del primer cierre nuevo.

La paridad debe registrarse antes de reescribir

El mejor momento para capturar el comportamiento esperado es cuando ECC aún procesa trabajo real y finanzas, cadena de suministro y operaciones todavía concilian sus resultados. Una reescritura probada solo con ejemplos manuales perderá las combinaciones extrañas acumuladas en años de uso.

Construya un arnés de paridad alrededor de límites de negocio. En informes compare conjuntos ordenados y totales, con tolerancias documentadas para representaciones que cambian de forma legítima. En interfaces grabe solicitudes, respuestas, IDoc, archivos y efectos, y reproduzca casos saneados contra el destino. En contabilizaciones compare tipos de documento, imputaciones, importes, divisas, impuestos, transiciones y mensajes de error que necesitan los operadores. Enmascare datos sensibles sin destruir las combinaciones que gobiernan la lógica.

Un registro de caso útil puede ser sencillo:

{
  "case_id": "sales-order-credit-hold",
  "entry_point": "order_create",
  "input_ref": "fixture/credit-hold-017.json",
  "expected": {
    "status": "HELD",
    "posted_documents": 0,
    "message_id": "ZCREDIT-014"
  }
}

Los identificadores son ilustrativos, pero la forma obliga a decir qué cuenta como igual. Añada precondiciones y efectos protegidos cuando haga falta. Guarde el resultado bruto y la comparación normalizada para que los revisores vean qué ignoró el arnés. Si la normalización elimina timestamps, orden o identificadores generados, documente por qué esas diferencias no tienen significado de negocio.

El tráfico grabado requiere selección. Rara vez hace falta repetir cada llamada, y el volumen bruto puede sobrerrepresentar casos felices. Elija clases de equivalencia, importes límite, combinaciones poco comunes, errores y cada rama regulatoria o contractual conocida. Añada casos para reglas halladas al leer el código aunque no aparecieran durante la captura.

La paridad no exige conservar una mala arquitectura. Fija el comportamiento externo significativo y permite mejores límites y propiedad de datos. CodeHero aplica este enfoque al reescribir ABAP: su plataforma lee todo el árbol y un arnés compara el sistema nuevo con tráfico de producción mientras cambia la arquitectura. El arnés apoya la aceptación, no el parecido entre fuentes.

Parte del ABAP no debe mudarse a S/4HANA

Una migración permite reducir el núcleo personalizado, pero "clean core" no ordena mover todo programa dudoso a otra plataforma. La ubicación depende del comportamiento, límite transaccional, propiedad de datos, latencia y soporte. Mover una validación muy acoplada a un servicio remoto puede añadir modos de fallo sin crear un límite útil.

Mantenga lógica cerca del núcleo cuando deba participar sincrónicamente en una transacción SAP y exista una ampliación publicada con el contrato necesario. Sáquela cuando posea una capacidad distinta, pueda operar mediante API o eventos publicados y se beneficie de un ciclo independiente. Sustituya código por S/4HANA estándar cuando el negocio acepte la regla. Retírelo cuando las pruebas indiquen que el proceso ya no existe.

El lenguaje objetivo es secundario. Go puede servir para servicios con interfaces y operación claras. Rust puede servir para núcleos numéricos donde importan corrección y control. TypeScript puede servir para clientes y workflows. Ninguno repara un contrato de negocio ausente. Si un equipo no puede decir qué debe hacer una rutina ABAP, traducirla a un lenguaje de moda solo encarece la incertidumbre.

Desconfíe del código remoto que trata las tablas SAP como su base privada. Extraer un programa Z manteniendo acceso directo crea un monolito distribuido con fallos de red añadidos. Defina contrato de API o evento, propietario del estado, reintentos e idempotencia y pruebe fallos parciales. Un diagrama limpio sin conciliación no es un diseño terminado.

También hay un límite humano. Los especialistas ABAP conocen excepciones que los arquitectos descartan como deuda técnica. Júntelos con propietarios de procesos e ingenieros del destino. No hace falta conservar cada implementación, pero no se debe perder su conocimiento antes de que la regla tenga otro hogar.

El entregable debe permitir decidir continuar o parar

Una evaluación creíble muestra qué se puede retirar, adaptar o rediseñar, qué sigue desconocido y qué pruebas sostienen cada afirmación. También permite a un ingeniero rastrear un riesgo hasta objetos, dependencias, tráfico y tests. Si cualquiera necesita una historia oral aparte, el entregable está incompleto.

Organice por capacidad de negocio y grupo de dependencias, no por miles de objetos. Para cada grupo muestre alcance, entradas actuales, uso, simplificaciones, datos e interfaces, destino, cobertura de paridad, responsable y decisiones abiertas. Estime y secuencie por grupo porque los objetos de contabilización o cumplimiento rara vez migran solos.

Fije criterios de salida explícitos. Cada objeto debe pertenecer a un grupo o conjunto de retirada justificado. Cada grupo de alto impacto necesita destino y responsable. Cada comportamiento retenido necesita una fuente de prueba. Cada asunto abierto necesita fecha y pruebas para cerrarlo. Así se expone la incertidumbre en vez de esconderla en un porcentaje.

No deje que el programa cierre el descubrimiento sin pruebas de producción. Registre ahora tráfico representativo, salidas conciliadas y ejecuciones excepcionales mientras ECC está disponible y se considera fiable. Las comprobaciones estáticas pueden repetirse. Una rama anual o un llamador externo olvidado quizá no se puedan recuperar cuando se necesiten.

El plazo de 2027 es real porque las opciones de mantenimiento se reducen y encarecen, pero el pánico no sirve para planificar. La acción inmediata es precisa: autorizar captura de ejecución, fijar un formato de inventario, elegir el primer grupo de negocio de alto impacto y registrar su comportamiento. Con esas pruebas, arquitectura, coste y calendario se convierten en decisiones de ingeniería en vez de conjeturas.

Presupueste la incertidumbre, no solo la reparación conocida. Reserve capacidad de decisión para objetos sin responsable, llamadas dinámicas, informes irreproducibles e interfaces con consumidores desconocidos. No son cabos administrativos. Ahí cambia tarde el alcance cuando alguien descubre por fin qué hace el código.

Mantenga las pruebas bajo control de versiones y actualícelas cuando el programa cambie ECC. Un transporte urgente, una variante de trabajo revisada o un cambio de interfaz después de la captura puede invalidar mapa y tests. Imponga una regla: todo cambio productivo durante la migración debe indicar el grupo, la decisión y los casos de paridad que afecta. Así la referencia no se aparta en silencio del sistema real.

Por último, ensaye el proceso de decisión tanto como el software. Entregue a los responsables un grupo realmente ambiguo y exija elegir destino, aprobar el comportamiento retirado y aceptar la prueba de paridad. Si nadie tiene autoridad durante la evaluación, el mismo asunto esperará en una reunión de cutover con menos tiempo y peores opciones.