En casi todos los proyectos donde reemplazamos un sistema existente, la conversación difícil no es sobre funcionalidad. Es el día que hay que decidir qué pasa con los nueve años de información que ya están adentro.
Esa parte casi nunca aparece en la cotización con el peso que tiene. Se menciona como una línea, "migración de datos", y se asume que es un paso técnico al final, algo así como copiar archivos de una carpeta a otra. Después resulta que es el trabajo que define si el sistema nuevo arranca con la confianza del equipo o con una sospecha permanente de que los números no cuadran.
Vale la pena entenderla antes de contratar, porque es también uno de los factores que más mueve el precio y el cronograma de un desarrollo. Si te interesa el panorama completo de qué mueve una cotización, lo desarrollamos en cuánto cuesta un sistema a medida.
No es copiar, es traducir
El sistema viejo y el nuevo no piensan igual. Ahí está el trabajo real.
En el viejo, el cliente y el proveedor pueden vivir en la misma tabla porque alguien tuvo que resolver algo un martes. Hay un campo de notas donde se anotaron durante años cosas que en el sistema nuevo son campos propios: la condición de pago, el contacto alterno, la advertencia de que a este cliente hay que facturarle a otro NIT. Hay fechas guardadas como texto en tres formatos distintos porque el formulario cambió dos veces.
Nada de eso está mal. Es lo que le pasa a un sistema que sirvió durante una década. Pero significa que la migración no es un traslado, es una traducción, y toda traducción exige decidir. Cada decisión necesita a alguien del negocio que la tome, no a alguien de desarrollo que la adivine.
Qué se migra, y qué no
Esta es una decisión de negocio, y es la primera que pedimos resolver.
No todo el histórico tiene que entrar al sistema nuevo. La pregunta útil no es "cuántos años queremos", que casi siempre se responde con "todos", sino tres preguntas más concretas: qué información se consulta de verdad en la operación diaria, qué información tiene que estar disponible por obligaciones de conservación, algo que tu contador o tu asesor legal define y no nosotros, y qué información solo da tranquilidad tenerla.
Las dos primeras se migran. La tercera casi siempre se resuelve mejor de otra forma: un archivo consultable, una copia del sistema viejo en solo lectura, una exportación completa entregada y documentada. Cuesta una fracción y sirve igual, porque nadie va a operar sobre datos de 2014.
Hay una distinción que ayuda a ordenar esto. Los saldos, los catálogos y los datos maestros tienen que estar exactos y completos, porque el sistema nuevo va a calcular sobre ellos. El detalle histórico de transacciones es referencia: necesita ser fiel y consultable, no necesariamente estar dentro del mismo módulo.
Los datos sucios no son la excepción
Toda migración destapa lo que ya estaba. Duplicados que nadie había contado, clientes escritos de cuatro maneras, números de teléfono con formato libre, registros incompletos que el sistema viejo permitía y el nuevo, con razón, no.
Aquí hay una frontera que conviene tener clara desde el principio: un desarrollador puede detectar y reportar duplicados, pero no puede decidir cuál de dos registros es el bueno. Eso lo sabe quien atiende a ese cliente. Cuando esa decisión se delega a quien escribe el código, se resuelve por regla automática, y las reglas automáticas sobre datos sucios producen errores silenciosos: el que se descubre seis meses después, cuando alguien nota que un historial está partido en dos.
Lo que sí se puede hacer, y es lo que hacemos, es convertir esa limpieza en una tarea acotada y ordenada. Un reporte de casos dudosos, en un formato que el equipo pueda revisar, con un plazo. No es glamoroso y es la diferencia entre arrancar limpio y arrastrar el desorden a un sistema nuevo y más caro.
Cómo se sabe que la migración salió bien
Una migración sin criterio de aceptación escrito no terminó, solo se dejó de hacer. Lo que pedimos acordar antes de mover un solo registro:
Conteos que cuadren. Cuántos clientes, cuántas facturas, cuántos registros por año en el viejo y en el nuevo, y una explicación para cada diferencia. Las diferencias van a existir, porque parte de lo que había eran duplicados o basura; lo que no puede existir es una diferencia que nadie sepa explicar.
Sumas de control. Los totales que el negocio ya conoce, saldos por cliente, ventas por mes, existencias por producto, comparados contra el sistema viejo. Si los dos coinciden, el equipo confía en el nuevo. Si no, se sabe exactamente dónde buscar.
Muestreo revisado por una persona. Un puñado de registros elegidos por el negocio, incluidos los casos raros que todos conocen, revisados a mano en las dos pantallas.
Y la migración se corre más de una vez. Un ensayo en seco con los datos reales, semanas antes del corte, es lo que convierte la migración en un procedimiento repetible y medido en horas en lugar de una operación a ciegas el día del arranque. Si quieres ver cómo encaja esto en el resto del proyecto, está en cómo estructuramos un proyecto.
El corte es un plan operativo, no una fecha
La parte que más se subestima no es técnica: es el día del cambio.
Entre el momento en que se extraen los datos del sistema viejo y el momento en que el equipo empieza a trabajar en el nuevo, la operación no se detiene. Alguien va a facturar, alguien va a recibir mercadería. Eso hay que resolverlo antes, y hay tres formas: se congela la operación durante una ventana corta, se captura dos veces durante unos días, o se arranca con un corte por fecha y el sistema viejo queda en solo lectura para consultar lo anterior.
Las tres son válidas y se eligen según el negocio. Lo que no es un plan es "lo hacemos el fin de semana". Un plan de corte dice quién hace qué, en qué orden, cuánto dura cada paso, quién confirma que el paso anterior salió bien, y qué se hace si a la mitad algo falla. Esa última parte, el camino de regreso, es la que distingue un arranque tranquilo de un lunes malo.
Si estás evaluando reemplazar un sistema y esta es justamente la parte que te preocupa, es una de las cosas que se pueden ordenar en una llamada de treinta minutos.
Cuándo no migrar es la respuesta correcta
Hay casos en los que migrar el histórico es gastar dinero en mover un problema.
Si los datos del sistema viejo no son confiables y el equipo ya no los usa para decidir, si la estructura es tan distinta que cada registro exige interpretación manual, o si el histórico que de verdad se consulta son los últimos meses, la opción honesta es otra: arrancar en limpio con los datos maestros y los saldos, dejar el sistema viejo accesible en solo lectura, y entregar una exportación completa y documentada por si alguna vez hace falta.
Lo decimos cuando lo vemos, aunque signifique una línea menos en la propuesta. Migrar datos que nadie va a usar es costo sin retorno, y además retrasa el arranque del sistema que sí estabas comprando.
Qué preguntar antes de firmar
Cuatro preguntas que separan una propuesta que ya hizo esto de una que la va a improvisar. Quién decide qué se migra, y cuándo se toma esa decisión. Cuántas corridas de prueba están incluidas antes del corte. Cuál es el criterio de aceptación escrito, con nombre y apellido de los conteos y las sumas que se van a comparar. Y qué pasa con el sistema viejo después del arranque, quién lo apaga, cuándo, y quién se queda con una copia.
Si una propuesta no puede responderlas, el riesgo no desapareció: solo está sin asignar. Hay más preguntas de este tipo en doce preguntas antes de contratar una agencia, y todas comparten la misma lógica.
Cómo lo trabajamos
En nuestros proyectos la migración es parte del desarrollo, no un anexo: se diseña junto al modelo de datos, se ensaya con datos reales antes del corte, y el criterio de aceptación se acuerda por escrito al inicio. Lo mismo aplica a la salida: el código, los datos y la documentación quedan a tu nombre, con una exportación completa que no depende de nosotros. Eso y el resto del alcance está en sistemas a medida.
Si tienes un sistema que ya no te alcanza y la duda es qué hacer con lo que hay adentro, la llamada de descubrimiento dura treinta minutos, es gratuita y sin compromiso. Salir de ahí con claridad sobre qué se migra y qué no ya es un resultado útil, incluso si después decides hacerlo con alguien más. Puedes agendarla aquí.
¿Esto aplica en tu empresa?
30 minutos, sin compromiso, para revisar tu caso y decidir si hay algo que construir.