Cómo modernizar un sistema antiguo sin detener la operación
Apagar el sistema viejo un viernes y encender el nuevo el lunes es la forma más arriesgada de hacerlo. Esta es la alternativa, paso a paso.
· 4 minutos de lectura
Cuando ya se decidió que el sistema actual tiene que cambiar, queda la pregunta difícil: cómo hacerlo sin que la empresa deje de operar mientras tanto.
El camino habitual, construir el reemplazo completo durante un año y cambiar todo un fin de semana, concentra todo el riesgo en un solo momento. Si algo sale mal ese lunes, no hay dónde volver.
Hay una alternativa que reparte el riesgo.
La idea: reemplazar por partes
El sistema antiguo sigue operando. El nuevo se construye alrededor y va tomando responsabilidades de a una. El viejo pierde funciones progresivamente hasta quedar vacío, y entonces se apaga sin ceremonia.
Nunca hay un día de corte. Cada semana el sistema nuevo hace un poco más y el antiguo un poco menos.
Los pasos
1. Estabilizar antes de tocar nada
Antes de construir, el sistema actual necesita tres cosas: respaldos que funcionen y estén probados con una restauración real, un ambiente de pruebas donde se pueda equivocar sin consecuencias, y las vulnerabilidades más urgentes corregidas.
Sin esto, cualquier cambio posterior es un riesgo innecesario.
2. Dibujar qué hace el sistema hoy
Un mapa de las funciones y de qué depende cada una. No hace falta que sea elegante: hace falta que esté completo, porque lo que no aparece en el mapa es lo que va a aparecer como sorpresa a mitad de la migración.
En esta etapa suele descubrirse que hay funciones que nadie usa desde hace años. Esas no se migran, se descartan, y ahí se ahorra una parte importante del trabajo.
3. Elegir la primera parte
No la más fácil ni la más grande. La que genera más trabajo manual o más reclamos, y que además tenga pocas dependencias con el resto.
La primera parte cumple una función adicional: demuestra que el enfoque funciona. Conviene que sea visible.
4. Construirla aparte y conectarla
El sistema nuevo se construye al lado y se conecta con el antiguo. Durante la transición conviven, y hay dos formas de que compartan información:
- Base de datos compartida. Los dos leen y escriben en el mismo lugar. Es más simple, y sirve cuando la estructura de datos actual es razonable.
- Sincronización entre los dos. Cada sistema tiene lo suyo y los cambios se propagan. Es más trabajo, y es lo que corresponde cuando la estructura antigua es justamente uno de los problemas.
La decisión entre ambas es la más importante de todo el proyecto, y depende de si la estructura de datos actual se rescata o no.
5. Mover a los usuarios de a poco
No todos el mismo día. Primero un grupo pequeño y dispuesto, que reporte problemas sin que el negocio se resienta. Después el resto, por tandas.
Durante ese período los dos sistemas están disponibles y se puede volver atrás en minutos. Esa posibilidad de volver es la que convierte un cambio riesgoso en uno controlado.
6. Apagar la parte antigua
Cuando nadie la usa hace semanas, se desconecta. Conviene dejarla accesible solo para consulta un tiempo más, y recién después retirarla.
7. Repetir
Con la siguiente parte, hasta que el sistema antiguo quede vacío.
Lo que hay que cuidar
El riesgo real de este camino es quedarse a medias. Dos sistemas conviviendo para siempre, cada uno con la mitad de las funciones, es peor que cualquiera de los dos completo. Se evita fijando desde el inicio en qué orden se apagan las piezas y comprometiendo esa secuencia.
Cuesta un poco más en total. Construir las conexiones entre lo viejo y lo nuevo es trabajo que se desecha al final. Es el precio de no detener la operación, y en la mayoría de las empresas vale la pena.
Necesita disciplina con el alcance. La tentación de aprovechar y agregar funciones nuevas en cada parte migrada es la forma más segura de que el proyecto no termine nunca. Primero se migra igual, después se mejora.
Cuándo no conviene
Si el sistema es pequeño y se puede reconstruir en pocas semanas, la complejidad de la convivencia no se justifica. Si el negocio tolera un día detenido, un cambio directo es más barato.
Este camino es para sistemas grandes, en producción, de los que la empresa depende todos los días.
Antes de empezar
La decisión de si conviene modernizar o rehacer está en modernizar el sistema actual o desarrollar uno nuevo. El acompañamiento de un sistema en producción durante y después del cambio es la mantención y evolución de software.