SAP ECC termina en 2027: el riesgo son sus integraciones

La fecha que no se mueve

El soporte estándar de SAP Business Suite 7, la versión en la que corre SAP ECC 6.0, termina el 31 de diciembre de 2027. No es una recomendación ni una hoja de ruta sujeta a cambios: SAP confirmó que su mantenimiento principal sigue hasta ese día, con una opción de mantenimiento extendido hasta 2030 a costo adicional. Después de esa fecha, correr software crítico sin contrato de soporte significa no recibir parches de seguridad nuevos, algo que para casi cualquier empresa es un riesgo inaceptable.

La versión 2027 llega igual para todos: la empresa que ya planea migrar y la que todavía no lo ha puesto en el roadmap. La diferencia es cuánto margen le queda a cada una.

El reloj ya está corriendo

El problema no es la fecha en sí, sino lo que toma cumplirla. Según el análisis de Incorta sobre el fin de soporte de ECC, la mayoría de las migraciones a S/4HANA toman 12 a 24 meses, y los proyectos completos corren 18 a 36 meses una vez que se incluyen los datos y las integraciones.

Hagamos la cuenta: si una migración completa puede tomar tres años, una empresa que decide empezar a fines de 2026 ya está apretada. "Algún día lo hacemos" se convirtió, en la práctica, en una decisión que hay que tomar este trimestre.

La urgencia tiene respaldo. El 60% a 70% de la base de soporte de SAP todavía no había migrado a la nube, según datos de Morgan Stanley citados por CIO.com, y aproximadamente la mitad de los CIOs encuestados por esa firma planea modernizar su ERP en los próximos años. No es una ola que esté por empezar: está en marcha y la fecha límite la empuja.

El susto real no es el ERP: son las costuras

Acá está el punto que casi nadie pone en el presupuesto. Migrar el ERP cambia su modelo de datos. Y cuando cambia el modelo de datos del ERP, no solo se rompen los reportes: se rompen las interfaces con todo lo que estaba conectado a él.

El CRM que alimentaba el pipeline comercial, la pasarela de pagos que conciliaba cobros, el POS que reportaba ventas, el e-commerce que sincronizaba inventario, el sistema heredado que nadie documentó nunca. Todas esas conexiones funcionaban. Por eso nadie las cotizó: llevaban años en marcha y parecían parte del paisaje. El problema es que la mayoría se armó a mano, con conectores punto a punto, sin dueño y sin contrato.

Migrar el ERP es el momento en que esas costuras se prueban todas a la vez. Y cuando una interfaz no documentada falla en la fase de pruebas, el negocio no se detiene: sigue operando a ciegas, con reportes que no actualizan y datos que dejaron de cuadrar, mientras el equipo corre detrás de cada rotura.

Qué hacer antes de tocar el ERP

La buena noticia es que estas interfaces se pueden mapear antes de empezar. Un plan de preparación, en cuatro pasos:

1. Inventariar cada interfaz que toca el ERP. Qué sistema se conecta, qué dato intercambia, quién lo construyó y quién lo sostiene hoy. Si el dueño es "el que estaba antes que yo", ya encontró el primer riesgo.
2. Listar los reportes que el negocio usa a diario. Finanzas, operaciones y dirección trabajan sobre reportes que viven en el modelo de datos viejo. Si no están identificados, se descubre su rotura el día que alguien necesita el número.
3. Definir cuántos años de historia hay que conservar y dónde. Los datos históricos se vuelven difíciles de alcanzar tras la migración. Decidir qué se conserva y cómo se consulta es una decisión de negocio, no un detalle técnico.
4. Planear cómo el negocio sigue operando durante la migración. Una capa de datos sobre ECC y S/4HANA permite que la operación trabaje con datos vivos mientras el cambio avanza, en vez de esperar a que todo termine.

Estos cuatro pasos son lo que separa una migración controlada de una sorpresa trimestral.

Por qué esto no es postergable

Hay una razón adicional para no dejar la migración para el final: cada capacidad nueva que la empresa quiera sumar depende de que el core esté en orden. Como resume So Chan, de Deloitte, citado por CIO.com, con los sistemas ERP heredados hay que modernizar el núcleo antes de apilar capacidades de inteligencia artificial encima. La migración del ERP no es un gasto: es un catalizador.

Es el mismo patrón que ya aparece en otras partes del stack. En una empresa de 50 a 500 empleados con TI interno, el equipo está enfocado en el roadmap del producto, y las integraciones entre ERP, CRM, pagos y e-commerce se resolvieron cuando hicieron falta, sin arquitectura que las gobierne. La migración forzada es, precisamente, el momento en que esos huecos se cobran todos juntos.

La ventana que se cierra

Ninguna de estas fuentes mide Latinoamérica en particular, así que no vamos a inventar cifras regionales: los datos describen una tendencia global. Pero el patrón golpea con más fuerza donde el equipo interno ya está al tope de su capacidad, que es exactamente el caso de las empresas medianas de la región.

La migración de 2027 es, al mismo tiempo, una amenaza y una oportunidad. La amenaza es conocida: la fecha y los parches. La oportunidad es menos obvia: es la única vez en una década en que la empresa va a revisar, una por una, todas las conexiones que sostienen su operación. Quien aprovecha esa ventana cierra 2027 con un stack documentado y dueños claros. Quien la deja pasar, termina con un ERP nuevo y los mismos cables frágiles encima.

Ese trabajo de mapear, decidir y ordenar las costuras entre sistemas es exactamente el que Byxel firma bajo su modelo de Ingeniería de Autor: definir qué interfaces existen, quién responde por cada una y cómo se sostienen antes de que el reloj llegue a cero.

Para seguir leyendo: las integraciones que nadie cotizó, el costo de mantener sistemas conectados a mano y por qué la deuda de integración es un pasivo que crece.

¿Su equipo está corriendo SAP ECC y la fecha de 2027 ya entró en el roadmap? Antes de firmar una migración, mapeemos juntos las integraciones que el proyecto va a destapar. Escribinos por WhatsApp y agendamos una revisión de 30 minutos de su stack actual.