Migración de datos a ERP: qué limpiar y qué dejar atrás

Pida ver el plan de una implementación de ERP y la migración de datos aparecerá como una fase — normalmente unas pocas semanas, encajada entre la configuración y las pruebas, dimensionada como si mover datos fuera un ejercicio mecánico de exportar e importar. No lo es. La migración es el momento en que cada supuesto adoptado durante el diseño se encuentra con el historial real y sin depurar de cómo ha operado de verdad el negocio, y es de forma desproporcionadamente frecuente la razón por la que las implementaciones se retrasan, por motivos ya tratados en el artículo de esta serie sobre patrones de fracaso en implementaciones de NetSuite.

El plan trata la migración como una tarea técnica: extraer, transformar, cargar. La realidad es que la migración es un ejercicio de toma de decisiones disfrazado de tarea técnica — qué trasladar, qué limpiar antes, qué archivar en lugar de migrar y qué dejar atrás por completo — y cada una de esas decisiones tiene consecuencias sobre el coste, el calendario y lo utilizable que resulta realmente el nuevo sistema el primer día.

Por qué esto importa

Subestimar la migración tiene una firma de fracaso específica y repetible. El perfilado se omite o se hace con prisas, el estado real de los datos se descubre durante la propia fase de migración en lugar de antes, y ese descubrimiento fuerza una renegociación de alcance y calendario en el punto del proyecto con menos margen disponible — porque el go-live ya se ha comunicado normalmente al negocio y no puede moverse con facilidad.

El coste de equivocarse aquí también se acumula después del go-live. Los datos migrados sin una depuración adecuada arrastran sus problemas al nuevo sistema, salvo que ahora son más difíciles de corregir, porque están incrustados en un sistema del que todo el mundo ha empezado a depender y se mezclan con transacciones genuinamente nuevas. Un registro de cliente duplicado que existía desde años en el sistema antiguo es una molestia; el mismo duplicado, recién migrado a un sistema en el que todos confían ahora como fuente de verdad, induce activamente a decisiones equivocadas.

Hay además una cuestión de alcance que la migración fuerza como nada más en el proyecto lo hace de forma tan directa: no todo lo que hay en su sistema actual merece existir en el nuevo. Clientes antiguos inactivos, artículos descatalogados, transacciones históricas más allá de lo legalmente exigido — migrarlo todo por defecto, porque nadie decidió explícitamente lo contrario, infla el coste, degrada el rendimiento y contamina el nuevo sistema con material irrelevante desde el primer día.

De un vistazo: las categorías de decisión de la migración

Las categorías que más a menudo se colapsan en "migrarlo todo" por defecto son la segunda y la tercera. El historial transaccional completo es caro de migrar y rara vez se necesita con ese nivel de granularidad — un saldo de apertura, bien determinado, suele servir mejor al negocio que años de historial granular que nadie va a consultar, y los requisitos legales de conservación se satisfacen normalmente con un archivo accesible en lugar de con presencia viva en el nuevo ERP.

Qué funciona y en qué hay que ser honesto

Qué funciona:

Perfilar antes de dimensionar, no durante la migración. Establezca recuentos de registros, tasas de duplicados, grado de cumplimentación de los campos obligatorios e integridad referencial en el primer mes del proyecto, no en la fase de migración. Es el paso con mayor palanca de toda la migración y es el que más a menudo se omite bajo presión de tiempo, precisamente porque parece que puede esperar.

Decidir la conservación por categoría, de forma deliberada, con la participación de finanzas y del área legal. Los requisitos legales de conservación en Iberia difieren según el tipo de documento y de registro, y "cuánto tiempo necesitamos conservar esto" es una pregunta de cumplimiento, no una pregunta de IT. Obtenga la respuesta para cada categoría antes de decidir qué migrar y qué archivar.

Depurar antes de migrar, nunca después. Un duplicado conocido o un registro mal formado debe corregirse antes de moverse, no migrarse con la intención de limpiarlo una vez en producción. Una vez en producción, queda mezclado con actividad nueva real y es considerablemente más difícil de aislar y corregir.

Migrar saldos de apertura en lugar del historial completo de transacciones siempre que el negocio no necesite consulta a nivel de transacción. Esta opción se utiliza sistemáticamente menos de lo debido porque da la sensación de perder algo, pero en la mayoría de las empresas mid-market el detalle histórico de transacciones apenas se consulta después de los primeros meses, y un saldo de apertura bien determinado preserva todo lo que el negocio realmente necesita.

Un paso definido y probado de rollback y conciliación. Toda migración necesita una forma de demostrar que los datos del nuevo sistema coinciden con los del antiguo, categoría por categoría, antes de dar de baja el sistema antiguo. Omitir esto es la vía por la que las empresas descubren un error de migración meses después, cuando la comparación ya no es sencilla.

En qué hay que ser honesto:

El perfilado encontrará cosas que nadie quiere oír. Las tasas de duplicados y los problemas de calidad del dato que aparecen durante el perfilado son con frecuencia mayores de lo que cualquiera espera, y la tentación es tratar el hallazgo como una exageración en lugar de como un hecho. Presupueste con honestidad el tiempo que llevará esa corrección, porque descubrir el alcance real tarde es peor que descubrirlo pronto y que la cifra no guste.

"Puede que lo necesitemos" no es un criterio de migración. Casi cualquier cosa podría concebiblemente necesitarse algún día. La disciplina consiste en preguntar qué se necesitaría concretamente, quién lo necesitaría, en qué circunstancia, y si un archivo en lugar de una migración viva satisface esa necesidad. La mayoría de los casos pasan esta prueba como "archivar", no como "migrar".

La depuración lleva más tiempo del que permite el plan, casi siempre. No es una crítica a ningún equipo en particular — es un rasgo estructural del trabajo, porque la depuración saca a la luz juicios de valor (¿es esto un duplicado, o dos entidades genuinamente distintas con el mismo nombre?) que no pueden automatizarse por completo y que se multiplican con el volumen de datos.

El historial migrado tiene que conciliar de verdad, y la conciliación es en sí misma una tarea significativa. Comparar saldos, recuentos y muestras entre el sistema antiguo y el nuevo, categoría por categoría, es trabajo real que hay que planificar y dotar de recursos, no algo que se dé por hecho como efecto secundario de que los scripts de migración se ejecuten correctamente.

El negocio pedirá cosas de vuelta después del go-live. Algunos datos archivados o excluidos resultarán ser deseados al final, normalmente por una disputa concreta con un cliente o por una petición de auditoría inusual. Esto es gestionable si el archivo es genuinamente accesible, y una crisis si "archivado" resultó significar "borrado".

Marco de decisión: dimensionar y ejecutar la migración

Recórralo en orden. Deténgase en la primera coincidencia.

1. ¿Se han perfilado los datos — recuentos de registros, tasas de duplicados, cumplimentación, integridad referencial — con independencia del calendario de migración?
Si no, hágalo ahora, en el primer mes del proyecto, sea cual sea la fase en la que el plan sitúe la migración. Este hallazgo revaloriza todo lo que sigue y es mucho más barato tenerlo pronto.

2. ¿Se ha asignado explícitamente cada categoría de datos a migrar, resumir, archivar o descartar — con la aportación de finanzas y del área legal sobre conservación?
Si no, hágalo antes de que empiece cualquier trabajo técnico de migración. Optar por defecto por "migrarlo todo" es una decisión por omisión, y normalmente es la equivocada.

3. ¿Los problemas conocidos de calidad del dato se están limpiando antes de la migración, o se están aplazando a un "lo arreglamos luego"?
Si se aplazan, pare y reconsidere. Migrar datos que se sabe defectuosos con la intención de corregirlos después falla de forma fiable, porque la corrección se vuelve más difícil una vez mezclada con actividad viva y menos urgente una vez pasada la presión inmediata del go-live.

4. ¿Existe un proceso de conciliación definido que compare los datos del sistema antiguo y del nuevo antes de dar de baja el sistema antiguo?
Si no, constrúyalo ahora. No es un seguro opcional — es el único mecanismo que detecta errores de migración cuando aún son baratos de corregir.

5. ¿Se han documentado las decisiones de conservación con un responsable nombrado y rendición de cuentas, en particular para todo lo que no se va a migrar?
Si no, documéntelo antes del go-live. "Decidimos no migrar X" tiene que ser trazable hasta una decisión y una razón, no reconstruido meses después cuando alguien pregunte dónde ha ido a parar algo.

6. Todo lo anterior completado — ¿sigue siendo realista el calendario de migración?
Revise la estimación con honestidad a la luz de lo que encontró el perfilado. Un calendario de migración fijado antes del perfilado era una conjetura; uno fijado después es una estimación, y rara vez son la misma cifra.

7. Migrado y en producción — ¿se ha completado y aprobado formalmente la conciliación?
No dé de baja el sistema antiguo hasta que esto esté hecho y documentado. El sistema antiguo es su único punto de referencia para detectar un error de migración y, una vez desaparecido, ese punto de referencia desaparece con él.

Coste y esfuerzo indicativos

El esfuerzo de migración escala mucho más con la calidad del dato que con el volumen de datos — un conjunto de datos más pequeño y más sucio puede costar fácilmente más de migrar bien que uno más grande y más limpio. Solicite un presupuesto para un perfilado y una estimación con alcance definido.

Preguntas frecuentes

¿Cuántos datos históricos necesitamos migrar realmente?
Menos de lo que asume la mayoría de las empresas. Los requisitos legales de conservación fijan un mínimo, pero ese mínimo se satisface normalmente con un archivo accesible en lugar de con presencia viva en el nuevo ERP, y la mayoría de las consultas operativas no se remontan más de uno o dos años. Establezca la necesidad operativa genuina por separado de la necesidad legal de conservación — normalmente apuntan a respuestas distintas.

¿Cuál es la mayor causa individual de desviación en una migración?
Omitir el perfilado o hacerlo con prisas. Casi todas las desviaciones de migración que hemos heredado de otro partner se remontan a que la calidad del dato se descubrió durante la fase de migración en lugar de antes, momento en el que pasa a ser una renegociación de calendario y presupuesto en lugar de un dato de entrada para la planificación.

¿Debemos limpiar el sistema antiguo o limpiar durante la migración?
Limpie antes, siempre que sea posible. Depurar en el sistema antiguo suele ser más fácil, porque el equipo entiende las peculiaridades y el historial de ese sistema, y significa que el nuevo sistema arranca genuinamente limpio en lugar de heredar una promesa de limpiar más adelante que compite con todas las demás prioridades posteriores al go-live.

¿Cuánto tiempo debemos mantener accesible el sistema antiguo después del go-live?
El suficiente para completar la conciliación con confianza y para atender la primera oleada de peticiones del tipo "necesitamos algo que no migramos" — según nuestra experiencia, un mínimo de varios meses, y más para los datos financieros dados los ciclos legales de auditoría y reporting. Dar de baja demasiado pronto para ahorrar coste de licencias es una falsa economía frecuente y lamentable.

¿Se aplica esto igual a una migración de CRM o de plataforma de ecommerce, no solo de ERP?
Los principios son idénticos — perfilar primero, decidir categorías de forma deliberada, limpiar antes de mover, conciliar antes de dar de baja — aunque los tipos de datos concretos y las reglas de conservación difieran. La disciplina se traslada con independencia de qué sistema se esté migrando.

Cierre — Próximos pasos

La migración de datos fracasa como línea de un plan porque no es en realidad una tarea técnica con una duración predecible — es una serie de juicios de valor sobre en qué necesita convertirse realmente el historial de su negocio, tomados bajo la presión concreta de una fecha de go-live que se acerca. Tratarla como una fase de ejecución en lugar de como un proyecto de toma de decisiones es la razón más común de que se desborde.

El correctivo está disponible en casi cualquier momento: perfile los datos con honestidad, por incómodo que sea el hallazgo, y tome la decisión de migrar, archivar o descartar de forma deliberada para cada categoría en lugar de por defecto. Los proyectos que hacen esto en el mes uno en lugar de en el mes cuatro son los que no renegocian su calendario en el peor momento posible.

Sobre el autor

Bruno Galo es el fundador de Atypical Tech, una consultora de NetSuite que presta servicio a clientes mid-market en toda Iberia. Está especializado en conectar sistemas CRM y ERP para lograr flujos order-to-cash sin fricciones, construyendo pipelines automatizados de gestión de pedidos que eliminan la introducción manual de datos entre los equipos de ventas y de finanzas. Como partner oficial de implementación de Stacksync, Bruno diseña y despliega agentes de IA sobre plataformas de integración para gestionar el enrutado de excepciones, el procesamiento de documentos y la conciliación — convirtiendo flujos de pedidos fragmentados en sistemas fiables y con automonitorización.

LinkedIn: https://www.linkedin.com/in/brunogd

Fuentes

Las URL son a nivel de editor y deben verificarse antes de la publicación.

• Oracle NetSuite, documentación de migración de datos e importación CSV — https://docs.oracle.com/en/cloud/saas/netsuite/
• Agencia Tributaria (España), requisitos de conservación de registros — https://sede.agenciatributaria.gob.es
• Autoridade Tributária e Aduaneira (Portugal), requisitos de conservación de registros — https://info.portaldasfinancas.gov.pt
• DAMA International, Data Management Body of Knowledge (DMBOK) — dimensiones de calidad del dato — https://www.dama.org
• Experiencia de Atypical Tech en proyectos de migración de ERP mid-market en Iberia