Cómo migrar un sistema viejo sin frenar la operación (ni perder 15 años de datos)

Respuesta corta. Un sistema viejo se migra sin frenar la operación en cinco fases: relevar qué hace realmente el sistema, hacer convivir el nuevo con el viejo, migrar los datos con validación, cortar módulo por módulo y recién entonces apagar el viejo. Así, en cada paso hay a dónde volver. El reemplazo de golpe —apagar el viejo un viernes y prender el nuevo el lunes— es el enfoque que más fracasa, porque concentra todo el riesgo en un solo instante.

El sistema anda. Factura todos los días. Y nadie en la empresa lo entiende del todo, porque el que lo hizo hace quince años no está más y se llevó en la cabeza la mitad de cómo funciona. Cada vez que hay que cambiar algo, se cruza los dedos.

Ese es el escenario real de miles de PyMEs argentinas, y por eso migrar un sistema viejo a la nube da tanto vértigo. A esta altura todavía no es un problema técnico: es un problema de riesgo. El sistema no se rompió, pero cada día que pasa dependés más de algo que menos gente entiende y que nadie puede garantizar. La pregunta no es “¿anda?”, sino “¿qué hago el día que deje de andar?”.

¿Cuándo hay que migrar un sistema viejo?

Conviene empezar a planificar la migración de un sistema viejo cuando aparece cualquiera de tres señales: que no corra en las versiones nuevas de Windows, que ya nadie lo pueda mantener, o que no se conecte con nada. Un sistema viejo puede aguantar mucho, pero esas tres avisan que el margen se está por terminar.

No corre en Windows nuevo

Cada vez que actualizás una máquina rezás para que el sistema siga abriendo. Tenés una computadora “vieja” que no tocás por las dudas, porque es la única donde todo funciona. Ese equipo es una bomba de tiempo: el día que muera, muere la operación con él, y no hay repuesto.

Nadie le puede tocar nada

No hay quien lo mantenga. Los ajustes que antes eran de un día ahora no los hace nadie, o cuestan una fortuna porque quedan tres personas en el país que entienden esa tecnología. Si tu sistema está hecho en Access o en Visual Basic, ya lo sabés: encontrar quién lo mantenga dejó de ser algo que puedas encargar en la esquina. Estás preso de tu propio sistema.

No se conecta con nada

Todo lo nuevo —facturación electrónica, cobros online, tu tienda— vive afuera, y los datos viajan a mano de un lado al otro. El sistema se volvió una isla, y la isla te cuesta horas todas las semanas.

La regla es simple: con una sola de estas señales, conviene empezar a planificar. Si te pasan dos de las tres, el problema ya dejó de ser tecnológico y es operativo. Ahí no es cuestión de “en algún momento”, es cuestión de “antes de que te agarre desprevenido”.

¿Por qué fracasa migrar un sistema de golpe?

Migrar un sistema de golpe —apagar el viejo un viernes y prender el nuevo el lunes— fracasa porque concentra todo el riesgo en un solo instante: si algo falla, no hay a dónde volver. La tentación de hacerlo de un saque suena limpia, y en la práctica es la forma más rápida de vivir una pesadilla.

El problema es simple: si algo falla el lunes —y siempre falla algo—, no tenés a dónde volver. La operación queda parada, con el equipo mirándote a vos, mientras alguien corre a entender por qué el sistema nuevo no hace lo que hacía el viejo. La presión hace que se tomen decisiones apuradas, y las decisiones apuradas dejan cicatrices.

Y hay un detalle que agrava todo: el sistema viejo casi nunca está tan documentado como uno cree. Tiene comportamientos que solo aparecen en casos puntuales —el cliente que se factura distinto, el descuento que se calcula de una forma rara, el reporte que alguien ajustó a mano hace años—. En un cambio de golpe, esos casos raros aparecen todos juntos el mismo día, siempre en el peor momento. Por eso el “big bang” no falla por falta de esfuerzo: falla porque concentra todo el riesgo en un solo instante.

¿Cuáles son las fases de una migración por etapas?

Una migración por fases tiene cinco etapas: relevar qué hace realmente el sistema, hacer convivir el nuevo con el viejo, migrar los datos con validación, cortar módulo por módulo y recién entonces apagar el viejo. La idea de fondo es que el traspaso sea gradual y reversible: en cada momento tenés una red debajo.

Relevar qué hace realmente el sistema

No lo que dice el manual —si es que existe— sino lo que hace de verdad, incluyendo esos atajos y excepciones que solo conoce la persona que lo usa hace años. Esta etapa es la que más se saltea y la que más caro se paga.

Convivencia de los dos sistemas

El nuevo empieza a funcionar en paralelo, sin apagar el viejo. Podés comparar que hagan lo mismo antes de confiar en el nuevo para algo crítico.

Migración de datos con validación

Se traen los datos históricos y —esto es clave— se verifica que llegaron completos y correctos. No se asume: se prueba.

Corte por módulo

Se pasa una parte a la vez: primero, por ejemplo, la facturación; cuando esa anda sólida, el stock; después el resto. Si algo se complica, el problema queda acotado a un módulo, no a toda la empresa.

Apagado del viejo

Recién cuando todo lo que hacía el sistema anterior ya funciona mejor en el nuevo, se apaga el viejo. Sin apuro y sin drama.

Fase	Qué se entrega
Relevamiento	Mapa real de lo que el sistema hace hoy, casos raros incluidos
Convivencia	El sistema nuevo andando en paralelo, sin riesgo para la operación
Migración de datos	Datos históricos cargados y validados contra el original
Corte por módulo	Cada área pasada y estable, una por una
Apagado	El sistema viejo dado de baja, con todo funcionando en el nuevo

Así se encara una migración de sistemas en serio: la operación no siente el golpe porque, en cada paso, hay a dónde volver.

¿Cómo se verifica que los datos migraron bien?

Que los datos migraron bien se verifica con tres chequeos que el cliente puede hacer por su cuenta: conteos, totales y muestreo. Perder quince o veinte años de información es el temor número uno, y tiene todo el sentido; la buena noticia es que la migración de datos es de las cosas más controlables del proceso, porque se puede auditar con números.

¿Cómo verificás que los datos migraron bien? Con tres chequeos que podés hacer vos mismo, sin depender de la palabra de nadie:

• Conteos. Si en el sistema viejo había 12.400 clientes, en el nuevo tiene que haber 12.400. Ni uno más ni uno menos.
• Totales. Que el total facturado del año pasado dé exactamente igual en los dos sistemas. Si coincide al peso, los datos viajaron bien.
• Muestreo. Agarrás diez registros al azar y los comparás campo por campo contra el original.

Si esos tres dan, la migración está sana. Lo importante es esto: no tenés que creer, podés auditar. Un buen proceso de migración se deja controlar por el cliente, no te pide fe.

¿Conviene copiar el sistema viejo tal como está?

No conviene copiar el sistema viejo tal como está: migrar es la única oportunidad barata de sacarse de encima los parches acumulados durante años. Es la parte que casi nadie te cuenta, y la que separa una buena migración de un simple “lo mismo pero en la web”.

Migrar no es fotocopiar. Si te limitás a copiar el sistema viejo con colores nuevos, te llevás también todos los parches que se fueron acumulando con los años: ese campo que se usa para algo que no era, el proceso que se hace en tres pasos porque el sistema nunca dejó hacerlo en uno, el Excel paralelo que tapa un agujero que el sistema nunca cubrió.

La migración es la única oportunidad barata de sacarte esas cosas de encima. En el relevamiento aparece, con nombre y apellido, todo lo que hoy se hace “así porque siempre se hizo así”. No hace falta arreglar todo de una, pero sí decidir qué vale la pena mejorar de paso. Muchas de esas tareas manuales que el sistema viejo nunca resolvió se terminan de raíz con integraciones que conectan lo que antes vivía suelto. Y si aprovechás para repensar los procesos que estaban torcidos, lo que termina saliendo no es una copia más moderna: es un software a medida que te queda mejor que el original.

Esa es la diferencia entre migrar por miedo —”que no se caiga”— y migrar con cabeza —”ya que lo tocamos, dejémoslo mejor”—. La primera te saca del peligro. La segunda, además, te deja un sistema del que no te vas a querer ir dentro de quince años. Para una PyME, donde cada hora del equipo cuenta, esa diferencia se paga sola.

Migrar con cabeza, no por miedo

Migrar un sistema viejo no es saltar al vacío. Hecho por fases, con los datos validados y con los dos sistemas conviviendo, el riesgo se vuelve manejable y la operación no se entera del cambio hasta que ya está hecho. El miedo es entendible; lo que no conviene es dejar que ese miedo te ate a un sistema que un día, sin avisar, deja de arrancar.

¿Tenés un sistema que nadie se anima a tocar? Contanos qué hace y te decimos por dónde se empieza.