Hay un tipo de proyecto que da más miedo que cualquier otro: reemplazar el sistema con el que la empresa opera todos los días. No es empezar de cero sobre un terreno vacío, es cambiarle el motor a un auto en movimiento.
Es también uno de los proyectos donde más plata se pierde cuando se encara mal.
Primero: viejo no es sinónimo de malo
Antes de planear una migración, chequeá si hace falta. Un sistema con diez años que funciona, es estable y se puede seguir evolucionando no es un problema. Reemplazarlo por gusto de modernidad es una de las formas más caras de no ganar nada.
Un sistema legacy es un problema cuando se cumple alguna de estas:
- Cada cambio cuesta desproporcionado. Modificar algo simple lleva semanas y nadie puede explicar bien por qué.
- Nadie se anima a tocarlo. Funciona, pero se toca lo mínimo por miedo a romper algo.
- La tecnología ya no recibe parches de seguridad. Esto sí es urgente, sobre todo si maneja datos de clientes.
- No se puede integrar con nada. No tiene API y cualquier conexión con otro sistema hay que hacerla a mano.
- Depende de una sola persona. Si esa persona se va, la empresa queda expuesta.
- La infraestructura es imposible de sostener. Un servidor físico bajo un escritorio, sin backups que alguien haya probado restaurar.
Si no marcaste ninguna, no lo toques.
Empezá por saber qué tenés
En la mayoría de estos casos no hay documentación y el autor original no está. Nadie en la empresa puede explicar en detalle qué hace el sistema.
No se puede planificar una migración sobre eso. El primer paso es una auditoría que reconstruya el mapa: qué módulos existen, qué hace cada uno, qué datos maneja, de qué depende, dónde están los riesgos de seguridad y qué tan grave es la deuda técnica.
Desde USD 1.500 y unas semanas de trabajo. Parece un gasto previo evitable y es exactamente lo contrario: sin ese mapa, cualquier presupuesto de migración es un número inventado, y vas a terminar pagando la diferencia.
Las tres estrategias
Reescritura total ("big bang")
Se construye el sistema nuevo completo en paralelo y un día se cambia.
Cuándo tiene sentido: sistemas chicos, o cuando el viejo está tan roto que no vale la pena entenderlo.
El riesgo: es la estrategia que más proyectos hunde. Mientras dura —y siempre dura más de lo previsto— la empresa opera con un sistema que ya nadie mantiene, porque todo el esfuerzo está en el nuevo. Si la reescritura se atrasa, y se atrasa, quedás con dos problemas.
Migración por módulos ("estrangulamiento")
Se reemplaza de a una parte por vez. El sistema nuevo y el viejo conviven, con los datos sincronizados, y el viejo se va quedando sin funciones hasta que se apaga.
Cuándo tiene sentido: en la mayoría de los casos. Es más lento en el papel y bastante más seguro.
La ventaja real: cada módulo migrado ya está dando valor mientras el resto sigue en curso. Si el proyecto se frena por presupuesto o por lo que sea, lo hecho quedó funcionando.
El costo: durante la transición hay que mantener los dos sistemas hablando entre sí, y eso es trabajo que no se ve pero se paga.
Envolver y extender
No se toca el sistema viejo. Se le construye una API por encima y las funciones nuevas se hacen afuera, contra esa API.
Cuándo tiene sentido: cuando el núcleo funciona bien pero está aislado, y lo que necesitás es integrarlo o ponerle una interfaz moderna.
La ventaja: es la opción más barata y rápida, y a veces resuelve el problema entero sin migrar nada.
Vale la pena evaluarla en serio antes de decidir una migración: en más casos de los que uno esperaría, lo que molesta no es el sistema sino que esté encerrado.
Cómo se hace sin frenar la operación
Una parte por vez. Elegí el módulo con más dolor y menos dependencias. Reemplazalo, ponelo en producción, estabilizalo. Recién entonces el siguiente.
Sincronización durante la transición. Mientras conviven, los datos tienen que estar consistentes en los dos. Es la parte técnicamente más delicada y hay que cotizarla.
Operación en paralelo antes de cada corte. Igual que en cualquier migración: durante unas semanas se usan los dos y se comparan los resultados. Se apaga lo viejo cuando los números coinciden, no cuando el calendario lo dice.
Un plan de vuelta atrás en cada fase. Si algo sale mal, tiene que haber una forma definida de volver al estado anterior. Si no la hay, no estás listo para cortar.
Los datos son la mitad del proyecto
En sistemas viejos, los datos acumulan décadas de decisiones raras: campos que se usaron para dos cosas distintas según la época, códigos que significan algo distinto antes y después de cierto año, registros migrados de un sistema anterior que ya venían mal.
Nada de eso está documentado y sólo se descubre mirando.
Presupuestá la limpieza y la validación como una tarea propia. Y pedí que alguien mire una muestra real de los datos antes de cerrar el precio de la migración: es la media hora que más plata ahorra en todo el proyecto.
Lo que hay que negociar de entrada
Si el sistema viejo lo hizo otro proveedor y la relación no es ideal, resolvé esto antes de arrancar:
- Acceso al código fuente y al repositorio con historial.
- Accesos de administrador a servidores, base de datos y servicios.
- Un export completo de los datos, en un formato que se pueda leer.
- Documentación, si existe.
Conseguí todo eso antes de anunciar que vas a migrar. Después de anunciarlo, la colaboración suele volverse más lenta.
Cuánto cuesta
No hay un número único, pero sí un orden:
| Etapa | Desde |
|---|---|
| Auditoría del sistema actual | USD 1.500 |
| Envolver con API y extender | USD 2.000 |
| Migración de un módulo | USD 4.000 |
| Sistema de gestión completo nuevo | USD 15.000 |
La auditoría es lo que convierte el resto en números confiables. Sin ella vas a recibir rangos enormes, y con razón: nadie puede cotizar lo que no puede ver.
Una nota sobre el equipo
Hay una dimensión que se subestima: la gente que trabaja con el sistema viejo lo domina. Sabe sus mañas, sus atajos, cómo esquivar sus defectos. Ese conocimiento tiene años de valor.
Si los tratás como obstáculos, vas a perder información que no está en ningún otro lado y vas a ganarte una resistencia que después no se revierte. Si los involucrás desde el relevamiento, te van a contar exactamente qué tiene que hacer el sistema nuevo, incluidas las cincuenta excepciones que ningún documento registra.
Si tenés un sistema que ya te está frenando y no sabés si conviene migrarlo, envolverlo o dejarlo tranquilo, esa es exactamente la pregunta que responde una auditoría técnica. Contanos qué tenés y lo miramos.
Preguntas frecuentes
¿Conviene reescribir un sistema viejo desde cero?+
Casi nunca de una sola vez. Una reescritura total tarda más de lo previsto y, mientras dura, la empresa opera con un sistema que ya nadie mantiene. Lo que suele funcionar es migrar por partes: se saca un módulo, se reemplaza, se pone en producción, y se sigue con el siguiente.
¿Y si el sistema no tiene documentación y su autor ya no está?+
Es el caso más común. Se empieza con una auditoría que reconstruya qué hace el sistema, cómo está armado y dónde están los riesgos. Desde USD 1.500. Sin ese mapa, cualquier presupuesto de migración es adivinanza.
¿Cómo migro sin parar la operación?+
Reemplazando de a un módulo por vez y manteniendo los dos sistemas conviviendo durante la transición, con los datos sincronizados. Se apaga la parte vieja recién cuando la nueva demostró que produce los mismos resultados.
¿Cómo sé si mi sistema es realmente un problema o simplemente es viejo?+
Viejo no es malo. Es un problema cuando cada cambio cuesta desproporcionadamente caro, cuando nadie se anima a tocarlo, cuando corre sobre tecnología sin soporte de seguridad, o cuando no podés integrarlo con nada. Si funciona, es estable y podés evolucionarlo, no lo toques.
¿Querés que esto funcione en tu empresa?
En Deepyze convertimos procesos manuales en sistemas que trabajan solos: automatización con IA, apps web y móviles, y software a medida. Contanos tu caso y en 24 hs tenés una propuesta concreta.
Sin compromiso · Respuesta en 24 hs · Equipo en tu mismo huso horario