🧨 SAPocalypsis Now — Episodio 9

Alonso llevaba ya demasiados años en aquella empresa.

Lo suficiente como para saber que allí nada se hacía sin improvisar.

Había sobrevivido a upgrades imposibles, a clientes cambiando requerimientos en plena UAT, y a más DUMPs de los que podría recordar.

Pero esta vez era distinto: la migración a S/4HANA era, supuestamente, el gran salto a la modernidad.

Por primera vez en años, veía ilusión en los correos, reuniones bien planificadas y hasta un calendario de entregas que parecía serio.

Él mismo se ofreció como responsable técnico del proyecto.
Sabía que la clave sería la documentación, la coordinación y la paciencia.

⚙️ Todo bajo control

Durante meses, Alonso y su equipo trabajaron meticulosamente.

Se reunían casi a diario con los de Basis para coordinar los sistemas, las versiones de kernel y los stacks de soporte.

En paralelo, los de desarrollo revisaban las notas necesarias y gestionaban los paquetes de transporte a través de la SPAU, asegurándose de que cada conjunto de objetos pasara por los entornos correctos y en el orden debido.

La estrategia era clara: migración Brownfield por fases.

Primero Finanzas, luego Logística, después Recursos Humanos.

Nada de hacerlo todo a la vez.

Durante semanas, Alonso revisó cada objeto Z que debía adaptarse, cada tabla que podía verse afectada, cada dependencia de código que debía limpiarse antes del salto.

Y aun así, algo lo inquietaba.

El cliente (un clásico) insistía una y otra vez:

Ese report Z de hace diez años tiene que seguir funcionando igual.

Alonso lo explicaba con calma:

En S/4HANA, eso no es compatible. Podemos rehacerlo, pero no migrarlo tal cual.

Pero el cliente era tozudo:

No quiero rehacer nada. Solo pásalo.

Así que, entre reuniones y tickets, el Clean Core empezó a desvanecerse.
Z tras Z, función tras función, los desarrollos personalizados se arrastraban a S/4 como viejos fantasmas del pasado.

💼 La oferta inesperada

Cuando ya todo estaba casi listo para ejecutar la primera fase, Alonso recibió la llamada.

Una oportunidad que llevaba esperando años:
un puesto estable, bien pagado, en una multinacional que valoraba su experiencia y su criterio.

Intentó retrasar su incorporación.
Quería terminar al menos la primera fase.
Pero no había margen.

Habló con sus superiores y con el equipo.
Explicó su situación, y todos lo felicitaron sinceramente.

Los jefes incluso intentaron hacerle una contraoferta.
Pero era ridícula.

Con la confianza de quien ya no tiene nada que perder, Alonso fue claro:

Mi recomendación es que esperéis a continuar la migración hasta tener a alguien con experiencia en proyectos de este tipo. No es algo para improvisar.

Le respondieron con una sonrisa confiada:

Tranquilo, Alonso. Patricia se hará cargo. Es muy buena, y en dos semanas se pondrá al día contigo.

Alonso conocía a Patricia.
Era buena técnica, sí, metódica, responsable… pero sin experiencia real en migraciones.
Aquello era otra liga.

📚 Quince días de infierno

Durante los quince días siguientes, Alonso prácticamente no durmió.
Le enseñó a Patricia todo lo que pudo:

• Cómo revisar los pre-checks de compatibilidad.

• Cómo buscar y aplicar notas de corrección mediante la SPAU.

• Cómo preparar un paquete de transporte de forma ordenada.

• Cómo actuar ante un short dump o un update termination.

• Y sobre todo, cómo identificar si un problema venía del nuevo entorno o de un viejo desarrollo Z.

Patricia aprendía rápido, pero no era suficiente.
Aquel sistema tenía demasiados esqueletos en el armario.

El último día, Alonso le dejó un mensaje antes de irse:

No te agobies si algo falla. Respira. Mira el log. Y recuerda: nunca subas una release sin revisar las dependencias. La SPAU es tu amiga.

Y con eso, se fue.

🔍 El comienzo de la migración

Las primeras semanas sin Alonso transcurrieron con aparente normalidad.

Se liberó la fase de Finanzas, y durante días, el sistema se comportó bien.

Hasta que empezaron los primeros avisos.

Pequeños, casi invisibles.

Un usuario de Contabilidad reportó que al ejecutar FBL1N a veces aparecía un DUMP.

Otro, en Tesorería, dijo que al contabilizar un documento en FB03, el sistema se cerraba inesperadamente.

Los errores no eran constantes.

A veces se producían, a veces no.

Y muchos usuarios, acostumbrados a convivir con rarezas del sistema, simplemente encontraban atajos para hacer lo mismo por otra vía.

No fue hasta que llegó el cierre contable cuando todo saltó a la luz.

El equipo de Finanzas, al necesitar ejecutar los reportes masivos, se topó con los DUMPs de lleno.

El sistema devolvía un error en bucle, provocado por incompatibilidades en estructuras CDS y campos obsoletos que el código Z seguía intentando leer.

El infierno había empezado… discretamente.

🧩 Parches y más parches

Patricia y su equipo se volcaron en solucionar los problemas.

Muchos provenían de desarrollos antiguos que el cliente se había negado a reescribir.

Al analizar el código, descubrieron lo que Alonso había advertido:

llamadas directas a tablas que ya no existían, estructuras reemplazadas, BAPIs obsoletas, y macros que no tenían sentido en S/4.

No había tiempo de rediseñar.
Así que se optó por comentar temporalmente las secciones de código conflictivas.

Los DUMPs dejaron de aparecer, pero enseguida comenzaron los reclamos:

Oye, este informe ya no muestra el desglose por sociedad.

Antes podía ver las facturas pendientes por proveedor, ahora no sale nada.

Esto antes funcionaba.

Patricia lo sabía.

Todo lo que estaban haciendo era tapar agujeros, no resolverlos.
Pero no había alternativa.

💣 El error invisible

Mientras el equipo intentaba mantener el sistema estable, llegó la segunda fase: Logística.

Los transportes estaban listos, y el plan parecía sólido.

Sin embargo, al revisar las dependencias en la SPAU, Patricia notó algo raro:
un conjunto de órdenes que no debía estar asociado a esa fase.

Archivos antiguos, posiblemente mezclados con la versión anterior de pruebas.

Pensó en detener la subida.

Pero el cliente presionaba.

Hay que liberar ya, no podemos retrasar más el proyecto

Así que dio el visto bueno.

Durante los primeros días, todo pareció funcionar.

Los procesos de ventas corrían, las entregas se generaban, los stocks se movían.

Pero en el fondo, algo se estaba acumulando.

Errores silenciosos.

Datos inconsistentes que no se detectaban hasta que los procesos cruzaban módulos.

Un pedido de ventas con datos truncados en cabecera. Un albarán sin referencia a sociedad.

Un movimiento de mercancía que no encontraba la cuenta de contrapartida.

Los DUMPs volvieron, pero esta vez más esporádicos y más traicioneros.

No tumbaban el sistema… lo iban corrompiendo poco a poco.

🧨 El derrumbe silencioso

A la tercera semana, el caos se hizo visible.

El sistema de integración con FI comenzó a lanzar errores en cascada.

Los documentos contables se generaban con datos incompletos.

Los lotes de job colgaban en SM37.

Los logs de actualización se acumulaban en SM13.

Y lo peor: nadie sabía exactamente qué versión del transporte se había liberado en producción.

Las órdenes en la SPAU estaban cruzadas, los logs incompletos, los objetos mezclados.

Patricia pasó dos noches sin dormir, intentando recomponer el orden de los paquetes.

Sabía que si restauraban sin control, podían perder semanas de trabajo.

Pero el sistema ya no era estable.

Los jefes, viendo la magnitud del problema, llamaron a una consultora externa.

Un equipo especializado en recuperación de entornos S/4HANA entró en escena.

Tardaron cinco días en estabilizar el sistema. Cinco días de pérdidas, de correos urgentes, de usuarios bloqueados. Cinco días en los que Patricia apenas habló.

☀️ El día después

Cuando todo volvió a la normalidad, Patricia respiró.

Había sobrevivido.

Nadie la culpó.

Todos sabían que el fallo no había sido técnico, sino de gestión.

De no respetar el ritmo que Alonso había previsto.

Poco después, Alonso, desde su nueva empresa, le escribió un correo:

Patricia, me he enterado. No fue culpa tuya. S/4 enseña rápido, y a veces duele.
Si alguna vez quieres cambiar de aires, aquí hay sitio para ti.

Semanas más tarde, Patricia aceptó.

Cuando se reencontraron, Alonso bromeó:

¿Ya no sueñas con DUMPs?

Ella rió cansada.

No… pero cada vez que veo la SPAU, me tiembla el ojo.

📚 Moraleja

En una migración, los sistemas no se rompen de golpe.
Se desmoronan poco a poco, entre notas mal aplicadas, órdenes mezcladas y código que nadie se atrevió a limpiar.

El Clean Core no es una moda, es una advertencia.

Porque en SAP, cada línea Z que arrastras al futuro es una pesadilla esperando su turno para volver.