La tercera parte terminó la limpieza: nombres unificados, fechas en un solo formato, números que de verdad son números, y significados que antes vivían en los colores de las celdas convertidos en campos escritos. Los datos están listos para moverse. Lo que queda es la decisión que determina si la transición pasa sin ruido o se convierte en semanas de confusión: ¿qué se migra primero?

Parece un detalle técnico para quien implementa. En realidad es una decisión operativa, y es tuya. Tu empresa no se detendrá por la migración. Los clientes harán pedidos, las facturas saldrán, los proveedores entregarán, todo ello mientras la mitad de tus datos está en un lugar y la otra mitad en otro. La secuencia correcta es lo que hace que ese periodo sea manejable en lugar de una etapa en la que todos trabajan dos veces.

Por qué la migración de golpe no funciona

El instinto es comprensible: moverlo todo durante el fin de semana, abrir el domingo con el nuevo sistema y listo. Ese escenario suele fracasar por tres razones que no tienen nada que ver con la calidad del sistema.

Primero, descubrirás durante la migración más de lo que esperas. Toda migración saca a la luz datos que faltan y que nadie había notado: un cliente sin número fiscal, un artículo sin unidad de medida, una factura sin referencia. Si lo mueves todo junto, todos esos descubrimientos llegan a la vez, en el momento más ajustado posible.

Segundo, tu equipo aprende el sistema mientras lo opera. Nadie domina una herramienta nueva en un día. Una migración de una sola vez pide a todos que lo aprendan todo simultáneamente, así que cuando aparece un error no puedes saber de dónde viene: ¿están mal los datos, está mal configurado el sistema o el empleado simplemente aún no ha entendido la pantalla?

Tercero, no te deja camino de vuelta. Si aparece un fallo de fondo a los dos días, tus únicas opciones son seguir adelante o revertirlo todo, y ambas son caras. Una migración por fases siempre mantiene parte del negocio sobre terreno estable. Este es uno de los patrones que se repiten en los proyectos de sistemas que se estancan: la culpa rara vez es de la herramienta y suele ser del intento de cambiarlo todo el mismo día.

Maestros antes que transaccionales: la regla sobre la que descansa toda la secuencia

Tus datos son de dos tipos. Datos maestros: clientes, proveedores, artículos o servicios, empleados, el plan de cuentas. Y datos transaccionales: facturas, pedidos, órdenes de compra, movimientos de inventario, recibos.

La diferencia entre ellos no es de importancia sino de dirección. Los datos transaccionales siempre apuntan a los datos maestros: cada factura apunta a un cliente y a unos artículos, cada orden de compra apunta a un proveedor. Lo contrario nunca ocurre. Así que la secuencia la dicta la dependencia, no la preferencia: migra primero los maestros, porque los transaccionales no pueden asentarse sobre algo que no existe.

Invierte el orden y obtendrás el fallo clásico: importas tres mil facturas, el sistema crea automáticamente un cliente nuevo por cada nombre escrito en ellas y terminas con una lista de clientes que contiene la misma empresa tres veces con tres grafías distintas. Habrás reproducido, dentro del sistema, exactamente el desorden que la tercera parte dedicó a limpiar, solo que ahora corregirlo es más difícil.

En la práctica, el orden es este:

  • Primero: las entidades principales. Clientes, proveedores, artículos y servicios. Listas cortas, que se migran una vez y se revisan a ojo. Es la capa sobre la que se apoya todo lo demás.
  • Segundo: los saldos iniciales. Lo que cada cliente te debe y lo que tú debes a cada proveedor, las cantidades de inventario en el momento de partida, los saldos de las cuentas. Esto no es histórico; es el punto cero desde el que arranca el sistema. Elige una fecha concreta para ello y mantenla.
  • Tercero: solo las transacciones abiertas. Lo que está vivo ahora mismo: pedidos aún no entregados, facturas aún no cobradas, órdenes de compra aún no recibidas. Es lo que el equipo toca a diario, y es mucho más pequeño de lo que imaginas.
  • Al final, y quizá nunca: el archivo histórico. Facturas cerradas de años anteriores.

El archivo histórico: la pregunta que te ahorra semanas

Lo que más tiempo y dinero consume en una migración es la insistencia en llevar todo el histórico de la empresa al nuevo sistema. La pregunta que debe preceder a esa decisión: ¿qué vas a hacer realmente con ese histórico?

Si la respuesta es «lo necesitamos para consultas o para una revisión legal», el archivo ya cumple esa función tal como está: conservado en su formato original, en un lugar conocido y donde se puede buscar. Tu obligación legal es conservar las facturas y los registros y poder presentarlos cuando se soliciten, según establece la Autoridad de Zakat, Impuestos y Aduanas (ZATCA), no que todos ellos vivan precisamente dentro del nuevo sistema.

Si la respuesta es «queremos informes que comparen este año con los anteriores», entonces necesitas parte del histórico, no todo, y normalmente a un nivel resumido en lugar de cada línea de factura. La diferencia entre esas dos migraciones es grande tanto en esfuerzo como en coste.

La regla práctica: migra el histórico sobre el que vayas a basar una decisión y conserva el resto como archivo. No conviertas la migración del archivo en condición previa para arrancar: se puede hacer más tarde sin presión, mientras que la puesta en marcha no puede aplazarse indefinidamente.

Operación en paralelo: necesaria, y peligrosa si se deja abierta

La operación en paralelo consiste en registrar las transacciones en el nuevo sistema y en el archivo antiguo al mismo tiempo durante un periodo definido. Tiene un propósito concreto: confirmar que el sistema produce los mismos resultados que ya conoces. Comparas el total de ventas de la semana, los saldos de los clientes, la cantidad de uno o dos artículos. Si las cifras coinciden, el sistema se comporta bien; si divergen, lo sabes antes de que alguien tome una decisión basada en una cifra errónea.

Pero la operación en paralelo tiene un coste real: tu equipo trabaja dos veces. Ese coste es aceptable durante dos semanas y destructivo durante tres meses. El peligro no es solo el esfuerzo. Al cabo de un tiempo, la doble captura empieza a fallar —alguien registra en un sitio y aplaza el otro—, de modo que las dos copias se separan y el ejercicio pierde todo su sentido, porque ya no sabes cuál es la correcta.

Por eso la única regla que importa aquí es: operación en paralelo con una fecha de fin comunicada a todos desde el primer día. Escribe la fecha, díselo al equipo y prolóngala solo mediante una decisión explícita con un motivo por escrito, nunca por inercia. Un periodo abierto no es prudencia; es una decisión aplazada, y es la forma más común de que un sistema nuevo se quede a medio usar durante un año entero. Esto forma parte del trabajo de gestión del cambio que tratamos a fondo en nuestra guía para implantar un sistema por fases.

La visión de Origami

Cuando construimos un sistema a medida para una empresa que funciona con hojas de cálculo, tratamos el plan de migración como parte del diseño, no como un paso de ejecución al final del proyecto. La razón es que el orden de migración obliga a tomar decisiones sobre la estructura del propio sistema: qué entidades deben sostenerse por sí solas, qué campos deben tolerar estar incompletos temporalmente y dónde necesitamos importaciones repetibles que no dupliquen registros.

También fijamos con el cliente, antes de empezar, la fecha en que se cierra el archivo antiguo, porque esa fecha es lo que convierte el proyecto de un experimento en paralelo en una transición real. Es el mismo enfoque que aplicamos en las hojas de ruta de digitalización por fases, y se extiende a nuestros servicios: cada fase entrega algo que funciona, no la promesa de que todo funcionará al final.

La señal que te dice que la migración ha salido bien

No sabrás si la transición funcionó por un informe de finalización ni por un porcentaje de migración. Lo sabrás por un comportamiento que nadie pidió: un empleado deja de abrir el archivo antiguo sin que se lo digan. Cuando el sistema se convierte en lo primero que abren por la mañana porque es el camino más rápido hacia lo que necesitan, la migración ha ocurrido de verdad. Cuando siguen abriendo el archivo cada mañana a pesar de que todo se ha migrado, la migración aún no ha ocurrido, diga lo que diga la cifra de avance.

Observa esa señal en lugar de las cifras. Y si ves que la gente vuelve al archivo antiguo, el motivo normalmente no es resistencia: es que el sistema no les da algo que necesitan, o se lo da despacio, o con más pasos. Es una causa que se puede corregir, pero solo si la ves pronto y preguntas por ella.

En las próximas partes

Los datos se han migrado en el orden correcto, y aparece una pregunta que no existía en el mundo de los archivos: quien abre un archivo ve todo lo que contiene, mientras que un sistema decide quién ve qué. La siguiente parte trata de los permisos: nóminas, márgenes y datos de clientes, y quién puede ver cada cosa. Después pasaremos a los informes que solías preparar a mano cada mes, y cerraremos la serie con los primeros treinta días después de la migración.

Fuentes