Para modernizar un sistema heredado sin detener la operación, no se apaga el sistema viejo para encender uno nuevo. Se reemplaza por partes: cada módulo nuevo convive con el anterior, los datos se migran por etapas y ambos sistemas corren en paralelo hasta comprobar que el nuevo da los mismos resultados. El negocio sigue facturando todo el tiempo y el riesgo se reparte en pasos pequeños.
Cuándo un sistema heredado ya te está frenando
Un sistema heredado no es necesariamente malo por ser antiguo. Muchos llevan años sosteniendo la operación. El problema aparece cuando empieza a costar más de lo que aporta. Algunas señales:
- Solo una persona sabe cómo funciona, y cada vacación suya es un riesgo.
- Cada cambio pequeño tarda semanas y rompe algo en otro lado.
- No se puede conectar con una app, una tienda en línea, un banco o el ERP sin trucos frágiles.
- Corre en un servidor físico o en software que ya no recibe actualizaciones de seguridad.
- El equipo vive en hojas de cálculo paralelas porque el sistema no da los datos que necesita.
Si te reconoces en dos o más, vale la pena planear la modernización antes de que una falla la decida por ti.
Por qué no conviene reescribir todo de una vez
La tentación es congelar el sistema viejo, construir uno nuevo durante un año y cambiar todo un lunes. En la práctica ese plan falla con frecuencia. El negocio no se detiene durante ese año y el sistema viejo sigue recibiendo cambios. Las reglas escondidas en el código antiguo aparecen recién el día del cambio. Y si algo sale mal, no hay forma fácil de volver atrás.
El reemplazo por partes: estrangular el sistema viejo
El patrón que usamos se conoce como «strangler fig» o estrangulamiento: el sistema nuevo crece alrededor del viejo y le va quitando funciones una por una, hasta que el antiguo ya no hace nada y se apaga.
- Se pone una fachada delante del sistema viejo: una capa de APIs por la que pasan todas las peticiones. Al inicio solo reenvía todo al sistema antiguo.
- Se elige el primer módulo a reemplazar. Conviene uno de valor visible y riesgo acotado, como consulta de pedidos o el catálogo, y no el corazón contable.
- Se construye el módulo nuevo y la fachada empieza a enviarle esas peticiones. El resto sigue yendo al sistema viejo.
- Se repite módulo por módulo, cada uno con su propia validación.
- Se apaga el sistema viejo cuando ya no recibe tráfico, después de archivar sus datos.
Piensa en una distribuidora en Guayaquil con un sistema de escritorio de hace quince años. Primero se publica una API sobre su base de datos. Luego se construye un portal web de pedidos para clientes que usa esa API. Después se reemplaza el módulo de inventario. La facturación, lo más delicado, va al final, cuando el equipo ya confía en el sistema nuevo.
Convivencia de sistemas y migración de datos
Durante meses ambos sistemas van a existir a la vez, y eso exige reglas claras. Lo más importante es definir, para cada dato y en cada etapa, cuál sistema es el dueño. Si los dos pueden editar lo mismo sin control, aparece la doble fuente de verdad, un problema que describimos en la guía para integrar tu ERP con tus apps y tu web.
La migración de datos sigue el mismo principio de etapas:
- Perfilado primero: antes de mover nada se revisa la calidad de los datos. Clientes duplicados, códigos inconsistentes y campos vacíos aparecen siempre.
- Limpieza con reglas escritas, acordadas con quienes usan los datos, no decididas solo por el programador.
- Migraciones repetibles: el proceso se ensaya varias veces en un ambiente de pruebas hasta que corre sin intervención.
- Sincronización mientras conviven: los cambios que ocurren en el sistema viejo se replican al nuevo, y viceversa cuando corresponde.
- Conteos y sumas de control: número de clientes, saldos totales, facturas por mes. Si no cuadran en ambos lados, no se avanza.
Pruebas en paralelo: comparar antes de confiar
Antes de que un módulo nuevo tome el control, se ejecuta en paralelo con el viejo sobre las mismas operaciones reales y se comparan los resultados. Si el sistema antiguo calcula un descuento o una comisión de una forma que nadie documentó, la diferencia aparece aquí, y no en la queja de un cliente. Solo cuando las diferencias se explican y se corrigen, el módulo nuevo pasa a mandar. Y siempre con un plan para volver atrás en minutos si algo falla.
Cuánto cuesta modernizar un sistema heredado
Depende del tamaño del sistema, de cuántos módulos se reemplazan y de la calidad de los datos. Como referencia, un desarrollo a medida de este tipo suele cotizarse en el mercado en torno a USD 60.000. En FoodTook Labs, proyectos comparables quedan alrededor de USD 20.000.
La diferencia tiene explicación. Somos un equipo que ya construyó y opera su propia plataforma en producción, con app de cliente, app de repartidor, panel de comercios y backoffice. Reutilizamos componentes probados en lugar de reinventarlos. Y trabajamos en ciclos cortos con demos semanales, lo que evita meses de retrabajo. El precio final depende del alcance: el discovery gratis te da el rango antes de decidir.
Como el reemplazo es por fases, la inversión también se reparte por etapas, y cada una entrega algo que ya funciona. Además, facilitamos el acople financiero para las empresas que desean modernizarse. Si estás evaluando proveedores, te puede servir cómo elegir empresa de desarrollo de software en Guayaquil.
Qué ganas al terminar
Un sistema moderno no vale por ser nuevo. Vale porque se puede conectar con tus canales, tu banco y tu facturación; porque tus datos fluyen en tiempo real hacia dashboards que ayudan a decidir; porque recibe actualizaciones de seguridad; y porque cualquier desarrollador competente puede entenderlo y mejorarlo. Es la base para que la empresa tome decisiones informadas y crezca sin depender de una sola persona.