Por qué fracasa la migración de datos en SAP y cómo corregirlo

La migración de datos de SAP falla por un motivo más que por ningún otro: el plan se construye sobre lo que el negocio cree que son sus datos, no sobre lo que muestra una extracción. Esta guía es para directores de programa, responsables de datos y responsables de finanzas en un programa de S/4HANA. Cubre por qué se rompen las migraciones, los cinco errores detrás de la mayoría de los fallos de cutover, un plan de cargas de prueba que puede copiar y qué herramientas de SAP sirven para cada tarea en 2026. Si hace una sola cosa esta semana, haga una extracción completa de sus maestros de clientes, proveedores y materiales y cuente usted mismo los registros.

Una empresa manufacturera dedicó 18 meses y 4,5 millones de dólares a su implementación de SAP. Llegó el día del lanzamiento. Todos estaban nerviosos pero ilusionados. Entonces falló la migración de datos.

Nada funcionaba bien. Faltaban datos de clientes. Las cifras de inventario eran incorrectas. Contabilidad no podía cerrar los libros. El director ejecutivo estaba furioso.

No fue el software ni el equipo de implementación. El fallo estuvo en la distancia entre lo que el negocio creía que eran sus datos y lo que realmente eran.

El modelo de datos de SAP no es una importación plana. Los registros dependen unos de otros. Un maestro de materiales tiene un registro general (MARA), datos de centro (MARC), datos de valoración (MBEW) y, donde se usan áreas de MRP, datos del área de MRP (MDMA). Si carga la cabecera sin las vistas dependientes, el material existe pero no se puede usar en ninguna transacción.

S/4HANA añade su propia regla. Los clientes y los proveedores son interlocutores comerciales (business partners). Un cliente heredado pasa a ser un interlocutor comercial con rol de cliente, y un proveedor pasa a serlo con rol de proveedor. Los límites de crédito, los datos bancarios y los números fiscales cuelgan de ese interlocutor. Un registro que un sistema heredado toleraba con lagunas fallará la validación aquí.

Luego está el volumen. A la mayoría de las empresas les sorprende la cantidad de datos que realmente tienen. Un cliente creía tener unos 50.000 registros de materiales. Al contar todas las variantes y los registros específicos de cada centro, la cifra rondaba los 500.000. Un plan dimensionado para la primera cifra no sobrevive a la segunda.

Estimación del negocioExtracción completa

Registros de materiales en el alcance500,000+450,000 · +900%

Estimación del negocio50,000

Extracción completa500,000

• Cada variante y cada registro específico de centro contados
• Un plan dimensionado con la estimación no la sobrevive

Eso no fue un problema de migración de datos. Fue un problema de alcance que acabó siéndolo.

La evaluación de calidad de datos al inicio de un proyecto suele ser una descripción de los datos, no un examen. El director financiero dice que el maestro de proveedores está bien mantenido. El responsable de almacén dice que los materiales están más o menos limpios. Son impresiones.

La primera extracción le dice la verdad. Proveedores que debían depurarse hace años y no se depuraron. Materiales descatalogados hace mucho y nunca desactivados. Direcciones de clientes con códigos de país inconsistentes. Datos bancarios que faltan en proveedores a los que se paga por transferencia electrónica.

Cada uno de estos casos exige una decisión de negocio, no una corrección técnica. Solo cuentas por pagar puede decir cuál de dos proveedores duplicados es el correcto. Solo compras puede decir qué materiales obsoletos bloquear y cuáles dejar atrás. Esas decisiones llevan tiempo y requieren a las personas que conocen los datos. Si la evaluación no se basa en una extracción real, el plan se construye sobre supuestos que no sobrevivirán al contacto con los datos. Mi estimador gratuito de migración de datos ayuda a dimensionar el esfuerzo cuando ya tiene cifras reales.

1. Tratar la migración como una tarea técnica tardía

La migración pertenece a cada fase de SAP Activate. Explore define el alcance: objetos, sistemas de origen, volúmenes y calidad. Realize construye las plantillas y ejecuta las cargas de prueba. Deploy ejecuta el ensayo final y la carga de cutover. Run concilia el primer cierre de periodo con datos reales.

Los proyectos que empiezan el trabajo de migración en Deploy lo empiezan con meses de retraso. Los problemas de calidad que deberían haberse resuelto en Realize aparecen en la primera prueba, semanas antes del cutover. Mi guía de planificación del cronograma SAP muestra dónde encaja la migración en el plan general.

2. Poca participación del negocio

La migración es técnica en su ejecución y una actividad de negocio en la toma de decisiones. TI no puede elaborar la lista de proveedores duplicados. Qué cuentas de clientes pasan como activas y cuáles quedan como histórico es una decisión de finanzas. La depuración de materiales obsoletos necesita a compras, almacén y gestión de producto.

Los programas que dotan de personal a la migración solo con perfiles técnicos, y tratan al negocio como una firma de aprobación al final, producen datos que se cargan. Comercialmente, son incorrectos.

3. Planificar muy pocas cargas de prueba

Una migración de datos de SAP bien ejecutada necesita al menos tres cargas de prueba antes del cutover, y los programas complejos necesitan más. Los proyectos que planifican una o dos están planificando datos limpios y un mapeo limpio. Ese escenario es raro. Más ciclos no son señal de una migración en apuros. Son señal de una migración bien planificada.

4. No conciliar las cargas de prueba

Que un trabajo de carga termine sin errores no es validación. Validar es comparar lo cargado con lo esperado: número de registros, totales financieros, saldos de partidas abiertas. Después, una prueba de humo de procesos confirma que los datos funcionan en las transacciones.

Una carga de prueba que no se concilia sigue costando tiempo. La brecha que produjo sigue ahí en la siguiente prueba, solo que ahora es más difícil rastrearla hasta su causa. Concilie cada carga antes de empezar la siguiente.

5. Una carga de cutover distinta de los ensayos

La migración del cutover debe repetir exactamente la última prueba: los mismos scripts de extracción, la misma lógica de transformación, la misma secuencia de carga, las mismas comprobaciones y los mismos tiempos. Cualquier cambio en el cutover es un riesgo sin probar en el momento de mayor presión del programa.

La pieza menos probada suele ser el delta. Entre la última prueba y el cutover, el negocio sigue dando de alta proveedores, cambiando pedidos y moviendo existencias. Defina la fecha de congelación de datos y ensaye la carga delta como parte de la última prueba.

Use esta estructura de ciclos como punto de partida. Cada ciclo tiene un objetivo y un criterio de salida, y no está completo hasta que se firma la conciliación.

Ciclo	Objetivo	Criterio de salida	Responsable
Prueba 1	Estructura: cada objeto se carga en orden de dependencias	Brechas de mapeo y errores de formato registrados por objeto	Responsable de migración de datos
Prueba 2	Calidad: probar las correcciones de mapeo y sacar a la luz los problemas de datos	Tasa de errores a la baja por objeto; decisiones de depuración registradas	Responsables de datos
Prueba 3	Reglas de negocio: excepciones y casos límite	Los responsables de datos aceptan una muestra conciliada en cada dominio	Responsables de datos
Prueba 4	Volumen y tiempos con el tamaño completo de producción	La carga completa termina dentro de la ventana de cutover	Responsable de cutover
Ensayo final	Ensayo general del cutover, incluidos delta y congelación	Recuentos y totales financieros conciliados y firmados	Controller financiero y responsable de datos

Alrededor de ese plan, cinco cosas marcan la diferencia:

1. Una extracción completa en Prepare. Toda, no una muestra. Perfile la integridad, la exactitud, la coherencia y los duplicados, y dimensione la depuración y el cronograma a partir de los resultados.
2. Mapeo objeto por objeto. Para cada objeto (interlocutores comerciales, materiales, pedidos de compra y de venta abiertos, partidas abiertas, existencias, activos fijos), documente los campos de origen a destino, las reglas de transformación, las comprobaciones de validación y las reglas de excepción.
3. Responsables de datos designados. Finanzas es responsable de los datos financieros de clientes y proveedores. Compras es responsable del maestro de materiales. El almacén es responsable de las existencias. Cada responsable firma su dominio tras cada ciclo.
4. Conciliación definida desde el principio. Acuerde qué recuentos y totales demuestran que una carga es correcta antes de la primera prueba, para que nadie lo discuta en el cutover.
5. Una secuencia de cutover por escrito. Congelación, extracción, transformación, carga, validación, aprobación del negocio, go/no-go. La misma secuencia que el ensayo final.

Para una nueva implementación de S/4HANA, el SAP S/4HANA Migration Cockpit es la herramienta que SAP recomienda para la carga inicial. Desde S/4HANA 2020 se ejecuta como la aplicación Fiori Migrate Your Data. La transacción LTMC está obsoleta, y los proyectos LTMC existentes solo pueden visualizarse. La aplicación ofrece dos enfoques: migrar datos mediante tablas de staging (rellenadas desde archivos o con sus propias herramientas) y migrar datos directamente desde un sistema SAP de origen. Los equipos on-premise y de nube privada usan la transacción LTMOM, el modelador de objetos de migración, para ajustar objetos estándar o crear los suyos. El cockpit está pensado para cargas iniciales, no para interfaces recurrentes ni cambios masivos.

SAP Data Services es la plataforma ETL de SAP. Úsela para volúmenes altos, lógica de transformación compleja, varios sistemas de origen o cuando quiera un marco reutilizable de calidad de datos que sobreviva al proyecto.

Las herramientas ETL de terceros, como Informatica, Talend o Microsoft SSIS, tienen sentido cuando la organización ya las posee y tiene las competencias.

SAP Datasphere, que ahora forma parte de SAP Business Data Cloud, no es una herramienta de migración. Su lugar es la capa analítica tras el go-live. Importa si deja el histórico en el sistema heredado y aún necesita elaborar informes sobre él.

Para la mayoría de las implementaciones estándar, el Migration Cockpit cubre la mayoría de los objetos. Los volúmenes altos, los sistemas heredados muy personalizados o las estructuras de origen inusuales suelen necesitar Data Services o una herramienta ETL a su lado. Las conversiones desde ECC son otro ejercicio, que explico en mi guía de migración de ECC a S/4HANA.

¿Qué es la migración de datos de SAP?

La migración de datos de SAP consiste en extraer datos de sistemas heredados, transformarlos para que encajen en las estructuras y reglas de SAP y cargarlos en SAP como parte de una implementación o una conversión. Los objetos típicos son los interlocutores comerciales (clientes y proveedores), los materiales con datos de centro, los pedidos de compra y de venta abiertos, los saldos de existencias, las partidas abiertas financieras y los activos fijos. Es difícil porque SAP impone dependencias y reglas de validación que los sistemas heredados a menudo no tenían.

¿Cuáles son los principales enfoques de la migración de datos de SAP?

Una nueva implementación (greenfield) carga datos maestros seleccionados y partidas abiertas en un sistema S/4HANA nuevo, y deja el histórico en el sistema heredado o en un archivo. Una conversión de sistema (brownfield) convierte en el propio sistema un ECC existente y su histórico. La transición selectiva de datos queda entre ambas y traslada sociedades, objetos o cortes temporales concretos. La elección correcta depende de la calidad de los datos, de los requisitos de histórico y de cuánto del proceso antiguo se quiere conservar.

¿Qué es SAP Migration Cockpit y cuándo conviene usarlo?

El SAP S/4HANA Migration Cockpit es la herramienta que SAP recomienda para la carga inicial de datos en S/4HANA, en todas las ediciones. Desde S/4HANA 2020 se ejecuta como la aplicación Fiori Migrate Your Data; la transacción LTMC está obsoleta. Ofrece objetos de migración predefinidos, valida los datos antes de contabilizarlos e informa de los errores a nivel de campo. Úselo para objetos estándar con volúmenes normales. Añada SAP Data Services u otra herramienta ETL cuando los volúmenes, la lógica de transformación o las estructuras de origen superen lo que manejan las plantillas.

¿Cuántas cargas de prueba debe prever un plan de migración de datos de SAP?

Al menos tres, y la última, un ensayo completo del cutover. Los programas complejos necesitan más. En un plan típico, la primera detecta brechas estructurales de mapeo. La segunda prueba las correcciones y saca a la luz problemas de calidad de datos. La tercera recorre las reglas de negocio y los casos límite. La ejecución final repite exactamente el cutover, y su conciliación pasa a ser la referencia para el día del go-live.

¿Cómo se migran clientes y proveedores a SAP S/4HANA?

Como interlocutores comerciales. En S/4HANA, los datos maestros de clientes y proveedores se mantienen a través del interlocutor comercial, con roles de cliente y de proveedor asignados. En una nueva implementación, el Migration Cockpit los carga mediante sus objetos de interlocutor comercial. En una conversión desde ECC, la integración cliente-proveedor hay que configurarla y ejecutarla antes de la conversión en sí.

¿Qué hace que la migración de datos de SAP falle en el cutover?

Cinco patrones causan la mayoría de los fallos de cutover. Muy pocas cargas de prueba. Una secuencia de cutover que nunca se probó de principio a fin. Cambios en el sistema heredado después de la última prueba, con una carga delta sin probar. Brechas de conciliación que se dejan abiertas. Una aprobación del negocio basada en una comprobación por muestreo. «Los primeros 1.000 registros se veían bien» no es validación. El go-live necesita recuentos y totales conciliados.