En resumen
Migrar un sistema legado sin perder datos exige tres cosas en orden: un mapeo campo por campo con las reglas de conversión escritas, cargas de ensayo repetidas hasta que dejan de producir sorpresas, y una conciliación que pruebe registro por registro que nada desapareció. El cutover es la parte corta; lo que decide el resultado es todo lo anterior.
Los proyectos no fallan en el cutover
Toda migración tiene un documento que nadie quiere escribir y que decide si el proyecto sale bien. No tiene un nombre atractivo: es el mapeo de campos, una tabla que dice, campo por campo, de dónde sale cada dato en el sistema viejo y dónde aterriza en el nuevo. Un campo de origen sin destino es dato que desaparece en el cutover; un campo de destino sin origen es una pantalla que el lunes abre vacía.
En sistemas en español hay una falla que aparece siempre y que casi nunca está en el plan: la codificación. Una base vieja en Latin-1 leída como UTF-8 convierte «Muñoz» en «Muñoz», y lo peor es que la carga no falla — termina bien, con el dato roto adentro. Cuando se descubre, semanas después, ya hubo escrituras encima y volver atrás dejó de ser trivial.
El otro punto ciego es el histórico. El sistema viejo guarda documentos fiscales que la autoridad puede pedir años después, y apagarlo el lunes siguiente al cutover porque «ya migramos» es una decisión que se toma sin consultar a quien va a tener que responder por ella.
Cómo lo hacemos
Leer los tipos reales, no los documentados
En sistemas legados, una fecha guardada como texto libre es más común de lo que nadie espera. El mapeo registra lo que el dato es de verdad, que con frecuencia no es lo que el esquema declara.
La codificación se prueba con los datos feos
Nombres con ñ, apellidos con tilde, direcciones con caracteres que alguien pegó desde Word. Si la prueba se hace con los primeros mil registros ordenados por código, esos datos ni aparecen — y son exactamente los que rompen.
Identificadores con su regla de país
RFC, NIT, RUT y CUIT tienen formatos y dígitos verificadores distintos. Normalizarlos todos con la misma regla genera duplicados que después nadie sabe cuál es el bueno, y el momento de decidirlo es antes de cargar, no después.
Conciliación, no confianza
Después de cada carga se comparan los dos lados: conteos, totales y verificación por registro. Probar que no se perdió nada es una actividad distinta de creerlo, y solo la primera sobrevive a una pregunta del área financiera.
Preguntas frecuentes
El sistema viejo no tiene documentación. ¿Es un bloqueante?
No, es el caso normal. El esquema, el dato en sí y las personas que operan el sistema son tres fuentes que juntas reconstruyen casi todas las reglas. Lo que sí frena de verdad no es la falta de documentación, sino la falta de acceso a una copia del dato parecida a producción.
¿Podemos apagar el sistema viejo apenas migramos?
Casi nunca conviene. El histórico fiscal y contable se sigue pudiendo pedir, así que el sistema viejo se deja en modo lectura por un período acordado, o el histórico se exporta a un formato que sobreviva al proveedor. Apagarlo el lunes siguiente ahorra una licencia y compromete una respuesta que puede llegar años después.
¿Se pueden correr los dos sistemas en paralelo?
Por un período, en general sí, y reduce bastante el riesgo del cutover. El costo es que las escrituras tienen que ir a un solo lado o conciliarse continuamente — mantener los dos como fuente de verdad crea un problema de divergencia peor que la migración misma.
También hacemos
Leer esto en portugués
La versión en portugués de esta página entra en más detalle: /servicos/migracao-de-sistema-legado.