Guía de migración a SAP S/4HANA para empresas medianas en México

Si tu empresa corre sobre SAP ECC, ya tienes una fecha en el calendario aunque no la hayas puesto tú. El mantenimiento estándar de SAP Business Suite 7, que incluye SAP ERP 6.0, termina el 31 de diciembre de 2027. No es una campaña de ventas: es el calendario oficial de SAP. La pregunta ya no es si vas a migrar a S/4HANA, sino cuándo y por qué ruta. Esta guía te da lo que necesitas para tomar esa decisión con criterio, sin depender de que un proveedor te la explique a medias.

Está escrita para la empresa mediana mexicana: la que tiene un ECC que lleva años funcionando, un equipo de TI pequeño y una dirección que quiere saber en qué se está metiendo antes de aprobar un presupuesto. Vamos por partes.

Qué cambia de verdad entre ECC y S/4HANA

S/4HANA no es una versión más de SAP. Corre obligatoriamente sobre la base de datos en memoria HANA, y eso cambia cosas de fondo. El modelo de datos se simplifica: tablas que en ECC existían para acelerar consultas desaparecen porque HANA calcula al vuelo. Finanzas y controlling se unifican en una sola tabla de asientos, el Universal Journal. Materiales cambia su modelo de inventario y valuación.

Para el usuario, lo más visible es Fiori, la interfaz web que reemplaza buena parte de las pantallas clásicas de SAP GUI. Para TI, lo más visible es que algunos de tus programas Z van a dejar de compilar, porque usan tablas o campos que ya no existen. Ese es el corazón del trabajo de una migración: no mover datos, sino resolver todo lo que el cambio de modelo rompe.

La tabla resume lo que más pesa en el día a día.

Las fechas que mandan en tu decisión

Hay tres fechas que conviene tener claras. El mantenimiento estándar de tu ECC termina el 31 de diciembre de 2027. Existe un mantenimiento extendido opcional, con un costo adicional sobre la cuota que ya pagas, hasta el 31 de diciembre de 2030. Y S/4HANA tiene soporte comprometido hasta 2040, así que a donde llegues no te vuelve a caducar en el corto plazo.

Lo importante de esas fechas no es el día exacto. Es que una migración seria toma meses de planeación y ejecución, y que hay una sola fecha límite compartida por toda la base instalada. Empezar en 2027 es empezar tarde. Empezar hoy te deja elegir la ruta con calma en lugar de tomar la que quede disponible.

Las tres rutas y cómo se elige entre ellas

Hay tres formas de llegar a S/4HANA. No compiten entre sí: resuelven situaciones distintas.

Greenfield es una implementación nueva. Se define el modelo de procesos desde cero y se cargan solo los datos maestros y los saldos que hacen falta. Conviene cuando tu ECC arrastra tanta personalización y deuda funcional que rehacerlo cuesta menos que arreglarlo, o cuando el negocio quiere estandarizar procesos de una vez.

Brownfield es una conversión del sistema actual. Conserva procesos, configuración e histórico; lo que cambia es la plataforma. Es la ruta más corta cuando la instalación está sana y no quieres abrir una discusión de procesos ahora. Hereda lo bueno y lo malo: si tu modelo actual estorba, después de convertir seguirá estorbando.

Bluefield, o enfoque selectivo, es el punto medio. Se levanta un sistema nuevo y hacia él se migran de forma selectiva las sociedades, los procesos y el histórico que valen la pena. Sirve para instalaciones grandes con partes muy distintas, o cuando quieres soltar unidades que ya no operan. Su costo es la complejidad de decidir, objeto por objeto, qué viaja y qué se queda.

Escribimos una guía aparte solo para elegir entre las tres, con los criterios en detalle. Aquí lo esencial: la ruta se decide después de mirar el sistema, no en una junta. Un diagnóstico honesto revisa tus desarrollos, tus datos y tus integraciones, y de ahí sale la recomendación.

Cómo se ve un proyecto real, por fases

Independientemente de la ruta, un proyecto de migración se ejecuta por fases con pruebas antes de cada corte. Esta es la secuencia típica.

1. Diagnóstico. Se revisa el sistema, se elige la ruta y se estima alcance, fases y tiempos por escrito. Dura semanas, no meses.
2. Preparación. Se limpian datos, se resuelve la compatibilidad del código propio y se prepara la infraestructura. Aquí se gana o se pierde el proyecto.
3. Realización. Se construye el sistema nuevo o se convierte el existente, se ajustan los desarrollos y se configura lo que cambió.
4. Pruebas. Pruebas unitarias, integrales y de aceptación con usuarios reales, más al menos un ensayo completo de la salida en vivo.
5. Salida en vivo y estabilización. El corte al ambiente productivo y las primeras semanas de acompañamiento cercano.

Ninguna fase se salta. La tentación de recortar pruebas para llegar a una fecha es el origen de la mayoría de las salidas en vivo que salen mal.

Qué se necesita de tu lado

Una migración no la hace el proveedor solo. Necesita de tu empresa tres cosas que conviene reservar desde el principio. Tiempo de la gente que conoce los procesos, para validar diseños y probar. Decisiones oportunas cuando haya que elegir entre conservar algo o rehacerlo. Y accesos y datos limpios para que el equipo técnico no pierda semanas persiguiendo información.

El error más caro no es técnico. Es asignar al proyecto a las mismas personas que ya están saturadas con la operación diaria y esperar que rindan en las dos cosas.

Los errores que más cuestan

Después de ver muchos de estos proyectos, los tropiezos se repiten. Empezar sin diagnóstico y descubrir el alcance real a mitad del camino. Migrar los datos sucios tal cual y heredar el problema en la plataforma nueva. Subestimar los desarrollos Z y las integraciones con terceros. Dejar la localización fiscal mexicana, como la facturación electrónica y la Carta Porte, para el final. Y contratar por precio sin revisar quién va a estar de verdad en el proyecto.

Cada uno de esos temas tiene su propio artículo en este racimo. Vale la pena leerlos antes de aprobar nada.

Por qué HANA cambia las reglas

Vale la pena entender el motor, porque explica casi todo lo demás. HANA es una base de datos en memoria. En lugar de leer del disco cada vez, mantiene los datos en RAM y los procesa por columnas. Eso permite calcular al vuelo lo que antes había que pre-calcular y guardar en tablas auxiliares. Por eso S/4HANA elimina tablas: ya no necesita totales guardados, los saca al momento.

Para el negocio, la consecuencia práctica es que reportes que antes corrían de noche pueden correr en línea, y que finanzas trabaja sobre una sola tabla de asientos en lugar de reconciliar varias. Para TI, la consecuencia es que cualquier programa que leía esas tablas auxiliares hay que revisarlo. No es un detalle técnico menor: es la razón por la que tus desarrollos Z necesitan atención en la migración.

Fiori y el cambio para el usuario

La otra cara visible es la interfaz. Fiori reemplaza muchas de las pantallas clásicas por aplicaciones web pensadas por rol. Un comprador ve sus tareas de compra; un contador, las suyas. La curva de aprendizaje es real pero manejable, y conviene planearla: capacitación, comunicación y un periodo de acompañamiento. SAP GUI sigue disponible para lo que aún no tiene equivalente en Fiori, así que la transición no es de golpe. Subestimar la gestión del cambio con los usuarios es una de las causas más comunes de que una migración técnicamente correcta se sienta como un fracaso en la operación.

Cómo se decide la ruta, con criterios

Elegir entre Greenfield, Brownfield y Bluefield no es cuestión de gusto. Sale de mirar cuatro cosas: cuánta deuda funcional arrastra tu ECC, qué tan sanos están tus datos, cuántos desarrollos y modificaciones tienes, y qué tanto apetito real hay en el negocio para rediseñar procesos. La tabla resume cuándo se inclina cada ruta.

La tabla orienta, no decide. La decisión firme sale del diagnóstico, porque a veces dos criterios apuntan a rutas distintas y hay que ponderar. Lo que no debes aceptar es una recomendación de ruta antes de que alguien haya visto tu sistema.

Cuánto dura y de qué depende

No hay una duración única, por las mismas razones que no hay un precio único. Lo que alarga un proyecto es predecible: muchos desarrollos Z que revisar, datos maestros sucios que limpiar, muchas integraciones que rehacer, y poca disponibilidad de la gente que conoce los procesos. Lo que lo acorta también: un ECC ordenado, datos limpios y decisiones oportunas. Por eso la limpieza de datos, que no depende del proveedor, conviene empezarla antes de contratar nada.

El presupuesto que no está en la cotización

Un error frecuente es mirar solo el precio del proyecto. Hay dos costos más que conviene tener en el radar. El primero es la infraestructura donde va a correr S/4HANA, que es un gasto recurrente, no una sola vez. El segundo es el tiempo interno de tu equipo, que no aparece en ninguna factura del proveedor pero sí en la carga de tu gente. Un proyecto barato de implementar puede salir caro de operar, o puede quemar a tu equipo si nadie reservó su tiempo. Pide siempre las dos cifras: cuánto cuesta llegar y cuánto cuesta correr.

Los errores más comunes, en detalle

Empezar sin diagnóstico. Se firma un alcance a ciegas y el tamaño real aparece a mitad del camino, cuando ya es caro corregir el rumbo.

Migrar los datos sucios. Los duplicados y los registros huérfanos viajan a la plataforma nueva y el problema se hereda, ahora con menos excusas para no haberlo limpiado.

Subestimar Z e integraciones. Se cuentan los desarrollos pero no cuáles se usan, ni se revisa qué interfaces hay que rehacer. Ahí se esconde buena parte del esfuerzo.

Dejar la localización fiscal para el final. La facturación electrónica y la Carta Porte se prueban tarde y el sistema sale en vivo sin poder facturar. Es de los errores más caros y más evitables.

Contratar solo por precio. Se compara la cifra sin preguntar quién va a estar de verdad en el proyecto ni qué queda fuera del alcance.

Qué no cambia, para bajar la ansiedad

Con tanto que cambia, conviene decir también qué se conserva. Tu operación no se detiene el día de la fecha límite. Tus datos no se pierden en una migración bien hecha: se depuran y viajan. Tu conocimiento del negocio sigue valiendo; S/4HANA cambia la plataforma, no lo que tu empresa sabe hacer. Y no tienes que decidir todo hoy. Lo que sí conviene decidir pronto es la ruta, porque de ahí cuelga el calendario. Migrar es un proyecto grande, pero es un proyecto conocido, con fases probadas, no un salto al vacío.

Mitos comunes que conviene desarmar

Alrededor de esta decisión circulan ideas que estorban. Vale la pena nombrarlas.

• "Mi ECC se apaga en 2027." No. Lo que termina es el mantenimiento estándar; el sistema sigue operando, con más riesgo cada mes.
• "S/4HANA es solo una actualización más." No. Cambia la base de datos, el modelo de finanzas y la interfaz. Es un proyecto, no un parche.
• "El mantenimiento extendido me resuelve el problema." No. Compra tiempo con costo, no resuelve el fondo. Solo sirve con un plan de migración detrás.
• "Con más presupuesto se hace en un par de meses." No. El tiempo depende del estado de tu sistema y de tus datos, no solo del dinero.
• "La localización fiscal se resuelve al final." No. Es de lo primero que hay que confirmar, porque depende de terceros y de reglas que cambian.

Un glosario mínimo

Para leer cualquier propuesta sin perderte, estos términos bastan.

• HANA: la base de datos en memoria sobre la que corre S/4HANA.
• Fiori: la interfaz web de S/4HANA, por rol de usuario.
• Código Z: los desarrollos propios de tu empresa, fuera del estándar de SAP.
• Universal Journal: la tabla única de asientos que unifica finanzas y controlling.
• Greenfield, Brownfield, Bluefield: las tres rutas para llegar a S/4HANA.
• Datos maestros: clientes, proveedores, materiales y demás catálogos base de tu operación.

El siguiente paso

Si tu ECC todavía no tiene ruta definida, el primer paso no es firmar un proyecto. Es mirar el sistema y salir con un número y un plan. Nuestro Assessment de ruta a S/4HANA hace exactamente eso en dos semanas, con alcance y precio fijos. Y si quieres una idea rápida de tiempo y costo antes de hablar con nadie, la calculadora te da un rango en unos minutos.

Conoce el Assessment de ruta a S/4HANA.