Claves
- Las reescrituras completas fracasan más por alcance y plazos que por la tecnología.
- Poner primero una interfaz estable delante del sistema heredado y sustituir por detrás.
- Sustituir una capacidad de negocio cada vez y probarla en producción antes de pasar a la siguiente.
- Ejecutar lo antiguo y lo nuevo en paralelo y comparar resultados antes de mover el tráfico.
Una reescritura completa promete empezar de cero y suele acabar en un proyecto largo y arriesgado. Sustituir un sistema heredado paso a paso mantiene el negocio en marcha y demuestra cada avance.
Por qué se atascan las reescrituras completas
Un sistema heredado suele ser antiguo por una buena razón: funciona y el negocio depende de él. Contiene años de reglas, excepciones y correcciones, muchas sin documentar. Una reescritura tiene que redescubrirlas todas mientras el sistema antiguo sigue cambiando.
El resultado sigue un patrón conocido. El sistema nuevo tarda más de lo previsto, el antiguo necesita cambios urgentes mientras tanto y la fecha de cambio se retrasa. Entretanto, la empresa paga dos sistemas y no aprovecha ninguno.
Empezar por una interfaz estable
El primer paso no es escribir código nuevo para el núcleo. Es poner una interfaz, normalmente una capa de API, delante del sistema existente, para que las demás aplicaciones hablen con esa interfaz y no directamente con la base de datos o las pantallas antiguas.
Cuando los consumidores dependen de la interfaz y no de la implementación, se puede cambiar lo que hay detrás pieza a pieza. Es lo que suele llamarse patrón «strangler»: el sistema nuevo crece poco a poco alrededor del antiguo hasta que este puede apagarse.
Priorizar por capacidad de negocio
Elija la primera capacidad que sustituir según dos criterios: cuántos problemas causa hoy y lo aislada que está. Un buen primer candidato tiene entradas y salidas claras y pocas dependencias, como la generación de presupuestos, las notificaciones o los informes.
No empiece por la parte más central y conectada del sistema. Las primeras fases deben generar confianza y un entendimiento compartido, no poner en juego todo el proyecto.
- Listar las capacidades y los datos que posee cada una.
- Puntuar cada una según el problema de negocio y el acoplamiento.
- Empezar donde el problema es alto y el acoplamiento bajo.
- Dejar el núcleo del procesamiento transaccional para cuando el equipo conozca bien el dominio.
Demostrar cada paso en paralelo
Antes de cambiar una capacidad, ejecute la implementación antigua y la nueva en paralelo con las mismas entradas y compare los resultados. Las diferencias sacan a la luz reglas no documentadas más rápido que cualquier taller de requisitos.
Mueva el tráfico de forma gradual, por sucursal, segmento de clientes o porcentaje, y mantenga un camino de vuelta documentado. Un paso de migración que no se puede revertir necesita todavía más preparación.
Tratar la migración de datos como un proyecto propio
Los datos sobreviven al código. Los datos heredados suelen contener duplicados, formatos incoherentes y campos usados para algo distinto de lo previsto. Planifique de forma explícita la limpieza, la correspondencia y la verificación, con recuentos y sumas de control que demuestren que no se ha perdido nada.
Cuando migra la última capacidad, apagar el sistema heredado debería ser un trámite: todos los consumidores usan ya la nueva interfaz, todos los datos están verificados y el negocio lleva semanas trabajando con el sistema nuevo.
¿Le ha gustado? Reciba el próximo por correo.