De qué hablamos
La modernización de software es el trabajo de poner al día un programa que la empresa usa y necesita, pero que ha envejecido: corre en una tecnología sin soporte, solo funciona en ordenadores antiguos, lo hizo alguien que ya no está o cada cambio cuesta más que el anterior.
Bajo ese nombre hay encargos distintos. Mantener y evolucionar un programa existente que otro construyó. Migrarlo a un entorno actual sin cambiar lo que hace. Renovarlo por partes. O sustituirlo por uno nuevo, llevándose los datos. Saber cuál de ellos es el tuyo ya es parte del proyecto.
Cuándo se plantea
Las razones suelen ser de riesgo más que de comodidad: el sistema operativo o la base de datos sobre los que corre han dejado de recibir actualizaciones de seguridad; la única persona que lo conocía se ha jubilado o ha cerrado; no se puede conectar con nada nuevo; o un cambio legal o de negocio exige una modificación que nadie sabe hacer. Mientras funciona, es fácil aplazarlo; el problema es que el día que falla no hay plan.
Qué incluye un proyecto bien planteado
- Una auditoría inicial: qué hay, en qué tecnología, con qué documentación y en qué estado está el código.
- El inventario de lo que el programa hace de verdad, incluido lo que nadie recuerda que hacía.
- La elección de la estrategia: mantener, migrar, renovar por partes o sustituir.
- La migración de datos, con sus comprobaciones.
- Un periodo en paralelo y un plan de vuelta atrás.
- Documentación nueva, para no repetir la situación de partida.
- Un acuerdo de mantenimiento a partir de ahí.
Qué mueve el precio
- Si hay código fuente y documentación, o hay que deducir el funcionamiento desde fuera.
- La tecnología de origen: cuanto más antigua y rara, menos gente la domina.
- El tamaño real del programa, que suele ser mayor de lo que parece desde las pantallas.
- El volumen y la limpieza de los datos que hay que trasladar.
- La convivencia: mantener dos sistemas sincronizados durante un tiempo es trabajo añadido.
- Lo que se aprovecha para cambiar: modernizar sin tocar funciones cuesta menos que modernizar y mejorar a la vez.
De qué depende el plazo
La auditoría inicial es breve y es la que permite estimar el resto con algo de fundamento: sin ella, cualquier plazo es una suposición. Después, lo que marca el calendario es la estrategia elegida —renovar por partes reparte el trabajo en el tiempo; sustituir concentra el riesgo en un corte— y la necesidad de no interrumpir la actividad, que obliga a elegir bien los momentos de cambio.
Lo que suele complicarse
Lo que complica estos proyectos es lo que el programa viejo hace en silencio: un cálculo que se añadió hace años, un proceso nocturno, un fichero que alguien recoge cada mes. Nada de eso figura en ningún documento y todo ello se echa en falta cuando deja de ocurrir. La migración de datos es el otro punto sensible: los formatos antiguos esconden registros incompletos y criterios que cambiaron con el tiempo.
Errores que salen caros
- Esperar a que falle. Modernizar con el programa parado es hacerlo con prisa y sin margen.
- Reescribirlo todo de una vez. Es la opción con más riesgo; por partes se puede corregir el rumbo.
- Dar por buena la lista de funciones. Hay que observar cómo se usa, no solo preguntar.
- Apagar el sistema antiguo demasiado pronto. Un tiempo en paralelo descubre lo que faltaba.
- Volver a depender de una sola persona. Sin documentación ni código entregado, la historia se repite.
Qué te tiene que quedar por escrito
- El resultado de la auditoría y la estrategia elegida, con sus alternativas descartadas.
- Qué funciones se conservan, cuáles cambian y cuáles se retiran.
- El plan de migración de datos y las pruebas que lo validan.
- El procedimiento de vuelta atrás y hasta cuándo se mantiene el sistema anterior.
- La entrega del código y de la documentación, y las condiciones del mantenimiento posterior.
Situaciones habituales
Casos que caben aquí: un programa de escritorio hecho hace muchos años que solo arranca en un ordenador concreto; una aplicación web cuyo autor ya no responde y que necesita mantenimiento; una base de datos de oficina que ha crecido hasta ser el sistema central de la empresa; o un programa que funciona bien pero no puede conectarse con la tienda online ni con el banco. Si lo que falta es solo esa conexión, quizá baste una integración.
Qué preparar antes de pedir propuesta
- Qué programa es, quién lo hizo y en qué tecnología, si se sabe.
- Si se dispone del código fuente, de la base de datos y de alguna documentación.
- Qué es lo que preocupa: seguridad, dependencia de una persona, cambios que no se pueden hacer.
- Cuántas personas lo usan y para qué procesos es imprescindible.
- Si se busca solo mantenerlo, migrarlo tal cual o aprovechar para cambiarlo.