Una migración de SAP ECC a S/4HANA se mide en trimestres, a menudo en años, y el negocio no deja de pedir cosas mientras tanto. La pregunta práctica no es si migrar, porque casi siempre es la mejor alternativa, sino qué hacer con la demanda que llega durante la migración. Mi respuesta es trabajar en dos pistas. El equipo de SAP mantiene a flote el core y conduce la migración. En paralelo, un equipo de soluciones responde a las necesidades de hoy con piezas escalables y desacopladas que viven fuera del ERP, consumen SAP a través de una capa de integración y están diseñadas para sobrevivir al cambio de versión. Lo que separa este modelo de la TI en la sombra es una sola condición: nada de lo que construye la segunda pista puede agregarle trabajo a la primera. Con el mantenimiento estándar de ECC terminando a finales de 2027, esa disciplina decide si las soluciones de hoy ayudan a la migración o la estorban.
Este artículo es el lado organizacional de extender un SAP ECC de 20 años sin exponerlo, donde explico la arquitectura de la capa de integración.
¿Por qué el negocio no puede esperar a S/4HANA?
El escenario es frecuente en empresas medianas de la región. Un SAP ECC que durante años no recibió la inversión que necesitaba acumula cerca de dos décadas de obsolescencia tecnológica y deja de responder a lo que el negocio pide: no tiene APIs para los canales digitales, cada cambio exige desarrollo ABAP y el equipo que lo conoce es pequeño y está ocupado. La decisión correcta, migrar a S/4HANA, llega tarde para las necesidades que ya están sobre la mesa.
Y la migración empeora el problema a corto plazo, por una razón que desde fuera casi nunca se ve.
El doble mantenimiento
Durante un proyecto de migración, cada cambio que se hace en el ECC productivo hay que repetirlo en el sistema que se está construyendo. Es lo que los equipos SAP llaman retrofit o doble mantenimiento, y por eso es habitual congelar los cambios funcionales en el sistema viejo. Cuando el equipo de SAP se resiste a un desarrollo nuevo en plena migración no está siendo lento: está protegiendo el proyecto más importante de la empresa.
El resultado es una pinza. El sistema no puede cambiar, el negocio no puede esperar, y la demanda va a ir a algún lado.
Las tres respuestas que no funcionan
| Respuesta | Qué pasa en el negocio | Qué pasa con la migración |
|---|---|---|
| «Esperen a S/4HANA» | Cada área resuelve por su cuenta: hojas de cálculo, SaaS contratado sin TI, integraciones improvisadas | Hereda sistemas en la sombra que nadie inventarió |
| Pedir desarrollos Z al equipo de SAP | Algunas necesidades se atienden, tarde | El equipo se satura, crece el doble mantenimiento y el proyecto se retrasa |
| Construir fuera de SAP sin reglas | Respuestas rápidas | Lecturas directas a tablas, lógica duplicada y un legacy nuevo que la migración tendrá que desenredar |
Las tres tienen algo en común: tratan la migración y la demanda del negocio como problemas separados. No lo son. Lo que se construya hoy para el negocio forma parte del alcance real de la migración, se reconozca o no.
¿Cómo funcionan las dos pistas?
El modelo de dos pistas separa el trabajo sobre el core del trabajo sobre las necesidades del negocio, y los une con un contrato explícito en lugar de con buena voluntad.
La pista SAP
Estabilidad del ECC productivo, parches y notas de seguridad, soporte a la operación y la migración a S/4HANA. Es también la única pista que decide qué cambia dentro del core.
La pista de soluciones
Portales B2B, integraciones con canales digitales, analítica, automatizaciones y casos de IA. Todo vive fuera del ERP, en infraestructura propia (en mi caso, servicios serverless en AWS, con el criterio que explico en cómo diseño plataformas empresariales), y consume SAP únicamente a través de la capa de integración.
Lo que comparten
Un catálogo de capacidades (qué datos y operaciones de SAP están disponibles para las soluciones), un presupuesto de carga sobre el ERP y un inventario de dependencias. Esos tres artefactos son el contrato entre pistas.
No es TI bimodal
Hace más de una década, Gartner popularizó la idea de TI bimodal: un modo estable y predecible, y otro rápido y experimental. La crítica que recibió fue justa, porque en la práctica creó dos clases de equipos, uno visto como legado y otro como innovación. Las dos pistas no son eso. La pista SAP no es la lenta: sostiene el sistema del que depende todo lo demás y conduce el proyecto de mayor riesgo de la empresa. La diferencia entre pistas es de responsabilidad, no de velocidad ni de prestigio.
¿Qué reglas evitan que la segunda pista estorbe a la primera?
Sin reglas, la pista de soluciones es TI en la sombra con mejores herramientas. Estas son las seis que aplico, y cada una existe para proteger la migración.
- Cero cambios en el core por pedido de una solución. Si una solución necesita algo que SAP no expone, se diseña como capacidad genérica y entra en la planificación del equipo de SAP, no como urgencia.
- Nada de acceso directo. Ninguna solución llama RFC ni lee la base de datos de SAP por su cuenta. Todo pasa por la capa.
- SAP sigue siendo la verdad. Las soluciones no recalculan precios, stock ni crédito. Si necesitan el dato, lo consultan o usan una réplica con fecha de corte.
- Lectura por defecto, escritura con acuerdo. Consultar es la norma. Escribir en SAP (crear un pedido, actualizar un maestro) requiere acuerdo con el equipo de SAP y pasa por comandos asíncronos con idempotencia.
- La carga sobre SAP la fija el equipo de SAP. Cuántas llamadas simultáneas puede recibir el ERP es una decisión de quien lo opera. La capa la hace cumplir con concurrencia reservada y límites por consumidor.
- Cada dependencia queda inventariada. Qué función RFC, qué IDoc o qué extracción usa cada solución, y para qué.
La sexta regla merece un apartado propio.
El inventario de dependencias es un regalo para la migración
Uno de los trabajos más costosos de una migración es descubrir quién depende de qué. Interfaces que nadie documentó, reportes que leen tablas directamente, integraciones que un proveedor instaló hace años. Cada sorpresa aparece tarde, en pruebas o después del go-live.
Una pista de soluciones disciplinada entrega lo contrario: una lista completa y actualizada de todo lo que sus soluciones consumen de SAP, con el mecanismo y el propósito de cada dependencia. Para el equipo de migración, ese inventario es trabajo ahorrado. Y cambia la relación entre equipos: la pista de soluciones deja de ser un riesgo que vigilar y pasa a ser una fuente de información para el proyecto.
¿Cómo se diseña hoy algo que sobreviva a la migración?
La pregunta de diseño no es «¿funciona con ECC?», sino «¿qué habrá que tocar cuando SAP ya no sea ECC?». La respuesta depende de dónde se acopla la solución.
Las tablas de ECC no sobreviven igual
Leer tablas de ECC directamente, por replicación de base de datos o con consultas SQL, parece la ruta más rápida. Es también la que peor envejece, porque S/4HANA cambió el modelo de datos en áreas centrales:
| Área | En ECC | En S/4HANA |
|---|---|---|
| Inventario | Documentos de material y stock repartidos en varias tablas (MSEG, MARD y otras) | Una tabla central, MATDOC; el stock se calcula desde ella y varias tablas antiguas quedan como vistas de compatibilidad |
| Finanzas | Documentos en BKPF y BSEG, con tablas de índices como BSIS o BSAS | Diario universal en ACDOCA; las tablas de índices pasan a ser vistas de compatibilidad |
| Ventas | Estados del documento en VBUK y VBUP | Los estados pasan a VBAK y VBAP; VBUK y VBUP desaparecen |
| Precios | Condiciones del documento en KONV | Condiciones en PRCD_ELEMENTS |
Una vista de compatibilidad puede hacer que una consulta vieja siga devolviendo datos, pero no está pensada como base para desarrollos nuevos y no garantiza el mismo rendimiento. Cada lectura directa de tablas es, en la práctica, una línea más en el plan de pruebas de la migración.
Dónde conviene acoplarse
| Decisión de hoy | Qué hay que tocar al migrar |
|---|---|
| Leer tablas de ECC desde la solución | La solución: consultas, transformaciones y validación de datos |
| Llamar BAPIs desde la solución | La solución: cada llamada y cada estructura |
| Llamar BAPIs desde un adaptador de la capa | Solo el adaptador; la solución no cambia |
| Consumir un contrato de la capa | Nada en la solución |
La última fila es el objetivo. No es gratis: alguien tiene que rehacer el adaptador. Pero ese trabajo queda concentrado, es estimable y lo hace quien conoce ambos lados, en lugar de quedar repartido entre soluciones que construyeron equipos distintos.
Enrutar por capacidad durante la transición
Si la migración se hace por fases, la capa permite algo más: dirigir cada capacidad al sistema que corresponda en cada momento. El stock puede seguir leyéndose de ECC mientras los precios ya salen de S/4HANA, y las soluciones no notan la transición. Es el patrón strangler fig que describió Martin Fowler, aplicado a la frontera entre el ERP y los canales. En una conversión técnica con un único corte no hay convivencia, pero el beneficio de fondo se mantiene: el día del corte cambian adaptadores, no soluciones.
¿Cómo se gobierna la relación entre los dos equipos?
La fricción entre pistas es previsible y, en parte, racional. El equipo de SAP ve en la pista de soluciones un riesgo: más carga sobre un sistema frágil, más superficie de seguridad y la sospecha de TI en la sombra. El equipo de soluciones ve en SAP un cuello de botella. Los dos tienen razón desde su lugar, y por eso la relación no puede depender de la buena sintonía entre personas.
| Decisión | Pista SAP | Pista de soluciones |
|---|---|---|
| Cambios dentro del core | Decide y construye | Propone la capacidad |
| Límites de carga sobre SAP | Los fija | Los hace cumplir y los monitorea |
| Qué datos se exponen | Valida origen y significado | Diseña y versiona el contrato |
| Operación de la capa | Recibe las alertas que la afectan | Responsable |
| Inventario de dependencias | Lo usa en la migración | Lo mantiene al día |
Un acuerdo así se firma más fácil con evidencia que con presentaciones. La primera solución bien construida, dentro de los límites, sin tocar el core y con su dependencia inventariada, convence más que cualquier propuesta de modelo operativo. Es la misma lógica que describí en construir evidencia antes del consenso.
¿Qué riesgos tiene este modelo?
- Volverse TI en la sombra. Si las reglas se relajan «solo esta vez», la pista de soluciones termina haciendo exactamente lo que prometía evitar.
- Duplicar la verdad. Cada regla de negocio reimplementada fuera de SAP es una segunda fuente de verdad que discrepará en el peor momento.
- Quitarle urgencia a la migración. Es el riesgo menos visible y el más serio. Cuando los canales digitales ya funcionan, alguien en la dirección preguntará si la migración sigue siendo necesaria. Lo es: la capa extiende el ERP, no lo moderniza, y no resuelve el fin del soporte, la obsolescencia técnica ni los procesos internos que viven dentro de SAP. Hay que decirlo desde el primer día y repetirlo cada vez que una solución sale bien.
- Una capa sin dueño. Si nadie la opera después de la migración, la capa se convierte en el legacy de la próxima década.
Mantener a flote y construir hoy no compiten
El equipo que mantiene a flote el core y el equipo que responde a las necesidades de hoy trabajan para el mismo objetivo con horizontes distintos. Uno protege el sistema del que depende la empresa y lo lleva a su siguiente versión. El otro evita que el negocio se detenga mientras eso ocurre.
El éxito del modelo se mide el día del go-live de S/4HANA. Si los canales digitales no notan el cambio y la migración heredó un inventario en lugar de una sorpresa, las dos pistas hicieron su trabajo.
Si tu organización está en plena migración de SAP y el negocio no puede esperar a que termine, y quieres contrastar cómo organizar las dos pistas, puedes escribirme por LinkedIn.