En esta nota (10 secciones)
La migración de datos es la parte del proyecto que se estima en una línea y se paga en semanas. Y es, con diferencia, la que más determina si el sistema nuevo se va a usar o no.
El motivo es simple: la confianza en un sistema se gana o se pierde en la primera semana. Si el primer día alguien busca un cliente y aparece tres veces, o busca un saldo y no coincide con lo que sabe, el sistema perdió. A partir de ahí nadie va a apoyar una decisión en un dato que ya lo traicionó.
La decisión que más cuesta y menos se piensa
Cuánta historia migrar.
La respuesta instintiva es "todo". Casi nunca es la correcta.
Traer ocho años de movimientos multiplica el costo de la migración, arrastra los errores de ocho años y produce un sistema nuevo lleno de basura vieja. Y después casi nadie los consulta.
Lo que funciona en la enorme mayoría de los casos:
- Maestros completos: clientes, proveedores, productos. Estos sí, todos, porque son los que se usan todos los días.
- Saldos actuales: cuentas corrientes, stock. Al día del corte.
- Movimientos del último año, quizás dos. Lo suficiente para operar y comparar contra el año anterior.
- El resto queda consultable en el sistema viejo, en modo lectura, durante el tiempo que haga falta.
Esa última línea resuelve el 90% de la ansiedad y cuesta una fracción. Nadie necesita que el remito de 2019 esté adentro del sistema nuevo. Necesita poder encontrarlo si alguna vez lo piden.
Los datos están más sucios de lo que creés
Siempre. Sin excepción. Lo que vas a encontrar:
- El mismo cliente cargado tres veces, con el nombre escrito distinto y saldos repartidos entre las tres fichas.
- Fechas como texto, en tres formatos.
- Campos usados para otra cosa: el de observaciones con el CUIT adentro, porque alguien un día lo necesitó y no había dónde ponerlo.
- Códigos duplicados que el sistema viejo permitía.
- Registros huérfanos: pedidos de clientes que ya no existen.
- Saldos que no cierran contra la contabilidad.
Nada de esto es culpa de nadie. Es lo que le pasa a cualquier base con años de uso y varias personas cargando.
El orden que funciona
1. Diagnóstico antes de cotizar
Antes de estimar la migración hay que mirar los datos. Cuántos registros, cuántos duplicados, cuántos campos vacíos que deberían estar llenos.
Una migración cotizada sin haber abierto la base es un número inventado. Pedí que la miren primero, aunque cueste unas horas.
2. Limpiar en el sistema viejo, no en el nuevo
Contraintuitivo y muy importante. La tentación es migrar todo y arreglar después.
No: unificá los duplicados y corregí los datos malos en el sistema donde la gente los conoce, con la gente que los conoce. En el sistema nuevo, nadie tiene el contexto para saber cuál de las tres fichas del mismo cliente es la buena.
3. Migraciones de prueba, varias
La primera migración no es la definitiva. Se corre, se revisa, se corrige el proceso, se vuelve a correr. Tres o cuatro vueltas es normal.
Lo importante es que la revise gente del negocio, no técnica. Un desarrollador ve que los registros están; el jefe de ventas ve que falta el cliente más importante.
4. Cortar con reglas claras
Antes del día del corte hay que tener definido:
- La fecha y hora exactas del corte.
- Qué pasa con lo que está a mitad de camino: pedidos abiertos, remitos sin facturar.
- Quién valida que los saldos cierran, y contra qué.
- Cómo se vuelve atrás si algo sale mal.
Ese último punto no es pesimismo. Es lo que te permite cortar con tranquilidad.
Las tres validaciones que no se saltean
Después de migrar, antes de operar:
- Los totales cierran. Suma de saldos de cuentas corrientes, valorización de stock, contra el sistema viejo. Si no da, no se arranca.
- Los diez casos más importantes están bien. Tus diez clientes principales, tus veinte productos que más rotan. Revisados a mano, uno por uno, por alguien que los conoce.
- Las cantidades coinciden. Cuántos clientes había, cuántos hay. Cualquier diferencia tiene que tener explicación.
Suena obvio y se saltea constantemente por presión de calendario.
Lo que cuesta
Como referencia, la migración suele ubicarse entre el 10% y el 25% del costo del desarrollo, y sube fuerte cuando el sistema viejo no tiene forma de exportar.
El factor que más la encarece no es el volumen: es cómo se sacan los datos del sistema viejo. Si exporta a un formato razonable, es trabajo acotado. Si hay que leer directamente de su base, o peor, si sólo se puede sacar por pantalla, el número cambia de categoría.
Averiguá eso antes de pedir presupuesto. Es la pregunta que más mueve el número.
Un consejo que vale por todo lo demás
Guardá una copia completa del sistema viejo, tal como estaba el día del corte, y no la borres.
No la copia de seguridad del proveedor: una copia tuya, en un lugar que controlás vos. Es barato, y es lo único que te salva de la pregunta que aparece nueve meses después: "¿y esto cómo era antes?".