Migración de Datos ERP: Guía Estratégica

El ochenta y tres por ciento de los proyectos de migración de datos fracasan, exceden su presupuesto o incumplen su plazo — una cifra que Gartner ha rastreado durante años y que no ha mejorado significativamente. Sin embargo, cuando las empresas medianas planifican un cambio de sistema, la migración de datos consistentemente recibe la menor atención. Se comprime en las últimas semanas antes del go-live, se asigna sin un dueño claro y se trata como una tarea técnica en lugar del riesgo estratégico que realmente es.

Su estrategia de migración de datos ERP no debería comenzar cuando arranca la implementación. Debería comenzar antes de firmar el contrato.

Por Qué la Mayoría de las Migraciones de Datos Fracasan

Las causas están bien documentadas. Tres causas raíz aparecen en prácticamente todo análisis post-mortem: gestión del cambio inadecuada, mala ejecución de la migración de datos y equipos sin experiencia. Según el análisis de Curiosity Software sobre fallas en migración, estos tres factores son responsables de la mayoría de los fracasos — y se potencian mutuamente.

Esas categorías se traducen en patrones que los líderes de TI del mercado medio reconocen de inmediato.

Datos sucios tratados como problema de go-live. Los equipos descubren problemas de calidad durante la migración — duplicados, campos faltantes, formatos inconsistentes — e intentan corregirlos bajo presión de plazo. La corrección sale apresurada e incompleta. La limpieza de datos debe ocurrir meses antes del go-live, no días antes.

Nadie es dueño. TI asume que el negocio es responsable de las decisiones sobre calidad de datos. Las áreas de negocio asumen que TI maneja el mapeo técnico. El proveedor de implementación asume que ambos lados lo tienen resuelto. Nadie firma qué se migra, qué se archiva y qué se deja atrás.

Plazos comprimidos que generan atajos en cascada. La dirección fija la fecha de go-live antes de que alguien haya evaluado los datos. Cuando el plazo se acorta, las rondas de validación se eliminan, las pruebas corren con datos incompletos y la limpieza se posterga para “después del go-live” — donde rara vez sucede.

Según McKinsey, las ineficiencias en migración representarán más de US$ 100 mil millones en gasto desperdiciado en los próximos tres años. La mayor parte de ese desperdicio se concentra en el mercado medio, donde los equipos de TI son más pequeños y el margen de error es más estrecho.

Los Datos Ocultos que Nadie Inventaría

Los datos más peligrosos en cualquier migración no están en su ERP. Están en las hojas de cálculo, bases Access, carpetas de SharePoint y archivos de FileMaker que orbitan a su alrededor.

Estos datos sombra suelen ser la información operativa más crítica de la empresa: listas de precios por cliente, tablas de tarifas por transportista, configuraciones de producto, flujos de aprobación, reglas de excepción. Viven en archivos que una o dos personas mantienen, y nunca aparecen en ningún inventario formal.

Durante la planificación de la migración, los equipos se enfocan en los sistemas visibles — el ERP, el CRM, el sistema contable. Los datos sombra aparecen tarde, generalmente cuando alguien pregunta “¿dónde quedó la matriz de precios?” dos semanas después del cutover.

Por qué esto es un problema específico del mercado medio:

Equipos reducidos crean soluciones provisionales. Cuando un sistema no hace exactamente lo que se necesita, alguien crea una hoja de cálculo para cubrir la brecha. Con los años, esa hoja se vuelve crítica para la operación.
Sin gobernanza formal de datos. Las empresas grandes tienen responsables de datos y marcos de gobernanza. Las medianas tienen “la persona que sabe dónde está ese archivo.” Ya escribimos sobre la dependencia de persona clave como riesgo de negocio — los datos sombra son donde ese riesgo se concentra durante las migraciones.
El cambio de sistema expone la dependencia. El ERP anterior y sus archivos satélite formaban un sistema informal. Reemplazar solo el ERP sin considerar los satélites rompe flujos que nadie documentó.

Antes de iniciar cualquier migración, haga una auditoría de datos sombra. Entreviste a todos los departamentos — no solo a los gerentes, sino a las personas que hacen el trabajo diario. Pregunte: “¿Qué archivos usan todos los días que no están en el sistema principal?” Las respuestas van a redefinir el alcance de su migración.

Si ya trabajó con mapeo de procesos, esta auditoría es su contraparte de datos — e igualmente crítica.

¿Quién Debe Ser el Dueño de la Migración de Datos?

Esta pregunta aparece en toda implementación de mercado medio, y la respuesta incorrecta es la más común: “todos.”

Responsabilidad compartida en la práctica significa ninguna responsabilidad. La migración de datos necesita una única persona responsable — un Líder de Migración de Datos — con autoridad para tomar decisiones cross-funcionales sobre qué se migra, qué se limpia y qué se archiva.

El rol de cada grupo:

TI gestiona la ejecución técnica: extracción, transformación, carga y configuración del sistema. Se encarga del cómo.
Las áreas de negocio deciden sobre calidad de datos: qué registros son precisos, cuáles son obsoletos, cuáles necesitan corrección. Se encargan del qué.
El proveedor de implementación aporta la experiencia del sistema destino: mapeo de esquema, requisitos de campos, especificaciones de formato. Se encarga del dónde.
El Líder de Migración orquesta a los tres, resuelve conflictos y sostiene el cronograma. Se encarga del resultado.

Este rol no requiere una nueva contratación. En nuestra experiencia con empresas medianas, los líderes de migración más efectivos son profesionales senior de TI o gerentes de operaciones que entienden tanto la tecnología como los procesos de negocio. La calificación clave no es profundidad técnica — es autoridad cross-funcional y disposición para tomar decisiones impopulares sobre calidad de datos.

Estrategia de Migración por Fases para el Mercado Medio

El enfoque “big bang” — migrar todos los datos de una vez el fin de semana del go-live — funciona para volúmenes pequeños y esquemas simples. Para empresas medianas en transición de ERP, un enfoque por fases reduce riesgos al exponer problemas temprano, cuando todavía hay tiempo para corregirlos.

Fase 1: Evaluar e inventariar (semanas 1–4).

Mapee cada fuente de datos, incluidos los datos sombra. Para cada fuente, documente:

Qué datos contiene y cuál es el volumen
Quién es el dueño y quién los usa diariamente
Cómo se conecta con otros sistemas — de forma automática o manual
Qué porcentaje es vigente, histórico u obsoleto

La mayoría de las empresas medianas descubren que solo necesitan migrar activamente el 40–60% de sus datos. El resto son registros históricos que pertenecen a un archivo, no al sistema nuevo.

Fase 2: Limpiar antes de mover (semanas 4–10).

Migrar datos sucios a un sistema limpio lo contamina. La limpieza incluye:

Deduplicación. Unificar registros de clientes que existen en tres versiones ligeramente diferentes entre sistemas.
Estandarización. Formatos de teléfono, direcciones, convenciones de nombres, formatos de fecha — elija un estándar y aplíquelo. En mercados con facturación electrónica obligatoria, esto incluye estandarizar RFC, RUC o NIT según el país.
Validación. Verificar que los campos obligatorios tienen valores reales, no placeholders. Confirmar que las relaciones entre registros están intactas.
Decisiones de archivamiento. Negocios cerrados de 2015, proveedores inactivos, códigos de producto obsoletos — defina qué migra y qué queda. Los requisitos regulatorios de cada país pueden dictar períodos de retención, pero esos datos pueden vivir en un archivo de solo lectura.

Si sus datos viven en silos entre sistemas desconectados, espere que esta fase tome más tiempo del planificado. Conciliar registros que nunca fueron diseñados para coexistir es un trabajo lento y detallado.

Fase 3: Mapear y hacer carga de prueba (semanas 8–14).

Mapee campos de origen a campos de destino en el sistema nuevo. Aquí es donde aparecen las diferencias estructurales — el sistema anterior almacena “cliente” como un solo registro, el nuevo lo separa en “empresa” y “contacto.”

Haga cargas de prueba con datos reales temprano. Cargar datos de producción reales en un ambiente de pruebas meses antes del go-live expone errores de mapeo, problemas de rendimiento y datos faltantes cuando todavía se pueden corregir. Esto es fundamentalmente diferente de probar con datos sanitizados, que ocultan los casos borde que rompen en producción.

Fase 4: Validar y hacer cutover (semanas 12–16).

La validación es el paso que se elimina cuando los plazos se comprimen. No permita que eso suceda.

Validación de conteo. ¿El sistema destino tiene la misma cantidad de registros que el origen?
Verificación puntual por campo. Muestree registros entre tipos de datos y verifique cada campo.
Validación de lógica de negocio. ¿Los totales calculados, relaciones y reportes producen los resultados esperados?
Prueba de aceptación del usuario. Las personas que usan los datos diariamente verifican que sus flujos de trabajo funcionan con los datos migrados.

Establezca una fecha de cutover firme con criterios de rollback definidos. Si la validación revela problemas críticos, necesita un marco de decisión claro: postergar el go-live, remediar en sitio o revertir.

Qué Pasa Después del Go-Live

La mayoría de las guías de migración se detienen en el cutover. La realidad es que el primer mes post-migración es una fase legítima del proyecto — no una limpieza.

En las primeras dos semanas, los usuarios encontrarán errores que las pruebas no detectaron. Un precio que migró incorrectamente. Un registro de cliente que fusionó dos empresas diferentes. Un reporte histórico mostrando números distintos a los anteriores.

Planifique esto antes del cutover:

Establezca un proceso de triaje de problemas de datos. Defina cómo los usuarios reportan problemas, quién investiga y cuál es la ruta de escalamiento. Una hoja de cálculo compartida y una reunión diaria de 15 minutos funcionan mejor que un sistema de tickets que nadie revisa.
Mantenga el sistema anterior accesible en modo de solo lectura por un período definido. Los usuarios necesitarán consultar datos históricos, y tener el sistema anterior disponible reduce el pánico.
Programe una revisión de calidad de datos a los 30 días. Compare reportes y métricas clave entre los sistemas anterior y nuevo. Investigue discrepancias — especialmente totales que están cerca pero no son exactos, y registros que migraron pero perdieron sus relaciones.
Registre lo que aprenda. Cada problema encontrado post-go-live es una lección para la siguiente fase de migración o el siguiente cambio de sistema.

Cubrimos el panorama más amplio de post-implementación en nuestra guía de post-implementación de ERP. La validación de datos es una pieza crítica de ese panorama mayor.

Preguntas Frecuentes

¿Cuánto tiempo toma una migración de datos ERP?

Para empresas medianas, una migración completa — desde la evaluación hasta la validación post-go-live — toma típicamente de 12 a 16 semanas. Migraciones complejas que involucran múltiples sistemas de origen o limpieza intensiva pueden extenderse a 6 meses. La fase de limpieza sola suele tomar de 4 a 6 semanas, y comprimirla es la fuente más común de problemas posteriores.

¿Cuál es la diferencia entre migración big bang y migración por fases?

La migración big bang mueve todos los datos a la vez en un único evento de cutover, típicamente en un fin de semana. La migración por fases mueve datos en etapas, comenzando por los datasets menos críticos. Big bang es más rápida pero más riesgosa — si algo sale mal, todo se ve afectado. La por fases toma más tiempo pero permite validar cada etapa independientemente, reduciendo el radio de impacto de los errores.

¿Cómo decidir qué datos migrar y cuáles archivar?

Si los datos soportan un proceso de negocio activo — órdenes abiertas, clientes activos, productos vigentes, registros financieros recientes — se migran. Los datos históricos que nadie consulta regularmente pertenecen a un archivo de solo lectura. Los requisitos regulatorios de cada país pueden dictar períodos de retención, pero los datos retenidos no necesitan vivir en su nuevo sistema de producción.

¿Quién debe ser el responsable de la migración de datos?

Un Líder de Migración dedicado debe coordinar el esfuerzo, con TI manejando la ejecución técnica, las áreas de negocio decidiendo sobre calidad de datos y el proveedor aportando experiencia del sistema destino. El líder de migración orquesta los tres grupos y es responsable del cronograma y resultado. El rol requiere más autoridad cross-funcional que profundidad técnica.

¿Cómo se valida la precisión de los datos después de la migración?

Valide en tres niveles: conteo de registros (mismos totales en origen y destino), verificación puntual por campo (muestrear registros entre tipos de datos) y validación de lógica de negocio (totales calculados y reportes producen resultados esperados). Programe una revisión post-go-live de 30 días para detectar problemas sutiles que pasan las verificaciones automatizadas pero aparecen cuando usuarios reales ejecutan flujos reales.

Cómo Tier2 Aborda la Migración de Datos

Tier2 tiene más de 11 años implementando y migrando datos entre ERPs empresariales — Dynamics, SAP Business One, Totvs, Baan. Esa historia en consultoría moldeó cómo construimos nuestras propias plataformas.

Tanto Tier2 Cargo como Tier2 Keel fueron diseñados con la realidad de la migración en mente. Esquemas de datos estandarizados, documentación clara de mapeo de campos y herramientas de importación integradas hacen que la fase de mapeo descrita arriba sea estructurada, no exploratoria. Cuando integramos una empresa que viene de otro sistema, las fases de evaluación y limpieza reciben el tiempo que necesitan — porque aprendimos que apurarlas es cómo las migraciones terminan en el 83%.

Si está planificando un cambio de sistema y quiere conversar sobre el alcance de su migración de datos, estaremos encantados de analizarlo con usted.

Antes de evaluar un solo proveedor o asistir a otra demostración, tome un reporte de su sistema actual y rastree de dónde vienen realmente los datos. Si la respuesta involucra más de un sistema y una hoja de cálculo, encontró el primer punto de su plan de migración.