Migración de datos entre programas: plan, pruebas y cuadre
Migrar datos es pasar la información a un sistema nuevo sin perderla ni estropearla. Se hace con inventario, mapa de campos, limpieza, cargas de prueba repetibles y un cuadre de recuentos y totales, con copia de seguridad y plan de vuelta atrás.
La migración de datos es pasar la información de un sistema a otro (de unas hojas de cálculo a un programa de gestión, de un programa antiguo a uno nuevo, de un servidor propio a la nube) sin perderla ni estropearla por el camino. Una migración bien hecha no se mide por cuántos registros se copian, sino por si al terminar las cifras cuadran, las relaciones siguen intactas y el equipo puede trabajar con el sistema nuevo desde el primer día.
Qué se migra y en qué casos
En una empresa, las migraciones suelen ser de uno de estos tipos:
- De hojas de cálculo a un sistema: el caso más habitual al implantar el primer ERP o CRM. Los datos existen, pero repartidos, con formatos distintos y duplicados.
- De un programa a otro: cambiar de ERP, de CRM o de programa de facturación. Hay estructura, pero no es la misma.
- De una base de datos de escritorio a una aplicación web: por ejemplo, de Access a un sistema en la nube.
- De un servidor a otro: el mismo programa, en otro sitio. Es la más mecánica, pero no la más fácil: lo que falla aquí suele ser lo que nadie había documentado.
Cada caso tiene su guía: cambiar de ERP, migrar Access a web o, si el programa antiguo es el problema, qué hacer con el software legacy. Aquí va lo que tienen en común.
Qué suele salir mal en una migración
- Relaciones rotas: las facturas llegan, pero ya no saben de qué cliente son; las notas llegan, pero sueltas.
- Datos que cambian de significado: un campo «estado» que en el sistema antiguo tenía cinco valores y en el nuevo tiene tres.
- Formatos: fechas al revés, decimales con punto donde se esperaba coma, tildes y eñes convertidas en símbolos raros.
- Duplicados multiplicados: el mismo cliente escrito de tres formas acaba siendo tres clientes.
- Lo que no estaba en ningún sitio: reglas que el programa antiguo aplicaba sin que nadie las hubiera escrito.
- El día del cambio sin vuelta atrás: si la carga definitiva falla y no hay copia, no hay plan B.
El plan de migración, paso a paso
- Inventario. Qué datos hay, dónde están, quién los usa y cuáles se necesitan de verdad en el sistema nuevo.
- Mapa de campos. Cada dato de origen tiene un destino, una transformación si hace falta (formato, unidades, valores) o una decisión escrita de no llevarlo.
- Limpieza. Duplicados, registros vacíos, valores que nadie entiende. Se limpia antes de cargar, no después.
- Carga de prueba. Sobre una copia del sistema nuevo, con todos los datos o con una muestra representativa.
- Cuadre. Recuentos y totales en origen y en destino: número de clientes, facturas por año, importe pendiente de cobro, stock por almacén. Cada diferencia tiene que tener explicación.
- Validación por quien usa los datos. Comercial, administración y almacén revisan lo suyo. Ven errores que un recuento no ve.
- Corte. Se congela el sistema antiguo (en solo lectura), se hace la carga definitiva, se vuelve a cuadrar y se abre el nuevo.
- Plan de vuelta atrás. Copia de seguridad antes de la carga definitiva y un criterio escrito de cuándo se deshace.
Lo que hace segura una migración no es un buen día de cambio, sino haber hecho antes la carga de prueba y el cuadre las veces que haga falta.
Detalles técnicos que evitan sustos
- Conserva el identificador antiguo en cada registro nuevo. Permite rastrear cualquier dato hasta su origen y repetir la carga sin duplicar.
- Carga en orden: primero lo que no depende de nada (clientes, artículos), después lo que depende (pedidos, facturas, historial).
- Fija la codificación de caracteres y los formatos de fecha y decimales antes de exportar, y compruébalos con registros que lleven tildes, eñes e importes con céntimos.
- Decide qué histórico migrar con detalle y qué basta con un saldo inicial. No todo el pasado necesita vivir en el sistema nuevo; lo que no se lleve se archiva de forma que se pueda consultar.
- Documentos adjuntos aparte: contratos, fotos y PDF se migran con su enlace al registro, y se comprueba que se abren.
- Repetible: la carga tiene que poder ejecutarse de nuevo desde cero. Si solo se puede hacer una vez, no se puede probar.
Datos personales durante la migración
Si migras datos de clientes, empleados o contactos, la protección de datos se sigue aplicando durante todo el proyecto. El artículo 5 del Reglamento General de Protección de Datos (RGPD) pide que los datos personales sean adecuados, pertinentes y limitados a lo necesario, exactos y, si fuera necesario, actualizados, y conservados durante no más tiempo del necesario para los fines del tratamiento. Una migración es un buen momento para aplicarlo: lo que no necesitas no se lleva.
Y el artículo 32 pide medidas de seguridad adecuadas al riesgo que, según el caso, pueden incluir el cifrado de datos personales y la capacidad de restaurar la disponibilidad y el acceso a los datos de forma rápida tras un incidente. En una migración eso se traduce en ficheros de exportación que no viajan por correo ni se quedan olvidados en un portátil, accesos temporales que se retiran al acabar y una copia de seguridad antes de tocar nada.
Quién hace qué en una migración
El proveedor técnico prepara las exportaciones, las transformaciones y las cargas; la empresa decide qué se lleva, valida los datos y firma el cuadre. Ninguna de las dos partes puede hacer el trabajo de la otra: el proveedor no sabe qué cliente está duplicado y la empresa no debería tocar la base de datos a mano.
En los proyectos que hacemos, la migración de datos forma parte del paso de integración, junto con los pagos, el correo o el programa que ya usas. Antes de cualquier cambio en la base de datos hacemos una copia de seguridad, y los cambios de estructura son pequeños y reversibles, y antes de sustituir la versión en marcha comprobamos que la nueva arranca de verdad. Cuánto pesa la migración en el presupuesto de un proyecto lo explicamos en precio de un ERP a medida: qué pagas de verdad.
Fuentes consultadas
Comprobadas el 27 de septiembre de 2026. Enlazamos la fuente original para que puedas consultar el texto vigente.
Preguntas frecuentes
¿Qué es una carga de prueba en una migración de datos?
Es hacer la migración completa sobre una copia del sistema nuevo, antes del cambio definitivo, para comprobar recuentos, totales y relaciones y dejar que el equipo revise sus datos. Se repite hasta que cuadra.
¿Hay que migrar todo el histórico?
No siempre. A menudo basta con migrar con detalle los últimos años y llevar el resto como saldo inicial o en un archivo consultable. Se decide por lo que el equipo necesita consultar a diario y por cuánto tiempo hay que conservar cada dato.
¿Cómo se sabe que una migración ha salido bien?
Cuadrando: el número de registros y los totales importantes (facturado, pendiente de cobro, stock) coinciden en origen y destino, o cada diferencia tiene una explicación escrita, y quienes usan los datos los han validado.
¿Se puede migrar sin parar el trabajo?
En muchos casos, sí, si el trabajo pesado (limpieza, cargas de prueba, cuadres) se hace antes y el día del cambio solo queda la carga final de lo último, con el sistema antiguo en solo lectura unas horas.
¿Algo de esto encaja con tu negocio? Cuéntanos cómo lo haces hoy.