Todo proyecto de sistema nuevo tiene una fecha que nadie cuestiona en voz alta — y una fase que suele empujar esa fecha. No es el desarrollo, no es la prueba integrada, no es la capacitación. Es la conversión de datos: sacar lo que existe en el sistema antiguo y ponerlo en el nuevo de una forma que el negocio reconozca como suya.

Es la fase más subestimada porque parece mecánica. Extraer, transformar, cargar. En la práctica, cada columna carga una decisión de negocio que nadie documentó en veinte años de operación, y la mayoría de esas decisiones solo aparece cuando la carga falla — o peor, cuando pasa y el número sale distinto. La IA cambió la economía de esta fase, pero cambió dónde se puede ganar tiempo, no dónde se puede delegar la responsabilidad.

La conversión no es tarea técnica: es una fila de decisiones

Cuando la conversión se atrasa, el diagnóstico apresurado es siempre el mismo: «la extracción está lenta» o «la herramienta es mala». Casi nunca es eso. Lo que traba es la fila de preguntas que nadie puede responder solo.

¿Cuál es el saldo correcto de un ítem que aparece en tres lugares con valores distintos? ¿Aquel cliente registrado cuatro veces con grafías diferentes es un cliente o son cuatro? Documento abierto en 2011, sin movimiento desde 2014 y sin cancelar: ¿va? El campo libre donde el equipo empezó a escribir el código del vendedor hace ocho años, ¿en qué se convierte en el modelo nuevo?

Ninguna de estas preguntas es técnica. Todas dependen de alguien del negocio con autoridad para decidir y asumir el resultado. Por eso, el primer entregable de una conversión bien conducida no es un script: es la lista de decisiones pendientes con dueño y plazo. Mientras no se cierra, todo trabajo de carga es provisorio.

Lo que realmente va: el alcance es el primer ahorro

La pregunta que más dinero ahorra en conversión es también la más impopular: qué no va.

El reflejo del proyecto es llevar todo — «por seguridad». Solo que el histórico convertido no es histórico gratis: hay que mapearlo, limpiarlo, cargarlo, validarlo y después mantenerlo. Cada año extra de histórico multiplica el esfuerzo de las cinco etapas y, encima, engorda la base nueva desde el primer día.

Un alcance honesto suele tener tres capas. Los maestros van completos, pero depurados — cliente, proveedor, material, plan de cuentas, centro de costo. Los saldos van en la posición de corte, no movimiento por movimiento. El movimiento histórico va solo donde existe obligación legal o uso operativo real; el resto queda consultable en el ambiente antiguo o va a archivado. Es exactamente la misma disciplina de archiving y volumen de datos: decidir qué merece estar en la base caliente.

Cuando el negocio entiende que «no convertir» no es «perder», el alcance cae — y la fase entera se achica con él.

El mapeo con IA: propuesta, nunca veredicto

El documento de mapeo — campo de origen, campo de destino, regla de transformación — es el corazón de la conversión y, históricamente, semanas de planilla. Es acá donde la IA cambia la cuenta.

Con el esquema del origen, la documentación del destino y una muestra real de datos, un asistente devuelve en horas lo que llevaba semanas: propuesta de mapeo campo por campo, justificación de cada elección, script de transformación, lista de valores que no encajan en ningún dominio del destino y las consultas de validación correspondientes. La ganancia no es escribir más rápido — es revisar en vez de redactar. Leer y corregir mil líneas de propuesta es mucho más barato que producirlas desde cero.

Tres usos rinden especialmente bien. Dominio de valores: la IA lee los valores distintos de un campo libre y propone la clasificación, revelando de paso lo que se estaba usando fuera del estándar. Deduplicación: en lugar de comparación exacta, comparación por similitud de nombre, dirección y documento, con puntaje — la IA sugiere los grupos, el negocio confirma. Anomalía después de la carga: señalar lo que quedó estadísticamente raro respecto del origen, que es donde el error de conversión mejor se esconde.

La limpieza ocurre en el origen — y antes

Existe una tentación fuerte de limpiar durante la carga, con reglas en el script de transformación. Funciona en el primer ciclo y cobra caro después: la regla vive solo en el código de conversión, nadie del negocio la ve y, cuando el dato llega mal al destino, la discusión pasa a ser sobre la regla en vez de ser sobre el dato.

Limpiar en el origen es más lento al principio y mucho más barato al final. El maestro duplicado lo resuelve quien es su dueño, con la decisión registrada donde el negocio la puede ver; el ítem sin clasificación lo clasifica quien sabe clasificar. La conversión entonces carga un dato que ya es bueno — y la validación pasa a medir la carga, no la limpieza.

Vale una regla práctica: si la corrección necesita conocimiento de negocio, es del origen. Si es solo formato — fecha, separador decimal, codificación de caracteres, tamaño de campo —, puede ser de la transformación.

Validar en capas, de lo barato a lo caro

Conversión sin reconciliación es apuesta con fecha marcada. Tres capas, en este orden, resuelven casi todo.

1. Conteo — registros por objeto, origen contra destino, con la diferencia explicada línea por línea. Barato, corre en cada ciclo y detecta carga parcial y duplicación de reproceso.
2. Totales que el negocio reconoce — saldo por cuenta, stock por depósito, abierto por cliente. Esta es la capa que importa: si el controller no reconoce el número, la conversión no está lista, aunque el conteo cierre.
3. Muestreo dirigido a los bordes — el mayor valor, el más antiguo, el de más decimales, el que tiene acentos, el que tiene campo nulo, el registro que nadie entiende. El error de conversión vive en las excepciones, no en el promedio.

Cada ciclo de carga tiene que terminar con ese informe firmado. Sin él, el equipo descubre el problema en el primer cierre después del go-live, que es el peor lugar posible para descubrirlo.

Ciclos de carga: ensayar antes de que valga

Una conversión que corre una sola vez, en el cutover, es apuesta. El patrón que funciona es el opuesto: varios ciclos completos antes de la fecha real, cada uno con alcance mayor y más gente del negocio mirando el resultado.

El primer ciclo mide la mecánica — tiempo, orden de dependencia entre objetos, qué se rompe. El segundo mide la calidad, con el negocio reconciliando de verdad. El tercero es ensayo de cutover cronometrado: empieza y termina dentro de la ventana, con la misma gente y el mismo guion que van a correr el día real. Si el tercer ciclo no entra en la ventana, el problema es de cronograma, y ese es un descubrimiento mucho mejor de hacer tres semanas antes que en la madrugada del cambio.

Cada ciclo también mejora el origen: lo que la validación rechaza vuelve como tarea de limpieza. Por eso empezar temprano compensa incluso con alcance incompleto — el valor está en el lazo de corrección, no en la carga en sí. Es la misma disciplina que sostiene una implementación de SAP sin sobresaltos.

Lo que queda después del go-live

Cuando la conversión está bien hecha, tres cosas sobreviven al proyecto y siguen valiendo.

La trazabilidad: para cada registro convertido se puede decir de dónde vino y qué regla lo transformó. Eso responde auditorías y cierra en minutos la discusión de «ese número está mal» que, sin rastro, consume semanas.

Las reglas de calidad: lo que la validación de la conversión probó se vuelve verificación permanente. La base nueva nace con el criterio de calidad ya definido, en vez de degradarse en silencio hasta la próxima migración.

Y las decisiones documentadas: qué quedó afuera, por qué, dónde consultarlo. Un año después, cuando alguien pregunte por un documento de 2013, la respuesta existe.

El límite honesto: la IA no convirtió nada sola en ningún proyecto que condujimos. Leyó esquemas, propuso mapeo, generó script y consulta, agrupó duplicados por similitud y señaló anomalías después de la carga. Las decisiones que cuestan caro — qué es duplicado, qué se puede redondear, qué no necesita ir — siguieron siendo de gente que responde por el dato. Lo que cambió es que esa gente pasó a gastar el tiempo decidiendo, y no tipeando planillas.

Para preparar esta fase, dos materiales de la Inove Academy ayudan antes de empezar. La guía rápida de migración a la nube trata la misma pregunta en otra escala — qué va como está y qué merece rediseño antes de cruzar. Y el e-book de implementación muestra por qué la mayoría de los problemas de proyecto no es técnica, con la conversión de datos como ejemplo recurrente.