Tu sistema legacy hecho a la medida: cómo modernizarlo sin parar la operación

Si tu empresa tiene un sistema que no aparece en el catálogo de ningún proveedor, esto es para ti. Lo construyó alguien de la casa hace ocho, doce o veinte años, sobre Visual Basic 6, Visual FoxPro, Access o Delphi, y ahí sigue: factura, calcula comisiones, controla el inventario por sucursal. Funciona, y por eso nadie lo toca.

La diferencia con un ERP comercial no es solo la tecnología: es que no hay fabricante. No existe una versión nueva que instalar, ni una mesa de ayuda a la que escalar el problema, ni alguien obligado a corregir un error de cálculo antes del cierre del mes.

Ese hueco se nota en dos momentos: cuando algo se rompe y cuando alguien pide conectar el sistema con algo nuevo. Ahí la conversación deja de ser "lo arreglamos" y se convierte en "¿quién sabe cómo está hecho?". La respuesta suele ser una sola persona.

El riesgo no es el código viejo, es el conocimiento que se va

Un sistema hecho a la medida no deja de operar porque la tecnología esté vieja. Sigue corriendo igual que el primer día. Lo que se agota es lo que nadie escribió: por qué a ciertos clientes se les aplica un descuento distinto, qué hace ese proceso nocturno que mueve saldos, qué tabla no se debe tocar.

A eso se suma que varias de las piezas con las que se construyó ya no reciben soporte del fabricante. El IDE de Visual Basic 6.0 dejó de tener soporte el 8 de abril de 2008, según Microsoft. Visual FoxPro 9.0 llegó al final de su soporte extendido el 14 de enero de 2015, según su ciclo de vida. Y versiones de .NET Framework como la 4.5.2, la 4.6 y la 4.6.1 se retiraron el 26 de abril de 2022, según Microsoft.

Nada de eso apaga el sistema la semana que entra. Lo que cambia es la posición de riesgo: las fallas de seguridad que aparezcan en esas piezas ya no se corrigen, y mantenerlas cuesta más cada año.

Antes de decidir, haz el inventario de lo que nadie documentó

Un inventario útil no es una lista de programas: es una lista de dependencias. Nombra cada sistema, qué hace, quién lo usa y en qué base de datos vive; anota quién lo entiende y qué pasa si esa persona falta dos semanas.

Escribe también qué se detiene si el sistema se cae un día completo: si no se puede facturar, si no se puede surtir, si no se puede pagar la nómina.

Si el sistema corre sobre SQL Server, revisa que alguien pueda leer las tablas: los datos son de la empresa aunque el código no lo sea. Esa base de datos es la materia prima de cualquier modernización, porque sirve para envolver el sistema viejo, migrar por partes o reconstruir reglas que hoy solo viven en la cabeza de alguien.

Tres caminos, y el error de tratarlos como uno solo

Los proyectos de modernización se caen cuando se plantean como una sola decisión. Hay tres caminos.

Envolver. El programa viejo sigue trabajando y encima se pone una capa nueva que lee y escribe en su base de datos, con una interfaz o una API. Es el camino más rápido y el que menos riesgo corre, pero no resuelve el fondo: el programa sigue sin soporte.

Migrar por partes. Se construye el reemplazo módulo por módulo y los dos sistemas conviven mientras el nuevo demuestra que cuadra. Es el camino más común cuando la operación no puede parar, y también el más largo: hay que mantener dos cosas a la vez.

Reescribir todo. Es el más limpio en el papel y el más riesgoso: nadie tiene por escrito el conjunto de reglas que el sistema viejo aplica. El error clásico es replicarlo tal como está, con tecnología nueva: sale un sistema viejo con ropa nueva.

El criterio para elegir no es el presupuesto, es qué parte no puede parar y qué parte ya no se usa. Si un módulo no lo abre nadie desde hace un año, no se migra: se retira.

Cinco decisiones que puedes tomar esta semana

1. Arma la lista: cada sistema, quién lo usa, en qué servidor corre, qué base de datos tiene detrás y quién lo entiende.
2. Haz un respaldo completo de la base de datos y guárdalo fuera del servidor donde vive el sistema.
3. Escribe una hoja de una página con lo que se detiene si el sistema se cae dos días; ordénala por lo que más te cuesta.
4. Siéntate con quien lo mantiene y anota los pasos manuales que rodean al sistema: el Excel que se arma antes de cerrar, el reporte que se copia a mano.
5. Elige un módulo para empezar y define cómo vas a comprobar que quedó bien: cuadre de saldos, tiempo del cierre, número de capturas.

Modernizar no significa empezar de cero

No necesitas tirar el sistema ni cambiar el ERP para dejar de depender de él. La base de datos se puede leer, las reglas se pueden reconstruir con quienes las aplican y el sistema viejo puede operar mientras el nuevo toma un módulo a la vez.

Lo primero que se moderniza no es el programa: es la libertad de que alguien más pueda trabajar sobre él. Eso se construye con respaldo, documentación mínima y una forma de conectarse que no dependa de quien escribió el código original.

En Linking trabajamos sobre los sistemas que ya tienes: agentes de IA y software a medida sobre tu ERP o sobre el sistema hecho a la medida, sin reemplazar a tu equipo (Modernización Legacy y Desarrollo de Software). Una cadena de hospitalidad con 91 sucursales opera SAP con 72% menos capital humano (caso publicado). El primer paso es una sesión de conocimiento de 30 minutos, sin costo, para ubicar cuál de tus sistemas es el que más te está costando.

El sistema que nadie se atreve a tocar no está en riesgo de dejar de funcionar. Está en riesgo de quedarse sin la única persona que sabe cómo funciona.

---

Fuentes:

• Visual Basic 6.0 Support Announcement — Microsoft Lifecycle, 8 de abril de 2008.
• Microsoft Visual FoxPro 9.0 — Microsoft Lifecycle, consultado el 4 de octubre de 2026.
• Microsoft .NET Framework — Microsoft Lifecycle, consultado el 4 de octubre de 2026.