Día de Muertos digital 2024: 7 sistemas legacy que necesitas dejar morir este año
En estas fechas en Mérida ponemos altares con cempasúchil, copal y la foto de quien recordamos. En las oficinas, mientras tanto, hay otros muertos que llevan años sin descansar: sistemas que dejaron de tener sentido hace mucho, pero que siguen ahí porque "hasta hoy ha funcionado" o porque "no hay tiempo de tocarlos". En ALCA hemos visto los mismos siete fantasmas en empresas medianas mexicanas, sin importar industria.
Este es el altar. Cada entrada incluye por qué duele, qué cuesta mantenerla, plan de retiro y alternativa razonable para 2025. La idea no es retirarlas todas en un trimestre; es identificar cuáles ya pasaron del límite saludable y empezar a despedirlas con orden.
1. El ERP de los 90s sin soporte oficial
El difunto. Un ERP local instalado entre 1998 y 2008, con base de datos propietaria y módulos modificados por consultores que ya no responden el teléfono. Corre en un Windows Server 2008 R2.
Por qué duele. Cualquier integración nueva (e-commerce, BI, cualquier API moderna) requiere ETL nocturno con archivos planos. Cada cambio de SAT en CFDI cuesta tres meses de desarrollo a la medida.
Costo real. Entre licencias del SO obsoleto, contratos de mantenimiento con un solo proveedor cautivo y horas perdidas en reportería manual, una empresa mediana fácilmente quema $400k a $800k MXN al año en este zombi.
Plan de retiro. Inventario de procesos críticos en 4 semanas, evaluación de alternativas SaaS o cloud (Odoo, NetSuite, SAP Business One Cloud, dependiendo de tamaño) en 4 más, migración por módulos en fases de 3 meses durante 12-18 meses. Nunca big-bang.
2. Excel como única fuente de verdad
El difunto. Un libro de Excel guardado en Google Drive (o peor, en el escritorio de Mariana de finanzas) que es la verdad para inventario, comisiones, presupuesto o pipeline de ventas. Tiene macros, vínculos rotos a otros archivos y una pestaña oculta llamada "no_tocar".
Por qué duele. Una sola persona puede romperlo sin querer. No hay historial, no hay control de acceso real, no se puede consultar desde otro sistema sin copy-paste. Cuando esa persona se va de vacaciones, la operación se ralentiza.
Costo real. Difícil de cuantificar en pesos, pero se mide en horas semanales de reconciliación, errores de tipeo que impactan reportes a dirección y la imposibilidad de tomar decisiones con datos frescos.
Plan de retiro. Identificar las 3 hojas más críticas. Para cada una: si es operativa (inventario, comisiones), migrar a una app simple (Airtable, Baserow, NocoDB, o módulo del ERP); si es analítica, llevarla a un dashboard (Metabase, Power BI). Mantener Excel solo para análisis ad-hoc, nunca como sistema de registro.
3. El servidor físico bajo el escritorio del CFO
El difunto. Una torre Dell Optiplex de 2012 que corre la facturación, el sistema de RRHH y "no recordamos qué más". Le pusieron un UPS porque "en lluvias se va la luz". Está en una oficina, no en un cuarto con clima.
Por qué duele. Punto único de falla absoluta. Sin redundancia, sin clima controlado, sin respaldo offsite. La temperatura ambiente lo desgasta. Una visita de mantenimiento puede tirar tres procesos críticos.
Costo real. El día que falla, son entre 8 y 72 horas de operación parada. En empresa mediana eso pasa rápido de $200k a $2M MXN de impacto, sin contar daño reputacional.
Plan de retiro. Inventario de qué corre ahí (a menudo descubrimos cosas que nadie recuerda). Migrar lo crítico a cloud (AWS, Azure, GCP, o nube mexicana si hay requisito de soberanía) en 60-90 días. Apagar el server físico solo después de 30 días de operación estable en cloud.
4. PHP 5.x en producción
El difunto. Una aplicación interna o un portal externo construido en 2014 con PHP 5.6, MySQL 5.5 y un framework que ya nadie mantiene (Codeigniter 2, Symfony 1, FuelPHP). PHP 5.6 dejó de recibir soporte de seguridad en 2018.
Por qué duele. Vulnerabilidades conocidas sin parche disponible. Hosting limitado a proveedores que aún ofrecen versiones antiguas (caro y precario). Imposible incorporar librerías modernas. Cada CVE nuevo es ruleta rusa.
Costo real. Si esa app expone datos personales, es exposición regulatoria directa con la LFPDPPP. Más el tiempo de desarrollo cuando algo se rompe (3x lo que costaría en stack moderno).
Plan de retiro. Auditoría de código y dependencias en 2 semanas. Decisión: actualizar a PHP 8.x con framework moderno (Laravel, Symfony reciente) o reescribir si la deuda de diseño es severa. Plan de 3-6 meses con pruebas de regresión.
5. Backups en disco duro externo
El difunto. Los respaldos críticos viven en un disco USB que alguien lleva a su casa el viernes y trae de vuelta el lunes. O peor: en un NAS sin offsite, en la misma oficina que los servidores.
Por qué duele. Un robo, un incendio o un ransomware se lleva el original y el respaldo en la misma jugada. La restauración nunca se prueba; el día que se necesita, el disco está corrupto o la persona que sabía cómo restaurar ya no trabaja ahí.
Costo real. En el escenario peor (ransomware sin posibilidad de recuperar), es existencial: empresas medianas que no pueden restaurar quiebran o quedan severamente dañadas en 3-6 meses.
Plan de retiro. Implementar regla 3-2-1: 3 copias, 2 medios distintos, 1 offsite. Usar S3/GCS/Azure Blob con object lock (immutable) para la copia offsite. Probar restauración trimestralmente. Sin prueba, no es respaldo.
6. FTP sin SFTP (ni autenticación moderna)
El difunto. Un servidor FTP de los 2000 donde proveedores y socios suben archivos (catálogos, layouts de banco, datos de comisiones). Usuario y contraseña viajan en texto plano. La contraseña es algo como "ftp2019".
Por qué duele. Cualquiera en la red puede capturar credenciales. Cualquiera con esas credenciales puede subir o bajar lo que quiera. No hay log decente, no hay control de acceso granular, no hay 2FA.
Costo real. Vector clásico de incidente. Si por ahí pasan datos sensibles (CFDIs, layouts de nómina, expedientes), es exposición regulatoria.
Plan de retiro. Migrar a SFTP con llaves SSH (no contraseñas) o, mejor, a un servicio gestionado tipo AWS Transfer Family, Azure Blob con SAS, o un MFT propiamente dicho. Periodo de transición con dual-write 30 días, comunicación clara a socios externos.
7. El sistema custom hecho por el ex-empleado fantasma
El difunto. Una aplicación que hace algo crítico (cálculo de comisiones, generación de reportes regulatorios, integración con un proveedor) hecha por una persona que ya no trabaja en la empresa hace 4 años. Sin documentación. Sin pruebas. Sin nadie que sepa cómo cambiarla.
Por qué duele. Es una caja negra crítica. Cualquier cambio se posterga eternamente. El día que se rompe, la operación se detiene hasta que alguien (caro y externo) descifra el código.
Costo real. El costo es la incapacidad de evolucionar. Mientras el resto del negocio cambia, esta caja queda igual y se vuelve cuello de botella.
Plan de retiro. Auditoría de código y datos (1-3 semanas, depende de tamaño). Decisión entre tres caminos: documentar y meter pruebas para hacerlo mantenible, reescribir desde cero con stack moderno, o reemplazar por SaaS si existe alternativa. La elección depende del tamaño y la criticidad.
Cómo priorizar este altar para 2025
No retiren los siete a la vez. Recomendamos esta priorización:
- Lo que es riesgo de seguridad inmediata (PHP 5.x expuesto a internet, FTP, backups frágiles): primero.
- Lo que es punto único de falla operativa (servidor bajo el escritorio, sistema del fantasma): segundo.
- Lo que bloquea iniciativas estratégicas 2025 (ERP que no integra, Excel maestro): tercero.
Para cada uno: dueño claro, presupuesto explícito, fecha de retiro y, sobre todo, criterio para apagar definitivamente. Sistemas que se quedan "encendidos por si acaso" tres años más son los que generan al siguiente fantasma.
Feliz Día de Muertos. Despídanlos con cariño, pero despídanlos.
¿Quieres armar tu plan de retiro de legacy? Te ayudamos. En ALCA hacemos la auditoría, priorización y acompañamiento en la migración con un formato probado. Solicita una conversación.
