Migrar un sistema legado sin frenar la empresa

El sistema se hizo hace diez, quince años. En PHP antiguo, en Delphi, en una base de Access que alguien armó y fue creciendo. Todavía mueve la empresa: facturación, inventario, registro de clientes. Pero solo una persona sabe modificarlo, no abre en el celular, no se conecta con WhatsApp ni con la pasarela de pago. Y cada cambio pequeño se vuelve un proyecto.

No eres el único. En octubre de 2025, Pega publicó una encuesta a más de 500 responsables de TI de empresas de varios países. El 78% está de acuerdo en que el tiempo y el dinero que se gastan manteniendo sistemas antiguos tendrían mejor uso en otra cosa. Y solo el 9% dijo haber llegado a retirarlos todos. Migrar es difícil para todos. La diferencia está en cómo se hace el cambio.

Cuándo el sistema legado se vuelve un riesgo

Un sistema antiguo no es un problema por ser antiguo. Lo es cuando empieza a salir caro o a amenazar la operación. Las señales más comunes:

• Solo una persona sabe modificarlo. Si se va, se enferma o desaparece, la empresa se detiene.
• La tecnología ya no recibe correcciones de seguridad. Una falla descubierta mañana no tendrá arreglo oficial.
• Cada integración es un parche. Hojas de cálculo exportadas a mano, robots copiando pantallas, doble digitación.
• No funciona fuera de la oficina. Sin acceso desde el celular ni desde el navegador.
• Cada cambio tarda semanas. Y siempre se rompe algo en otro lado.

El segundo punto tiene fecha para mucha gente. Según la tabla oficial de PHP, la versión 8.2 deja de recibir correcciones de seguridad el 31 de diciembre de 2026. Las versiones 8.1 y anteriores ya ni aparecen en la lista de versiones con soporte. Si tu sistema corre en una de ellas, ya está expuesto o lo estará en menos de tres meses.

El costo de esperar también está medido. El informe de 2022 del CISQ, consorcio de calidad de software, estimó en US$ 1,52 billones la deuda técnica acumulada en Estados Unidos, y la llamó el mayor obstáculo para cambiar sistemas existentes. En tu empresa, aparece como el pedido simple que nunca sale.

Por qué reescribir todo de una vez suele fallar

La tentación es obvia: encargar un sistema nuevo desde cero, desarrollarlo durante meses y, en un fin de semana, apagar el viejo y encender el nuevo. Parece limpio. En la práctica, es el camino que más falla.

El motivo es que el sistema antiguo guarda reglas que nadie escribió en ningún lado. El descuento que vale solo para un tipo de cliente. El cálculo de impuestos ajustado después de una multa. La excepción creada para un proveedor en 2017. Todo eso está en el código, no en la cabeza de quien pide el sistema nuevo. En la reescritura, esas reglas desaparecen, y la empresa solo se entera cuando una factura sale mal.

En 2000, Joel Spolsky, uno de los fundadores de Stack Overflow, escribió un texto que sigue siendo referencia sobre esto. Contó el caso de Netscape, que decidió reescribir su navegador desde cero y pasó casi tres años sin lanzar una versión nueva mientras perdía mercado. Martin Fowler, autor de libros clásicos sobre arquitectura de software, dice que ha visto el plan de cambiar todo de una vez “fallar la mayoría de las veces”.

La encuesta de Pega apunta en la misma dirección. La mayor parte del costo de la deuda técnica no estaba en mantener el sistema viejo. Estaba en el tiempo que tardaban en terminar los proyectos de modernización, y otra parte importante venía de proyectos que fracasaron por culpa de los sistemas antiguos.

Cómo migrar por partes

La alternativa tiene nombre en el sector: estrangulamiento, inspirado en el higo estrangulador, que crece alrededor de un árbol hasta sostenerse solo. Fowler describe el método así: el sistema nuevo nace junto al antiguo y va asumiendo una función a la vez. Cuando pasa la última parte, el antiguo se apaga sin drama.

En la práctica, la migración sigue un orden:

1. Inventario. Listar qué hace el sistema, quién usa cada parte, con qué se conecta y dónde están los datos. Incluye las reglas escondidas en el código.
2. Primero los datos. Decidir qué va a la base nueva, en qué formato y cómo verificarlo. Un dato sucio migrado sigue sucio.
3. Elegir el primer módulo. De preferencia uno que duela en el día a día y tenga pocas dependencias. Pedidos de venta, agenda o registros suelen ser buenos candidatos.
4. Correr en paralelo. El módulo nuevo funciona junto al antiguo durante un tiempo. Los números de ambos se comparan hasta que coinciden.
5. Hacer el cambio de ese módulo. Solo de ese. El resto de la empresa sigue en el sistema antiguo.
6. Repetir. Módulo por módulo, hasta que el antiguo ya no tenga función. Entonces se apaga.

La ventaja es que cada paso entrega valor por sí solo. Si el presupuesto se ajusta a mitad de camino, lo que ya se migró está en línea y funcionando. Nadie pasa meses pagando por algo que todavía no existe.

Los cuidados que evitan sorpresas

Algunos puntos deciden si la migración termina bien:

• Accesos a nombre de la empresa. Servidor, base de datos, dominio y código deben estar bajo control de la empresa antes de empezar. Es el mismo primer paso de quien intenta retomar un proyecto de software atrasado.
• Backup probado. No basta con que exista. Alguien tiene que restaurar una copia y ver si abre.
• Quien lo usa participa. La persona de finanzas sabe qué informe no puede faltar en el cierre del mes. Tiene que probar antes del cambio.
• Criterio de terminado por escrito. Cada módulo tiene una lista de lo que debe funcionar y de qué números deben coincidir.
• Costo de mantener los dos. Durante la migración, la empresa paga el sistema viejo y el nuevo. Eso entra en la planificación desde el inicio, junto con lo que costará mantener el sistema nuevo en línea después.

Cómo lo hacemos en el Studio

Nuestro trabajo de rescate empieza por el diagnóstico. Leemos el código y los datos del sistema antiguo, listamos las reglas que guarda y trazamos el orden del cambio. Solo después sale el precio cerrado, con plazo por escrito en el contrato. El código, los archivos y los accesos del sistema nuevo quedan a nombre del cliente, y el trabajo lo hace nuestro equipo de desarrollo.

Unir y reemplazar sistemas que ya mueven la operación es un trabajo que ya hicimos. En LCX, empresa de turismo con operación en más de 10 países de América del Sur, había un sistema por país. Se convirtieron en un solo sistema, en línea en 29 días.

Todo sistema que entregamos sale con un agente de IA que corre a diario, señala fallas, sugiere mejoras y verifica si los datos tienen sentido. En una migración, eso pesa: es el que avisa cuando un número del sistema nuevo no coincide con lo esperado.

Si tu empresa depende de un sistema que ya nadie puede mantener, el rescate de proyectos del Studio empieza por el diagnóstico de lo que existe y entrega la migración por partes, sin frenar la operación.