La migración de datos es el frente de trabajo que más se subestima, programa tras programa, en todos los ERP que he dirigido. El proveedor calcula tres meses de trabajo con datos. La realidad termina entre seis y nueve. Al llegar el cutover, la mitad del equipo está apagando incendios por duplicados y el comité directivo pregunta por qué nadie lo advirtió antes.
Creé este estimador para adelantar esa conversación unos meses. Dimensiona el trabajo por objeto de datos, por volumen y por ERP de destino, y devuelve una estimación en días-persona, una banda de costos y un enfoque de migración recomendado. Es independiente del proveedor y cubre SAP S/4HANA, SAP ECC, Oracle Fusion Cloud, Oracle E-Business Suite y Microsoft Dynamics 365 y AX.
El resultado es un rango, no un punto único, porque la realidad es un rango. Las variables que más mueven la cifra son la calidad de los datos, el número de sistemas de origen y cuánto historial decide traspasar.
Elija su ERP de destino. Añada los objetos de datos incluidos en el alcance y los volúmenes de registros que espera para cada uno. Indique con honestidad el nivel de calidad de los datos. El estimador devuelve el esfuerzo por objeto, un rango total de días-persona, una banda de costos y un enfoque recomendado (Migration Cockpit, LSMW, ETL a medida o híbrido).
Todo se ejecuta en su navegador. No se envía nada a ningún sitio. No se guarda nada. Modifique los datos de entrada cuantas veces haga falta para poner a prueba el resultado frente a sus propias hipótesis.
- Maestro de clientes: relaciones de solicitante, destinatario de mercancías, pagador y destinatario de factura, funciones de interlocutor
- Maestro de proveedores: registros de proveedor, condiciones de pago, retenciones de impuestos, datos bancarios
- Maestro de materiales: datos básicos, vistas de centro, vistas de ventas, MRP, contabilidad y costos
- Cuentas del libro mayor y plan de cuentas: costos primarios y secundarios, jerarquías
- Centros de costos, centros de beneficio, órdenes internas: datos maestros de controlling
- Pedidos de compra abiertos: cabecera, posiciones, repartos, asignaciones de cuenta
- Pedidos de venta abiertos: cabecera, posiciones, condiciones, datos de interlocutores
- Facturas abiertas (cuentas por pagar y por cobrar): partidas abiertas con asignaciones y reglas de compensación
- Saldos de inventario: por almacén, lote, stock especial
- Transacciones financieras históricas: asientos, saldos, arrastre de saldos de fin de ejercicio
- Maestro de activos fijos e historial de depreciación: por clase de activo y área de valoración
- Datos maestros de recursos humanos: empleados, unidades organizativas, posiciones, cuando SuccessFactors o HCM están dentro del alcance
Introduzca los datos de su migración
Los campos marcados con * son obligatorios.
El patrón es siempre el mismo. El descubrimiento se hace en talleres, con los responsables de los sistemas presentes. Le dicen que los datos están «bastante limpios». La estimación se construye sobre esa afirmación. Nadie ejecuta ni una sola consulta de perfilado antes de que la cifra llegue al caso de negocio.
Un cliente de manufactura me dijo que sus números de pieza estaban estandarizados. Extrajimos los datos y encontramos 12 formatos distintos en uso activo. En otro programa, el sistema de registro de las notas de clientes resultó ser un campo personalizado que nadie había documentado, y tres años de historial desaparecieron porque el mapeo no lo recogió. En una migración financiera, la única persona que entendía el plan de cuentas heredado se había jubilado cinco años antes.
El momento caro es descubrir estos problemas durante el ensayo de cutover, no en la planificación. Una corrección de calidad de datos detectada en la segunda semana del descubrimiento cuesta días. La misma corrección detectada en el tercer simulacro de cutover le cuesta al programa semanas, a veces un trimestre. Para entonces las fechas son públicas, la red de gestión del cambio está movilizada y retrasar el go-live es una conversación de consejo de administración.
Lo correcto es perfilar los datos antes de firmar la estimación. Ejecute consultas reales contra el origen. Cuente los duplicados. Cuente los nulos. Cuente los registros que hoy incumplen las reglas de campos obligatorios de su sistema de destino. El estimador da por hecho que usted lo hará. La banda de costos se ensancha con fuerza cuando indica con honestidad el nivel de calidad de los datos.
El enfoque adecuado depende del ERP de destino, de los volúmenes de datos y de cuántos sistemas de origen hay que consolidar. A continuación, a grandes rasgos, lo que suelo elegir, con el esfuerzo relativo a la opción más sencilla.
| Enfoque | Ideal para | Multiplicador de esfuerzo | Herramientas |
|---|---|---|---|
| SAP Migration Cockpit (LTMC / LTMOM) | S/4HANA greenfield, objetos estándar, volúmenes medios | 1,0× | LTMC, LTMOM, plantillas entregadas por SAP |
| LSMW | ECC, migraciones de sistemas heredados, programas que siguen en versiones anteriores | 1,2× | LSMW, sesiones BDC grabadas |
| ETL a medida mediante SAP BTP / Integration Suite | Alto volumen, transformaciones complejas, consolidación de varios orígenes | 2,0× | BTP, CPI, SAP Data Services, Syniti, SNP |
| Híbrido (Cockpit + ETL) | Conversiones brownfield a S/4HANA y migraciones selectivas | 1,5× | Cockpit para los maestros, ETL para el historial transaccional |
| Nativo de Oracle | Destinos Oracle Fusion Cloud y EBS | 1,3× | FBDI, ADFdi, Oracle GoldenGate |
| Dynamics Data Management Framework | Destinos Dynamics 365 F&O y AX | 1,3× | Entidades DMF, Azure Data Factory |
El ETL a medida es lo más flexible y lo más caro. La prueba honesta para saber si lo necesita es si sus datos de origen incumplen las reglas estándar del destino de maneras que ninguna plantilla puede corregir sin lógica registro por registro. Si la respuesta es no, quédese con las herramientas estándar.
- SAP S/4HANA (greenfield, brownfield, selectivo)
- SAP ECC (todavía relevante en entornos paralelos y migraciones tardías)
- Oracle Fusion Cloud ERP
- Oracle E-Business Suite (R12)
- Microsoft Dynamics 365 Finance and Operations
- Microsoft Dynamics AX (2009, 2012)
- Directores de programa que dimensionan el frente de datos antes de que el integrador de sistemas (SI) se comprometa con una cifra.
- Responsables de migración de datos que ponen a prueba su estimación interna frente a una referencia independiente.
- CIO y CFO que verifican la partida de datos de un presupuesto de implementación de varios millones de dólares.
- Asesores independientes que necesitan cifras defendibles en propuestas o en revisiones de aseguramiento.
- Equipos internos de ERP que elaboran el caso de negocio sin pagar un encargo aparte para definir el alcance.
- Una cifra defendible, rápido. Estimación en días-persona objeto por objeto, en lugar de una suposición única.
- Neutral respecto a los proveedores. Construido con patrones de programas de SAP, Oracle y Microsoft, no con el manual de un solo proveedor.
- Recomendación de enfoque. Le indica si el punto de partida adecuado es Migration Cockpit, LSMW, ETL a medida o un enfoque híbrido.
- Sensible al volumen y a la calidad. La banda de costos se ensancha cuando baja la calidad de los datos, como ocurre en los programas reales.
- Gratis, solo en el navegador, sin registro. Nada sale de su equipo. Actualice y empiece de nuevo cuantas veces necesite.
¿Qué grado de precisión tienen las estimaciones de migración de datos de esta herramienta?
Las cifras reflejan los patrones que he visto en programas de SAP, Oracle y Dynamics durante los últimos 25 años. Están pensadas para anclar una conversación de planificación, no para sustituir un ejercicio de perfilado sobre sus datos reales.
La palanca más importante para la precisión es si ha ejecutado consultas de perfilado contra el origen. Una banda de costos construida sobre un nivel de calidad de datos honesto se sostiene. Una construida sobre el optimismo de los talleres, no. Use el resultado del estimador como cifra de referencia en su conversación con el SI. Si su estimación es sensiblemente menor, pregunte qué supuesto de calidad de datos están haciendo y cómo lo validaron.
¿Debo migrar las transacciones financieras históricas o solo las partidas abiertas?
En la mayoría de los programas, lo correcto son las partidas abiertas más los saldos de apertura, con el historial consultable en el sistema heredado mediante un archivo de solo lectura o una capa de reporting. Migrar todo el historial transaccional multiplica el esfuerzo, ralentiza la conciliación y pocas veces compensa su costo.
La excepción son los sectores regulados, donde la retención legal exige que el historial viva en el sistema de registro, o los negocios en los que las comparaciones interanuales continuas en el nuevo sistema son un requisito operativo real. En ambos casos, el multiplicador de esfuerzo del estimador para datos históricos refleja la mayor carga.
¿Qué enfoque de migración recomienda la herramienta?
Elige el punto de partida según el ERP de destino, el conjunto de objetos y los volúmenes. Un S/4HANA greenfield con objetos estándar suele acabar en Migration Cockpit. Las conversiones brownfield y las migraciones selectivas se inclinan por un enfoque híbrido. Los volúmenes altos, los varios sistemas de origen o una transformación pesada llevan la recomendación hacia un ETL a medida sobre BTP o una plataforma equivalente en el lado de Oracle o Microsoft.
La recomendación es un punto de partida. La decisión real se toma después de una prueba de concepto con una muestra de sus datos, no con una calculadora. Trate el resultado como la hipótesis de trabajo con la que entra en ese ejercicio.
¿Puedo exportar el plan o compartirlo con mi equipo?
La calculadora se ejecuta íntegramente en el navegador. Puede hacer una captura de pantalla del resultado o copiar las cifras por objeto en su propia hoja de planificación. No hay cuenta, no hay exportación a PDF y no se guarda nada en el servidor. Es deliberado. Si quiere un repaso más a fondo de las cifras, reserve una llamada de 30 minutos y traiga la captura.
¿Cubre datos que no son maestros, como la configuración y la seguridad?
No. El estimador dimensiona únicamente datos maestros y datos transaccionales. Los datos de configuración, los roles de seguridad, los desarrollos a medida y los objetos de integración pertenecen a otros frentes de trabajo, con sus propios factores de esfuerzo, y no deberían meterse en la partida de datos. Juntarlo todo en una sola cifra es una de las razones por las que las estimaciones de migración de datos se disparan ya en la fase de planificación.
¿Cómo trata los despliegues multirregión y multientidad?
El estimador dimensiona un único evento de migración. Para un despliegue multirregión, ejecútelo una vez por ola y sume las olas, aplicando un factor de reducción por las plantillas, los mapeos y las herramientas que reutiliza a partir de la primera ola. En mi experiencia, la segunda ola cuesta aproximadamente entre el 60 y el 70 % de la primera, la tercera baja hasta alrededor del 50 % y se estabiliza a partir de ahí. Los objetos de datos de carácter legal local (impuestos, nómina, banca) suelen ser la parte que no se reutiliza limpiamente.
¿Sirve la herramienta para conversiones brownfield de ECC a S/4HANA?
Sí, y ajusta el menor esfuerzo de los objetos que se convierten in situ frente a los que necesitan un nuevo mapeo. Una conversión brownfield suele quedarse entre el 40 y el 60 % del esfuerzo de datos de una migración greenfield equivalente, porque las estructuras de clientes, proveedores, materiales y plan de cuentas pasan sin necesidad de volver a extraerlas. La carga mayor suele ser la conversión a interlocutor comercial (business partner) y el impacto del nuevo libro mayor en los asientos históricos.
¿Es gratuita la calculadora?
Sí. Sin registro, sin pedir el correo electrónico, sin pagos. El cálculo se ejecuta en su navegador y no se guarda ni se envía nada a ningún sitio. Si quiere ayuda para construir el caso de la migración de datos una vez que tenga una cifra, reserve una llamada de 30 minutos.