En enero del año 49 a. C., Julio César llegó al Rubicón con una legión y una decisión. Cruzar aquel pequeño río significaba abandonar el territorio donde aún podía retroceder sin desencadenar una guerra civil. El agua no era profunda; la consecuencia sí.
Una migración a SAP S/4HANA contiene un umbral parecido. El momento decisivo no llega cuando comienza la conversión técnica. Llega mucho antes, cuando la dirección acepta que no está comprando una actualización, sino el derecho y la obligación de rediseñar cómo funcionará la empresa durante la siguiente década.
El calendario importa, pero no debe gobernar solo
SAP mantiene el soporte principal de las aplicaciones centrales de Business Suite 7 hasta finales de 2027 y ofrece mantenimiento extendido opcional hasta finales de 2030. Esa referencia crea presión, pero una transformación diseñada únicamente para escapar de una fecha corre el riesgo de transportar todos los problemas antiguos a una plataforma nueva.
La pregunta inicial no debería ser «¿cuánto tardaremos en migrar?», sino «¿qué queremos poder hacer después que hoy resulta demasiado lento, caro o frágil?».
Tres caminos y ninguna respuesta universal
Conversión del sistema o brownfield
Conserva gran parte de la configuración y de los procesos existentes. Puede reducir disrupción y tiempo, pero exige analizar cuidadosamente código propio, simplificaciones y deuda técnica. Es adecuado cuando el sistema funciona razonablemente bien y el objetivo principal es evolucionarlo.
Nueva implantación o greenfield
Permite rediseñar procesos y adoptar estándar con mayor libertad. También requiere más gestión del cambio, decisiones sobre datos históricos y una disciplina firme para evitar reconstruir cada personalización anterior.
Transición selectiva
Combina elementos de ambos modelos: conserva partes elegidas mientras transforma otras. Puede ser útil en grupos con múltiples sociedades, carve-outs o calendarios escalonados. Su flexibilidad añade decisiones y necesita una arquitectura de datos muy clara.
Elegir el enfoque por moda es como escoger un barco por su aspecto sin conocer la costa. La decisión depende de calidad del sistema actual, volumen de datos, complejidad organizativa, apetito de cambio y tiempo disponible.
Las decisiones que deben tomarse antes del proyecto
Definir el resultado empresarial
Reducción del cierre financiero, visibilidad de inventario, simplificación del paisaje, adquisiciones más rápidas o adopción de IA son objetivos distintos. Cada uno cambia prioridades y arquitectura.
Conocer el territorio
El inventario debe incluir procesos, desarrollos, interfaces, jobs, volúmenes, calidad de datos, roles y dependencias con terceros. Lo desconocido no desaparece durante la migración; reaparece como incidencia.
Decidir qué historia conservar
No todos los datos históricos necesitan viajar al nuevo sistema. Hay que equilibrar obligaciones legales, analítica, coste y accesibilidad. Migrar basura con precisión sigue produciendo basura.
Asegurar el talento
Los proyectos compiten por perfiles con experiencia funcional, técnica y de transformación. La capacidad no se mide solo en número de consultores: importan conocimiento del negocio, liderazgo de procesos, integración, datos, seguridad y pruebas.
Diseñar la transición operativa
Cutover, convivencia, reconciliación, contingencia y soporte posterior deben ensayarse. Una salida a producción no es el final del proyecto; es el momento en que la hipótesis se encuentra con la realidad.
Los indicadores de una migración sana
El porcentaje de tareas completadas ofrece una imagen pobre. Resulta más útil medir procesos estandarizados, objetos retirados, pruebas automatizadas, defectos críticos, calidad de datos, tiempo de ciclo, adopción y capacidad de actualizar el sistema después.
También conviene vigilar una señal incómoda: cuántas decisiones importantes permanecen abiertas mientras el calendario avanza. Un proyecto puede parecer verde y estar acumulando una tormenta.
Pruebas: el lugar donde la estrategia toca el suelo
Una migración no se valida demostrando que el sistema arranca. Debe probarse que la empresa puede cerrar un periodo, entregar un pedido, pagar a un proveedor y responder a una auditoría. Los casos de prueba deben construirse alrededor de procesos completos, excepciones y volúmenes reales.
Automatizar regresiones aporta velocidad, pero no sustituye el juicio funcional. Los datos de prueba han de representar sociedades, monedas, impuestos, variantes de materiales y escenarios poco frecuentes. Los defectos que aparecen durante el cutover suelen proceder de aquello que parecía demasiado pequeño para merecer una prueba.
La transformación de las personas
Los procesos nuevos cambian decisiones, responsabilidades y secuencias de trabajo. Formar únicamente en pantallas produce usuarios capaces de seguir un guion, no de responder cuando el proceso se desvía. La formación debe explicar el porqué, practicar excepciones y permitir que los responsables cuestionen el diseño antes de la salida.
También hay que proteger el tiempo de los expertos internos. Si mantienen su operación diaria mientras validan diseño, datos y pruebas, el proyecto dependerá de noches y buena voluntad. La capacidad de negocio es un recurso del programa y debe planificarse como tal.
Gobernar decisiones, no solo tareas
Los comités de dirección funcionan cuando resuelven alternativas con impacto, no cuando reciben cien diapositivas de progreso. Cada decisión debería presentar opciones, coste, riesgo, recomendación y fecha límite. Las cuestiones que no se deciden a tiempo terminan siendo decididas por el calendario.
La misma claridad debe llegar a proveedores e integradores. Entregables, criterios de aceptación, transferencia de conocimiento y responsabilidades durante la estabilización necesitan quedar definidos antes de que aparezca la presión final.
El ensayo general del cutover
El plan de transición debe ejecutarse como un proceso real, con duraciones, responsables, dependencias y criterios de abandono. Un ensayo revela pasos que no caben en la ventana, accesos que faltan y reconciliaciones que nadie había asignado.
La decisión de seguir o detenerse necesita umbrales objetivos. Si el equipo solo descubre durante la madrugada qué significa «demasiados errores», la presión favorecerá continuar incluso cuando la evidencia aconseje volver atrás.
Después de la salida
La estabilización requiere priorización, observabilidad y una ruta clara entre soporte y proyecto. También debe protegerse la evolución: si todas las mejoras se congelan indefinidamente para resolver incidencias, el nuevo sistema comienza su vida acumulando frustración.
El punto de no retorno debe ser consciente
César cruzó el río con una idea clara de lo que dejaba atrás, aunque no pudiera controlar todo lo que seguiría. Una empresa no necesita dramatismo militar, pero sí la misma lucidez respecto a sus compromisos.
Migrar a SAP S/4HANA merece una decisión explícita sobre procesos, datos, arquitectura y personas. Cuando esa decisión existe, el proyecto deja de ser una carrera contra 2027. Se convierte en la construcción deliberada de una empresa capaz de cambiar.
