El sistema probablemente no necesita una reescritura
Antes de aprobar una reconstrucción de varios años, revise qué se puede aislar, medir y cambiar de forma segura.
Una reescritura completa suele proponerse cuando los ciclos de lanzamiento se ralentizan y cada funcionalidad atraviesa varias partes del sistema. La propuesta puede ser razonable, pero debe tratarse como una decisión de alto coste, no como respuesta automática a la deuda técnica.
Revisar primero las restricciones
Empiece por mapear dependencias, propiedad de datos, acoplamiento de despliegue y reglas de negocio que no están documentadas. Así se ve si el problema se limita a algunos dominios o afecta a toda la plataforma.
Un monolito modular o una capa de compatibilidad pueden reducir el riesgo antes de separar servicios. El objetivo no es conservar código antiguo, sino evitar reemplazar reglas de negocio que funcionan sin una razón clara.
Modernizar por etapas
Cuando sea necesario reemplazar un componente, dirija una parte definida del tráfico a la nueva capacidad mientras el camino existente sigue disponible. Mida el resultado, documente la decisión y continúe solo cuando el cambio sea estable.
Ejecutar componentes antiguos y nuevos en paralelo añade complejidad temporal. Ese coste puede ser aceptable si protege la entrega del producto y hace reversible la migración.
Medir una transición segura
Antes del primer cambio, registre métricas de base: tiempo de entrega de un lanzamiento, errores en el flujo crítico y proporción de tráfico atendida por el componente nuevo. Cada etapa necesita un responsable, una condición de parada y una forma de devolver el tráfico a la ruta anterior.
Después de la transición, revise el resultado de negocio además de las métricas técnicas. Si el nuevo límite no reduce la coordinación ni mejora la fiabilidad, ajuste el plan antes de pasar a la siguiente etapa.