- Señales de alarma: solo una persona lo entiende, no admite integraciones, falla con más volumen o no puede cumplir normativas nuevas como Verifactu.
- Reescribirlo todo de golpe es la opción más arriesgada. Migrar por módulos, con el sistema antiguo funcionando, es la más segura.
- La IA acelera la parte más lenta: entender y documentar el código antiguo.
- El proyecto se controla con entregas cortas: cada pocas semanas, un módulo nuevo en producción.
Casi todas las empresas con más de diez años tienen uno: un programa hecho a medida, una base de datos de Access, un ERP antiguo muy personalizado. Funciona, hasta que deja de hacerlo o hasta que el negocio necesita algo que ya no puede dar.
Cinco señales de que ha llegado el momento
- Dependencia de una persona. Si quien lo mantiene se va, nadie sabe cómo funciona.
- No se conecta con nada. Tu equipo copia datos a mano entre el programa y el resto de herramientas.
- Normativa nueva. Verifactu, facturación electrónica o protección de datos exigen cambios que el sistema no admite.
- Rendimiento. Va lento con más usuarios o más datos, y cada mejora rompe otra cosa.
- Seguridad. Corre sobre versiones sin soporte que ya no reciben parches.
Las cuatro estrategias y cuándo usar cada una
| Estrategia | En qué consiste | Cuándo encaja | Riesgo |
|---|---|---|---|
| Sustituir | Cambiar a un producto estándar | El proceso es común y el programa no aporta ventaja | Adaptar la empresa a la herramienta |
| Encapsular | Mantener el núcleo y darle una API y una interfaz nueva | El núcleo funciona pero está aislado | Bajo, pero no resuelve la deuda |
| Migrar por partes | Construir módulos nuevos que sustituyen poco a poco al antiguo | El programa es crítico y no se puede parar | Bajo y controlado |
| Reescribir de golpe | Construir el sistema nuevo entero y cambiar un día | Sistemas pequeños y bien documentados | Alto: plazos y alcance se disparan |
Comparativa de estrategias de modernización.
En sistemas críticos, la opción que mejor funciona es migrar por partes: el sistema nuevo crece alrededor del antiguo y va asumiendo funciones una a una, hasta que el antiguo se puede apagar sin que nadie lo note.
El método por partes, paso a paso
- Inventario. Qué hace el sistema, quién lo usa, qué datos guarda y con qué se conecta.
- Mapa de dependencias. Qué partes se pueden separar primero sin romper el resto.
- Capa intermedia. Una API que da acceso a los datos del sistema antiguo para que lo nuevo pueda leerlos y escribirlos.
- Primer módulo. Se elige uno de valor visible y riesgo bajo: un portal de clientes, un informe, el alta de pedidos.
- Convivencia. Durante semanas funcionan los dos y se comparan resultados.
- Corte. Cuando el módulo nuevo es fiable, se retira el antiguo para esa función. Y se repite.
Qué aporta la IA a una modernización
La parte más lenta de modernizar no es escribir el código nuevo: es entender el antiguo. Reglas de negocio enterradas en procedimientos de base de datos, lógica sin documentar, nombres crípticos. La IA acelera mucho este trabajo:
- Leer el código antiguo y documentar qué hace cada parte y qué reglas aplica.
- Generar pruebas que capturan el comportamiento actual, para comprobar que lo nuevo hace lo mismo.
- Traducir y limpiar datos al migrarlos al nuevo modelo.
- Proponer el código equivalente en tecnología actual, que después revisa un ingeniero.
La IA no sustituye la revisión técnica. Acelera el análisis y reduce errores, pero las decisiones de arquitectura siguen siendo humanas.
Plazos y coste orientativos
El coste depende del tamaño del sistema, de la calidad de su documentación y de cuántas integraciones tenga. Más útil que una cifra cerrada es el ritmo: con migración por partes, lo razonable es tener un primer módulo en producción en 6 a 10 semanas y avanzar con entregas cada 3 o 4 semanas. Así el presupuesto se controla por etapas y cada una ya aporta valor.
Errores que alargan el proyecto años
- Querer replicar todas las funciones antiguas, incluidas las que nadie usa.
- No tener pruebas del comportamiento actual antes de tocar nada.
- Migrar los datos al final, en lugar de desde el primer módulo.
- No implicar a los usuarios hasta el día del cambio.
- Aprovechar la migración para rediseñar todos los procesos a la vez.
Preguntas frecuentes
¿Cuándo hay que modernizar un software antiguo?
Cuando depende de una sola persona, no se integra con otras herramientas, no puede cumplir normativas nuevas, falla con más volumen o corre sobre tecnología sin soporte de seguridad.
¿Es mejor reescribir o migrar por partes?
En sistemas críticos, migrar por partes. El sistema nuevo va asumiendo funciones mientras el antiguo sigue funcionando, lo que reduce el riesgo y permite controlar el presupuesto por etapas.
¿Cuánto tarda modernizar un software heredado?
Depende del tamaño, pero con migración por partes es razonable tener un primer módulo en producción en 6 a 10 semanas y avanzar con entregas cada 3 o 4 semanas.
¿Se pierden datos en una migración?
No si se migran desde el primer módulo, con validaciones y comparación de resultados entre el sistema antiguo y el nuevo durante un periodo de convivencia.
¿Puede la IA modernizar el código automáticamente?
Acelera el análisis, la documentación, las pruebas y la traducción de código, pero el resultado debe revisarlo un ingeniero. No es una conversión automática sin supervisión.
