Cómo modernizar un sistema legado sin detener tu operación

Modernizar un sistema legado sin detener tu operación consiste en reemplazarlo por partes, no de golpe: primero se diagnostica qué hace realmente el sistema, después se elige una estrategia por módulo (mover, adaptar, refactorizar o reescribir) y al final se migra la información con ensayos, operación en paralelo y un corte planeado con plan de regreso. Bien hecho, tu equipo sigue facturando, vendiendo y surtiendo mientras el sistema nuevo toma el control poco a poco.

El error más caro que vemos en empresas mexicanas no es tener un sistema viejo. Es intentar cambiarlo en un solo fin de semana, sin saber bien qué reglas de negocio vivían escondidas en el código.

¿Qué es un sistema legado?

Un sistema legado es software que todavía sostiene procesos críticos del negocio, pero que ya no se puede mantener, ampliar o integrar con un costo y un riesgo razonables. La antigüedad no lo define; lo define la fragilidad. Un sistema de 2012 en Laravel bien mantenido no es legado. Un sistema de 2019 hecho en macros de Excel que solo entiende una persona, sí lo es.

En la práctica, en México seguimos encontrando estos escenarios:

• Visual Basic 6, FoxPro o Delphi con base de datos local, instalados en cada computadora o compartidos en red.
• Microsoft Access que empezó como control interno y terminó siendo el sistema de inventarios de toda la empresa.
• PHP 5 o versiones antiguas de frameworks sin parches de seguridad, a veces con contraseñas en texto plano.
• Servidores físicos en un cuarto de la oficina, sin respaldos probados, con un sistema operativo fuera de soporte.
• Libros de Excel con macros que hacen cálculos de comisiones, costeo o nómina y que nadie se atreve a tocar.

Señales de que tu sistema ya necesita modernizarse

No todas las señales son técnicas. Muchas aparecen primero en la operación:

1. Dependes de una sola persona. Si el programador original se va o se enferma, nadie puede corregir un error.
2. Cada cambio pequeño tarda semanas y suele romper otra cosa.
3. No se integra con nada. No puedes conectarlo a tu tienda en línea, a tu CRM ni a un PAC para timbrar CFDI 4.0, así que alguien recaptura datos todos los días.
4. Solo funciona en la oficina. Para consultar algo desde fuera hay que conectarse por escritorio remoto a una máquina específica.
5. No hay respaldos confiables o nunca se ha probado restaurarlos.
6. El proveedor del lenguaje o del sistema operativo ya no da soporte, y cada actualización de Windows es una apuesta.
7. Los reportes se arman a mano exportando a Excel porque la base de datos no permite consultas decentes.

Si te identificas con tres o más, ya no es una mejora deseable: es un riesgo operativo.

¿Qué estrategias existen para modernizar un sistema legado?

Hay cinco estrategias principales. No compiten entre sí; en un mismo proyecto normalmente se combinan según el módulo.

Rehost (mover tal cual)

Llevas el sistema y su base de datos a un servidor en la nube sin cambiar el código. Ganas respaldos, disponibilidad y acceso remoto, pero el software sigue siendo el mismo. Es útil como primer paso para quitarte el riesgo del servidor físico mientras planeas lo demás.

Replatform (adaptar la plataforma)

Haces cambios mínimos para aprovechar una mejor plataforma: por ejemplo, mover la base de datos de Access a SQL Server o PostgreSQL administrado, empaquetar la aplicación en contenedores Docker o actualizar de PHP 5 a PHP 8 con los ajustes indispensables. El negocio no nota cambios en las pantallas, pero el sistema se vuelve más estable y seguro.

Refactor (reestructurar el código)

Mejoras la estructura interna sin cambiar lo que hace el sistema: separas la lógica de negocio de la interfaz, agregas pruebas automatizadas, expones una API. Solo es viable si el lenguaje actual tiene futuro y el código es rescatable.

Rewrite (reescribir)

Construyes un sistema nuevo con tecnología actual. Es la opción con más beneficio a largo plazo y también la de mayor riesgo si se intenta en un solo bloque, porque el sistema viejo contiene años de reglas que nadie documentó.

Strangler fig (sustitución gradual)

El nombre viene de una higuera que crece alrededor de un árbol hasta reemplazarlo. El patrón strangler fig consiste en construir el sistema nuevo módulo por módulo alrededor del legado, con una capa intermedia que decide qué sistema atiende cada función. Primero migras, por ejemplo, el catálogo de clientes; luego cotizaciones; después facturación. Cada módulo se libera cuando ya está probado en operación real, y el legado se apaga cuando ya no le queda nada que hacer.

Para la mayoría de los sistemas administrativos medianos, es la estrategia que recomendamos.

Comparativa de estrategias de modernización

Estrategia	Qué cambia	Riesgo operativo	Tiempo típico	Cuándo conviene
Rehost	Solo la infraestructura	Bajo	Semanas	Servidor físico en riesgo; necesitas respaldo y acceso remoto ya
Replatform	Base de datos, versión o contenedores	Bajo a medio	Semanas a pocos meses	El código sirve, pero la plataforma está fuera de soporte
Refactor	Estructura interna del código	Medio	Meses, de forma continua	El lenguaje sigue vigente y el código es rescatable
Rewrite total	Todo el sistema de una vez	Alto	Varios meses a más de un año	Sistemas pequeños o con reglas muy bien documentadas
Strangler fig	Todo, pero por módulos	Bajo a medio	Varios meses, con entregas frecuentes	Sistemas críticos que no pueden detenerse

Los tiempos son orientativos y dependen del tamaño del sistema, la calidad de la información y la disponibilidad de tu equipo para validar.

El diagnóstico: el paso que nadie quiere pagar y todos necesitan

Antes de elegir estrategia hay que entender qué hace realmente el sistema. Un diagnóstico serio incluye:

• Inventario funcional: pantallas, reportes, procesos automáticos y quién usa cada cosa. Es común descubrir que un tercio de las funciones ya nadie las usa.
• Reglas de negocio ocultas: cálculos de precios, descuentos por volumen, redondeos fiscales, validaciones. Se extraen leyendo el código y entrevistando a los usuarios clave.
• Modelo de datos: tablas, relaciones, campos reutilizados para otra cosa, catálogos duplicados, datos huérfanos.
• Integraciones existentes: archivos que se exportan a contabilidad, conexiones con el banco, carpetas compartidas que otro sistema lee.
• Riesgos inmediatos: respaldos, seguridad, licencias, dependencia de personas.

El entregable es un mapa de módulos con la estrategia, el orden y el riesgo de cada uno. Ese mapa es lo que permite cotizar con fundamento; si quieres entender qué mueve el precio, lo explicamos en cuánto cuesta un software a la medida.

¿Cómo se migran los datos sin perder información?

La migración de datos es donde fallan más proyectos, y casi nunca por la tecnología. Fallan por datos sucios: clientes duplicados con distinto RFC, productos con la misma clave, fechas capturadas como texto, saldos que no cuadran desde hace años.

Un proceso de migración confiable sigue estos pasos:

1. Extracción desde la base original (archivos DBF, MDB, SQL Server antiguo, hojas de Excel) hacia un área intermedia.
2. Limpieza y normalización: se unifican catálogos, se validan RFC y códigos postales contra los formatos que exige CFDI 4.0, se separan campos mal usados.
3. Transformación al modelo de datos nuevo, con scripts versionados en un repositorio, no con copiar y pegar.
4. Carga en la base de datos destino.
5. Conciliación: se comparan conteos de registros, sumas de saldos, existencias por almacén y totales por periodo entre el sistema viejo y el nuevo.

Estos scripts se ejecutan varias veces antes del corte real: una en el primer ensayo, otra con datos más recientes y una más justo antes de salir. Cada ensayo descubre algo. Es preferible que lo descubra el equipo técnico un martes por la tarde y no tu área de cobranza el lunes del arranque.

Una decisión que conviene tomar temprano: cuánta historia migrar. A veces lo sensato es migrar catálogos, saldos abiertos y los últimos dos o tres ejercicios, y dejar el histórico completo en una base de solo consulta.

Operación en paralelo: la red de seguridad

La operación en paralelo es un periodo, normalmente de una a cuatro semanas, en el que el sistema nuevo procesa la misma información que el legado y se comparan resultados. No significa que tu equipo capture todo dos veces; según el caso, se puede:

• Replicar automáticamente las transacciones del legado hacia el sistema nuevo.
• Capturar en el nuevo y comparar reportes clave contra el viejo al cierre de cada día.
• Liberar el módulo nuevo solo para una sucursal o un grupo de usuarios piloto.

El objetivo es encontrar diferencias en cálculos, permisos y reportes antes de que el sistema viejo deje de existir.

El corte: cómo se hace un cutover sin sustos

El corte o cutover es el momento en que el sistema nuevo se vuelve el oficial. Un buen corte se parece más a un procedimiento quirúrgico que a un lanzamiento:

• Ventana definida en un horario de baja operación, acordada con las áreas.
• Checklist escrito con responsables y tiempos: congelar el legado, última extracción, carga, conciliación, pruebas de humo, apertura a usuarios.
• Criterios de éxito claros: si los saldos de clientes no cuadran al centavo, no se abre.
• Plan de regreso probado: cómo volver al sistema anterior y qué hacer con lo capturado en el nuevo si hay que revertir.
• Soporte reforzado los primeros días, con alguien del equipo técnico disponible para resolver dudas en sitio o por videollamada.

Con el enfoque strangler fig, en lugar de un corte grande hay varios cortes pequeños, uno por módulo. Cada uno es menos riesgoso y el equipo gana confianza en cada paso.

Riesgos más comunes y cómo controlarlos

Riesgo	Qué lo provoca	Cómo se mitiga
Reglas de negocio olvidadas	Lógica escondida en el código viejo	Diagnóstico con lectura de código y pruebas con casos reales
Datos inconsistentes	Años de captura sin validaciones	Limpieza previa y conciliación automática
Resistencia del equipo	Cambio de pantallas y hábitos	Usuarios clave en las validaciones y capacitación por rol
Alcance que crece sin control	“Ya que estamos, agreguemos…”	Primero paridad funcional, mejoras en una fase posterior
Caída en el arranque	Corte sin ensayo ni plan de regreso	Ensayos de corte y operación en paralelo
Dependencia de un nuevo proveedor	Código y accesos que no son tuyos	Repositorio, documentación e infraestructura a nombre de tu empresa

Ese último punto importa. Modernizar para quedar otra vez atado a una sola persona o a un proveedor que no te entrega el código es cambiar un problema por otro.

¿Qué tecnología usar para el sistema nuevo?

La respuesta corta: la que tu negocio pueda mantener durante los próximos diez años. Para sistemas administrativos y ERP web solemos trabajar con backends como Laravel, .NET, Node.js o Python, bases de datos PostgreSQL o SQL Server, interfaces en React o Vue y despliegue en AWS, Google Cloud o Azure con contenedores y CI/CD. Si tu equipo ya conoce .NET, por ejemplo, puede tener sentido quedarse en ese ecosistema. Profundizamos en los criterios en cómo elegir el stack tecnológico para tu software.

Dos piezas que casi siempre conviene incluir desde el inicio:

• Una API que exponga la lógica de negocio. Es lo que después te permite conectar tienda, CRM, bancos o el SAT sin volver a reescribir. Lo explicamos en integración de sistemas por API.
• Infraestructura administrada con respaldos automáticos, monitoreo y entornos separados de pruebas y producción. Es lo que ofrecemos en nube e infraestructura.

¿Modernizar o comprar un ERP comercial?

Es una pregunta legítima. Si tus procesos son estándar, un ERP comercial puede ser suficiente, y la modernización se reduce a migrar datos hacia él. Si tu ventaja competitiva está justamente en cómo cotizas, produces o distribuyes, y por eso terminaste construyendo un sistema propio hace años, lo lógico es conservar esa ventaja en un sistema a la medida moderno. Lo comparamos con detalle en ERP a la medida vs. comercial y en cómo centralizar operaciones en un ERP web.

Cómo te ayuda Tecsolt

En Tecsolt desarrollamos software a la medida desde 2017 y hemos trabajado con sistemas heredados en distintas tecnologías, desde bases locales hasta aplicaciones web sin soporte. Empezamos con un diagnóstico del código, los datos y los procesos, y te entregamos un plan por módulos con estrategia, orden y riesgos antes de escribir una línea del sistema nuevo. Migramos con scripts versionados, conciliación y operación en paralelo, y el código, la documentación y los accesos a la infraestructura quedan a nombre de tu empresa. Si quieres revisar tu caso, agenda una reunión o conoce más sobre nuestro servicio de software y ERP a la medida.

Preguntas frecuentes

¿Qué es un sistema legado y cuándo conviene reemplazarlo?

Un sistema legado es software que sigue sosteniendo procesos críticos, pero está construido sobre tecnología sin soporte, depende de una o dos personas o ya no se puede cambiar sin miedo a romperlo. Conviene modernizarlo cuando el costo de mantenerlo, el riesgo de una falla o la imposibilidad de integrarlo con otros sistemas empiezan a frenar al negocio.

¿Se puede migrar un sistema en Visual Basic 6 o Access a web sin perder información?

Sí. La información se extrae, se limpia y se carga en una base de datos moderna como PostgreSQL o SQL Server mediante scripts de migración que se ensayan varias veces antes del corte. Al final se concilian conteos y saldos entre el sistema viejo y el nuevo para comprobar que no se perdió ni se duplicó nada.

¿Cuánto tiempo tarda modernizar un sistema legado?

Depende del tamaño y de la estrategia. Mover un sistema a la nube sin cambiar su código puede tomar semanas, mientras que reescribir un sistema administrativo completo por módulos suele tomar de seis a doce meses o más. El tiempo real se define después de un diagnóstico del código, la base de datos y los procesos.

¿Qué es el patrón strangler fig en modernización de software?

Es una estrategia en la que el sistema nuevo crece alrededor del viejo y lo va sustituyendo módulo por módulo. Una capa intermedia dirige cada función al sistema que ya la resuelve, hasta que el legado deja de recibir tráfico y se puede apagar. Reduce el riesgo porque nunca hay un cambio total en un solo día.

¿Es mejor reescribir el sistema desde cero o modernizarlo por partes?

En la mayoría de los casos es más seguro modernizar por partes, porque cada entrega se valida en operación real y el negocio nunca depende de un solo lanzamiento. Reescribir desde cero solo tiene sentido cuando el sistema es pequeño, sus reglas están bien documentadas o la tecnología actual hace imposible cualquier cambio.

¿Cómo evito que mi operación se detenga durante la migración?

Con operación en paralelo, un plan de corte ensayado y un plan de regreso. Durante unas semanas ambos sistemas procesan la misma información y se comparan resultados; el corte se hace en una ventana de baja actividad y, si algo falla, se puede volver al sistema anterior sin perder datos.

• #sistemas legados
• #modernización de software
• #migración de datos
• #strangler fig
• #migración a la nube