Día de Muertos digital: 7 sistemas legacy que necesitas dejar morir este año

En estas fechas en México montamos altares para recordar a quienes ya no están. Permítannos un homenaje paralelo: a los sistemas legacy que siguen vivos en muchas empresas mexicanas medianas, alimentándose de la productividad del equipo, devorando presupuestos de mantenimiento y, sobre todo, drenando la energía de quienes los operan. No están muertos, pero deberían estarlo.

Esta es nuestra lista honesta de los siete sistemas que en ALCA recomendamos retirar antes de que termine el primer semestre de 2026. Para cada uno explicamos por qué duele tenerlo, cuánto cuesta mantenerlo y cuál es el camino razonable de salida.

1. El ERP de los noventa sin soporte

Lo reconocemos a la entrada del datacenter: pantallas verde sobre negro, atajos de teclado que solo entienden tres personas y el contrato de mantenimiento expirado en 2014. Sigue vivo porque "ahí está toda la información histórica" y porque migrar parece imposible.

Por qué duele: sin parches de seguridad, sin desarrolladores activos, sin documentación útil. Cada nueva regulación (CFDI 4.0, complementos del SAT) requiere hacks artesanales.

Plan de retiro: evaluación honesta de qué procesos siguen ahí, migración por módulos (típicamente nómina y contabilidad primero) a un ERP moderno como Odoo, NetSuite o un SaaS sectorial. Plazo razonable: 9 a 14 meses.

2. Excel como única fuente de la verdad

El "sistema" que nadie compró pero que opera procesos críticos. La nómina, el inventario, el pipeline de ventas, el control de cobranza, todo en hojas con macros que solo Doña Cecilia sabe cómo usar.

Por qué duele: sin control de versiones, sin auditoría, sin concurrencia real. Un compañero abre el archivo y los demás esperan. Un error en una celda y se cae el reporte mensual.

Plan de retiro: identificar los 3 a 5 archivos críticos, mapear los procesos que sostienen y migrarlos a herramientas adecuadas: Airtable o Notion para casos simples, una app interna en Retool o Budibase para casos medianos, módulos de un ERP/CRM cuando aplica. La regla: Excel está bien para análisis ad hoc, no para sistemas de registro.

3. El servidor físico bajo el escritorio del CFO

Una caja gris que llegó con Windows Server 2008. Hospeda la base de datos del sistema de facturación y un par de carpetas compartidas. El UPS murió hace meses.

Por qué duele: un backhoe afuera, un apagón en la colonia, un derrame de café y se acabó la operación. Cero redundancia, cero monitoreo, cero respaldos verificados.

Plan de retiro: virtualizar la carga (P2V) y subirla a una VM en AWS, Azure o un proveedor mexicano como KIO o Triara. Costo típico: USD 80 a 250 al mes por servidor pequeño. Plazo: 4 a 8 semanas. Beneficio inmediato: snapshots automáticos y disaster recovery real.

4. PHP 5.x en producción

El sistema interno que se hizo en 2012, corre en una versión de PHP que dejó de recibir parches en 2019 y depende de extensiones que ya no existen en distros modernas.

Por qué duele: vulnerabilidades conocidas, imposibilidad de actualizar dependencias, dificultad creciente para encontrar desarrolladores dispuestos a tocarlo.

Plan de retiro: dos caminos viables. Si el sistema sigue siendo valioso, upgrade incremental a PHP 8.x con Rector y un buen suite de pruebas. Si ya no aporta valor diferencial, reemplazo por una solución moderna (incluso un SaaS) y archivado de los datos históricos. La peor decisión es seguir parchando sin plan.

5. Backups en disco duro externo

El ritual sagrado: cada viernes, alguien copia la base de datos a un disco USB que se va en la mochila a casa del gerente. Cada año, el disco se cae al piso una vez.

Por qué duele: sin verificación de integridad, sin pruebas de restauración, sin offsite real, sin cifrado. El día que necesites restaurar, descubrirás que el último backup útil tiene tres semanas.

Plan de retiro: estrategia 3-2-1 con servicios estándar. Backup automático en S3 o equivalente con versionado, copia cifrada en otra región, prueba mensual de restauración. Costo: USD 20 a 100 al mes para la mayoría de empresas medianas. No tiene defensa razonable seguir como están.

6. FTP en lugar de SFTP

Aún vemos FTP plano expuesto a internet para intercambio con proveedores o clientes. Credenciales viajando en texto claro, archivos sin cifrar, logs inexistentes.

Por qué duele: cualquiera en la red puede capturar credenciales. Riesgo de compliance evidente bajo la LFPDPPP y cualquier auditoría seria.

Plan de retiro: migrar a SFTP (con llaves, no contraseñas) o a soluciones modernas tipo AWS Transfer Family, Azure Storage con SAS tokens, o incluso un bucket S3 con políticas adecuadas. Plazo: 2 a 4 semanas. Coordinación con contrapartes incluida.

7. El sistema custom hecho por el exempleado fantasma

El más doloroso. Una aplicación interna construida por una persona que ya no trabaja en la empresa, sin documentación, sin pruebas, con una cuenta de email personal en el dominio del repositorio. Nadie sabe cómo desplegarlo y todos rezan para que no se caiga.

Por qué duele: riesgo operativo inaceptable. Si se cae, la operación se detiene. Si se necesita un cambio, no hay quién lo haga sin gastar semanas de arqueología.

Plan de retiro: auditoría técnica para entender qué hace, qué entradas y salidas tiene. Decisión binaria: si aporta valor, adopción formal (repositorio en la organización, CI/CD, documentación, owner asignado, reescritura por partes). Si no, reemplazo por algo estándar. Plazo: 3 a 6 meses dependiendo del tamaño.

Cómo priorizar el retiro

No se puede matar todo a la vez. Recomendamos priorizar usando dos ejes simples:

• Riesgo operativo: qué tan grande sería el impacto si el sistema falla mañana.
• Costo de oportunidad: cuánto tiempo del equipo consume mantenerlo vs. lo que se podría hacer con ese tiempo.

Los que están altos en ambos ejes son los primeros del altar. En la mayoría de empresas medianas que vemos, el ranking termina siendo: backups, servidor físico bajo el escritorio, sistema custom huérfano, FTP, ERP viejo, PHP 5, Excel.

Una conversación que vale la pena tener antes de fin de año

El cierre de año es buen momento para esta conversación porque coincide con la planeación de presupuesto 2026. Retirar legacy no se trata de moda tecnológica, se trata de reducir riesgo, liberar tiempo del equipo y dejar de pagar el impuesto invisible de mantener cosas que ya no funcionan. Como dirían las abuelas: hay que dejar ir lo que ya cumplió.

---

¿Quieres armar tu plan de retiro de legacy? Te ayudamos. Agenda una conversación de 30 minutos y revisamos contigo cuáles sistemas conviene retirar primero, con qué reemplazarlos y cómo encajar todo en tu presupuesto del próximo año.