Un plan de migración de datos a un nuevo software tiene seis fases: inventariar las fuentes, mapear cada campo al destino, limpiar, hacer cargas de prueba, conciliar origen y destino con cifras, y ejecutar el corte con una vía de vuelta atrás. La migración está terminada cuando puedes demostrar que los datos cuadran, no cuando la carga acaba sin errores. Es una fase que incluimos en cada proyecto de desarrollo de aplicaciones web a medida en Madrid.
Es una de las partes de un proyecto de software que más se subestiman. El sistema nuevo puede estar perfecto, pero si el primer día aparecen clientes duplicados, saldos que no coinciden o facturas sin su cliente, el equipo deja de confiar en él y vuelve al Excel. Y recuperar esa confianza cuesta más que haber migrado bien. Por eso, al elegir una consultora de software a medida en Madrid, pregunta cómo plantea la migración.
Al terminar tendrás una checklist por fases y un método para comprobar con números que no se ha perdido ni alterado nada por el camino, lista para sumarla al presupuesto de tu software a medida.
Qué es una migración de datos a un nuevo software
Una migración de datos es el traslado controlado de la información de uno o varios sistemas de origen, como hojas de cálculo, un programa antiguo o un ERP anterior, a un sistema nuevo con otra estructura. Incluye transformar los datos al nuevo modelo, corregir los errores que arrastran y verificar que el resultado es completo y exacto.
En los proyectos de desarrollo de software a medida con integraciones en Madrid la tratamos como una fase con su propio plan y presupuesto, porque de ella depende que el equipo adopte el sistema.
No hay que confundirla con la migración de una web, donde la preocupación es mantener el posicionamiento; para ese caso tienes la guía para cambiar de web sin perder SEO.
Fase 1: inventario y decisión de qué migrar
Lista todas las fuentes: el programa actual, los Excel satélite, el correo con adjuntos o la intranet corporativa que alguien usa como archivo. Para cada tipo de dato decide qué va al sistema nuevo:
- Datos maestros: clientes, productos, proveedores, tarifas. Casi siempre se migran.
- Transacciones abiertas: pedidos pendientes, stock actual, saldos, facturas por cobrar. Se migran, y son las que más se revisan.
- Histórico cerrado: se migra solo si el equipo lo consulta a menudo. Si no, basta con archivarlo en formato consultable.
La ley marca un mínimo de conservación. El artículo 30 del Código de Comercio obliga a guardar libros, correspondencia y justificantes durante seis años, y la Agencia Tributaria recuerda que las facturas deben conservarse durante el plazo de prescripción de cuatro años. Conservar no obliga a migrar: un archivo de solo lectura cumple si garantiza la integridad y la legibilidad de los documentos.
Con los datos personales ocurre lo contrario. El RGPD exige en su artículo 5 que sean exactos y que se conserven solo el tiempo necesario para su finalidad. La migración es el mejor momento para no trasladar contactos que ya no deberías tener.
Fase 2: mapeo de campos
Por cada entidad, una tabla que relaciona el campo de origen, el campo de destino y la regla de transformación. Por ejemplo, la columna «Cliente» de un Excel de pedidos se convierte en una referencia al cliente por su NIF, y la columna «Estado», escrita a mano de cinco formas distintas, en un valor de una lista cerrada. Si el origen es una hoja de cálculo, en cómo convertir procesos de Excel en una aplicación web explicamos cómo pasar de pestañas a un modelo de datos relacional.
El mapeo lo valida también alguien del negocio, porque es donde aparecen las reglas que nadie había escrito. Las transformaciones se programan como scripts que forman parte de la lógica de datos del backend del sistema nuevo, se versionan con el resto del código y se pueden repetir tantas veces como haga falta.
Fase 3: limpieza y deduplicación
Fechas escritas como texto, importes con la coma decimal en un sitio y el punto en otro, el mismo cliente con tres nombres distintos, errores que se multiplican si alguien extrajo los datos con IA sin revisar las facturas. Se corrigen en origen siempre que sea posible, para que la corrección no dependa del script de migración. Cada regla de limpieza queda documentada, porque habrá que aplicarla otra vez en el corte final.
Para encontrar duplicados, normaliza antes de comparar: el NIF en mayúsculas y sin espacios, los nombres sin tildes y sin la forma societaria, los teléfonos sin prefijo. Imagina una distribuidora que tiene a «Talleres Pérez, S.L.», «TALLERES PEREZ SL» y «Talleres Pérez» como tres clientes distintos, cada uno con parte de su historial. La fusión la decide alguien que conozca a esos clientes; el script solo propone candidatos, igual que haría un CRM a medida con deduplicación.
Fase 4: cargas de prueba
Nunca migres por primera vez el día del cambio. Haz al menos dos cargas completas en un entorno de pruebas, con los datos reales y el script definitivo, y deja que los usuarios trabajen con ellas. Así sabrás cuánto tarda la carga, qué errores aparecen y si el sistema nuevo se comporta como esperan. Si el nuevo software es un ERP a medida construido por módulos, cada módulo puede tener su propia carga de prueba.
Fase 5: conciliación con números
Validar fila a fila, con las reglas del backend en Express o NestJS, evita que entren datos mal formados, pero no demuestra que no falte nada. Para eso se concilia: se comparan recuentos, sumas e incluso una huella del contenido completo entre origen y destino.
CodeZone Pro Tip: demuestra que los datos cuadran comparando recuentos, sumas y una huella del contenido
-- Conciliación origen/destino: se ejecuta tras cada carga de prueba y antes del corte
WITH origen AS (
SELECT count(*) AS filas, sum(importe) AS total,
md5(string_agg(concat_ws('|', numero, cliente_nif, fecha, importe), ',' ORDER BY numero)) AS huella
FROM staging.facturas_origen
), destino AS (
SELECT count(*) AS filas, sum(f.importe) AS total,
md5(string_agg(concat_ws('|', f.numero, c.nif, f.fecha, f.importe), ',' ORDER BY f.numero)) AS huella
FROM erp.facturas f JOIN erp.clientes c ON c.id = f.cliente_id
)
SELECT o.filas AS filas_origen, d.filas AS filas_destino,
o.total AS importe_origen, d.total AS importe_destino,
o.huella = d.huella AS contenido_identico -- false: hay diferencias aunque cuadren los totales
FROM origen o, destino d;
-- Qué facturas difieren: filas del origen que no están idénticas en el destino
SELECT numero, cliente_nif, fecha, importe FROM staging.facturas_origen
EXCEPT
SELECT f.numero, c.nif, f.fecha, f.importe
FROM erp.facturas f JOIN erp.clientes c ON c.id = f.cliente_id;La primera consulta compara filas, importes y una huella calculada sobre todo el contenido, ordenado para que sea reproducible. Si una factura se ha asignado al cliente equivocado, los totales cuadran pero la huella no, y la segunda consulta te dice exactamente cuál es. Para que funcione, origen y destino deben tener los mismos tipos de dato antes de comparar. Con este informe, el paso a producción se decide con cifras.
Fase 6: el corte y la marcha atrás
El corte es el momento en que el sistema antiguo deja de usarse. Se prepara como un procedimiento escrito, con horarios y responsables de tu lado y del equipo de desarrollo web en Madrid que lo ejecuta:
- Congelar los cambios en el origen y avisar a los usuarios.
- Ejecutar la carga final con los scripts ya probados.
- Conciliar y decidir con criterios fijados de antemano, por ejemplo cero diferencias en saldos de clientes.
- Si algo falla, volver al sistema anterior, que se mantiene intacto en solo lectura.
La guía de implantación de Dynamics 365 de Microsoft recomienda ensayar el corte completo en un entorno de pruebas, lo que llama un ensayo general.
Cuando el nuevo sistema sustituye a una aplicación antigua por partes, la migración se hace módulo a módulo, siguiendo el plan para modernizar una aplicación legacy sin detener la actividad. Y si el destino es un CRM, antes de migrar conviene decidir si adaptarás uno comercial o desarrollarás el tuyo, porque el modelo de datos cambia mucho entre ambos.
Después de migrar
Mantén el origen accesible en solo lectura durante un tiempo acordado y revisa durante las primeras semanas las incidencias relacionadas con datos. Si el sistema nuevo alimenta otros, como un portal donde tus clientes consultan sus facturas o una app de campo integrada con el ERP y el CRM, comprueba también que lo que ven coincide con el origen. El histórico archivado puede consultarse desde el panel de administración, con permisos y registro de accesos. Y presupuesta el esfuerzo: la migración suele ser una partida propia del proyecto y afecta al coste de mantener el software en los meses siguientes.
El Precio de una Migración que No Cuadra
Una migración mal verificada se descubre en el peor momento: al cerrar el mes, al reclamar una factura o en una inspección. Cada diferencia que aparece después del corte es más cara de corregir y resta confianza al sistema nuevo. Por eso, en nuestra agencia de software en Madrid la conciliación es un entregable más.
En Codezone planificamos y ejecutamos la migración de datos dentro de cada proyecto y seguimos después con soporte técnico en Madrid tras la puesta en marcha. Si vas a cambiar de sistema, cuéntanos de dónde vienen tus datos y adónde van y te ayudamos a preparar el plan.
