Migración a S/4HANA: 3 controles para confiar en los datos

En una migración a S/4HANA, una carga al 100 % no demuestra que los datos estén bien. El cierre necesita evidencia de qué población se extrajo, qué reglas se aprobaron, qué se cargó realmente y qué diferencias siguen abiertas al comparar el origen con S/4HANA.

Control 1: separar datos aptos de datos que requieren decisión

Antes de cargar, cada registro debe terminar en un estado visible: apto, rechazado o pendiente. Busca claves duplicadas, obligatorios vacíos, fechas imposibles, referencias rotas y valores fuera del dominio permitido. Normalizar un código es razonable cuando existe un catálogo aprobado; adivinar qué proveedor quiso decir un texto legado no lo es.

El control tiene que conservar el alcance: objeto de migración, sociedades u otros filtros, fecha y hora del extracto, recuento inicial y reglas aplicadas. Sin esa fotografía de corte, un total posterior puede parecer correcto aunque esté comparando otra población.

Control 2: el mapeo es una decisión funcional versionada

La IA puede proponer un borrador entre columnas de origen y campos destino, pero no debe aprobarlo. Para cada campo de origen dentro del alcance, la matriz debe mostrar uno de tres resultados: destino y regla de transformación, exclusión aprobada o conservación en un archivo definido. Así se evita tanto perder una decisión como migrar información que no pertenece al objeto destino.

La matriz necesita versión, responsable funcional, fecha de aprobación y casos de prueba. Un ejemplo simple es un código de país: el flujo puede detectar que “España”, “ES” y “ESP” aparecen en el legado, pero solo la tabla de equivalencias aprobada decide cuál es el valor permitido en destino. Si falta la equivalencia, el registro queda pendiente.

Control 3: reconciliar después del corte

Reconciliar no es comparar dos totales en una hoja. Cruza origen y destino por una clave gobernada y clasifica cada resultado: ausente en destino, extra en destino, cambio de campo o clave duplicada. La excepción debe incluir la clave, ambos valores, regla o tolerancia aplicada, propietario y estado de resolución.

Define antes la población de comparación: mismo objeto, filtros, corte temporal, versión de mapeo y criterio de inclusión. Conserva los recuentos origen / apto / rechazado / pendiente / cargado / excepción abierta. Una diferencia explicada y asignada es parte del resultado; ocultarla para que el porcentaje de carga parezca mejor no lo es.

Cómo encaja con Migration Cockpit

SAP S/4HANA Migration Cockpit organiza proyectos, objetos de migración, tareas de mapeo y la carga. Cuando el objeto y el escenario lo admiten, permite simular antes de migrar. La disponibilidad de simulación no es universal, por lo que hay que revisar la documentación del objeto concreto y no prometer la misma secuencia para todos los casos. SAP describe las funciones de Migration Cockpit; su documentación de proceso advierte de que determinados objetos no permiten simulación.

Una prueba pequeña antes del corte

En un entorno de prueba, prepara una muestra con una clave duplicada, un obligatorio vacío y una referencia rota. Comprueba que cada caso va al estado esperado y que la matriz de mapeo deja evidencia de la decisión. Si el objeto permite simulación, úsala para detectar errores técnicos; si no la permite, documenta la prueba alternativa y no presentes la ausencia de errores como una garantía de negocio.

Después de la carga, compara el destino con el mismo extracto de corte, no con una extracción nueva. SAP sitúa la reconciliación con el sistema legado después de la transferencia dentro de su documentación para UPA; esto respalda la práctica en ese alcance específico, no una función universal de Migration Cockpit. La guía SAP de transferencia y reconciliación para UPA lo refleja explícitamente.

Lecturas relacionadas

Continúa con migración a SAP S/4HANA para Utilities en LATAM y filtros y paginación OData en SAP para profundizar en los conceptos de este artículo.