> ## Content Index > Fetch the complete content index at: https://www.abnerballardo.com/llms.txt > Use this file to discover other available public pages before exploring further. # Reemplazar software crítico sin detener el negocio - URL: https://www.abnerballardo.com/es/post/reemplazar-software-critico-sin-detener-el-negocio/ - Published: 2026-01-12T03:41:28.000Z - Updated: 2026-01-12T03:41:28.000Z - Description: Cómo reemplazar software crítico sin detener el negocio ni apostar todo a un big bang. Un enfoque de liderazgo para gestionar el riesgo. - Author: Abner Ballardo - Tags: #es [Read in English](https://www.abnerballardo.com/en/post/replacing-critical-software-without-stopping-the-business/) ## Un marco de liderazgo para *Parallel Replacement* ## 1\. El problema real no es tecnología En muchas organizaciones, el reemplazo del software crítico se presenta como un problema técnico: elegir arquitectura, lenguajes de programación, *frameworks* o *cloud platforms*. Sin embargo, ese enfoque rara vez aborda el problema de fondo. Reemplazar sistemas críticos para el negocio es, ante todo, una **decisión de liderazgo**. Está condicionada por tolerancia al riesgo, continuidad de negocio, incentivos organizacionales, exposición regulatoria e impacto reputacional. Los equipos de tecnología ejecutan; el liderazgo asume las consecuencias. Cuando un sistema es central para la operación diaria, la experiencia del cliente o el cumplimiento regulatorio, la pregunta clave no es *cómo* reemplazarlo, sino *quién decide cuándo el reemplazo es más seguro que seguir intentando evolucionar lo existente*. > **Tesis:** Cuando los sistemas son críticos para el negocio, la estrategia de reemplazo debe definirse a nivel ejecutivo y no delegarse únicamente a arquitectura. ## 2\. ¿Por qué la evolución contínua suele fallar a escala? En entornos grandes y altamente operativos, el **business‑as‑usual tiende a imponerse sobre el cambio estructural**. Los sistemas en producción deben seguir atendiendo clientes mientras absorben, de forma simultánea: - nuevos pedidos de funcionalidades, - respuestas a incidentes y recuperación operativa, - cambios regulatorios, - exigencias crecientes de performance y seguridad. Aunque la evoluación incremental resulta atractiva en teoría, en la práctica la capacidad disponible de ingeniería es consumida constantemente por el presente. Con el tiempo, la promesa de “modernizamos después” se convierte en un estado permanente. Los resultados suelen repetirse: - inestabilidad recurrente y incidentes operativos, - acumulación de riesgo invisible y difícil de cuantificar, - pérdida progresiva de talento senior en ingeniería que no desea seguir manteniendo sistemas que nunca mejoran de forma estructural. No se trata de falta de disciplina ni de competencia. Es un **resultado estructural** de cómo operan las organizaciones grandes. ## 3\. El *Big‑Bang rewrite*: cuando el control se confunde con simplicidad Cuando la evolución incremental se estanca, muchas organizaciones reaccionan moviéndose al extremo opuesto: el big‑bang rewrite. La lógica parece simple: construir un nuevo sistema, migrar todo de una sola vez y dar de baja la plataforma legada. Este enfoque asume, de manera implícita, que: - los requerimientos pueden congelarse, - las condiciones del negocio permanecerán estables, - el momento de la migración puede controlarse con precisión. En entornos regulados y orientados al cliente, estas suposiciones rara vez se cumplen. El negocio sigue cambiando, los requerimientos regulatorios evolucionan y las expectativas de los usuarios no se detienen mientras los equipos de ingeniería reconstruyen. Los resultados suelen ser previsibles: - retrasos reiterados por *scope creep*, - divergencia creciente entre el sistema antiguo y el nuevo, - una transición de alto riesgo con opciones muy limitadas de rollback. Los big‑bang rewrites no fallan por falta de capacidad técnica, sino porque **las organizaciones no pueden pausar la realidad**. ## 4\. La falsa dicotomía que atrapa a las organizaciones Muchas organizaciones creen que están obligadas a elegir entre solo dos extremos: - una evolución incremental interminable que nunca concluye, - o un *rewrite* disruptivo de todo‑o‑nada. Este *framing* binario oculta una tercera alternativa y empuja a decisiones que concentran el riesgo en lugar de reducirlo. El desafío real no es elegir entre velocidad o elegancia, sino **controlar el riesgo mientras el negocio continúa avanzando**. ## 5\. *Parallel Replacement*: la estrategia del “Segundo Puente” El parallel replacement —frecuentemente descrito como construir un segundo puente junto al primero— ofrece un camino alternativo más pragmático. La estrategia consiste en: - construir un nuevo sistema en paralelo al existente, - mantener operativo la plataforma legada, - migrar usuarios, tráfico o capacidades de manera progresiva. El sistema antiguo no se retira hasta que el nuevo ha demostrado su solidez en production y bajo condiciones reales. > Este enfoque no trata de innovation ni de velocidad. Trata de **contención de riegos y opcionalidad**. ## 6\. ¿En qué debe (y no debe) enfocarse el nuevo sistema? Para que el *parallel replacement* funcione, el nuevo sistema debe diseñarse deliberadamente con restricciones explícitas. **Debe enfocarse en:** - flujos *core* del negocio, - automatización y *foundations* operacionales, - prácticas modernas de ingeniería, seguridad y observabilidad. **Debe evitar explícitamente:** - paridad de funcionalidades con el sistema legado, - bases de datos compartidas o alto acoplamiento, - reimplementar complejidad histórica. El objetivo no es recrear el pasado, sino establecer un core limpio y sostenible que pueda absorber crecimiento de forma segura. ## 7\. ¿Por qué *Parallel Replacement* reduce el riesgo organizacional? Comparado con estrategias *big‑bang*, el *parallel replacement* cambia de manera significativa cómo se distribuye el riesgo: - el negocio nunca se congela, - no existe un único momento irreversible de transición, - usuarios reales y tráfico validan los supuestos de forma temprana, - el liderazgo conserva la capacidad de pausar, redirigir o detener la iniciativa. El riesgo se distribuye en el tiempo, en lugar de concentrarse en un solo evento crítico. ## 8\. El costo oculto: sistemas duales y presión de governanza El *parallel replacement* no es gratuito ni simple. Durante un período, la organización debe aceptar: - duplicación temporal de sistemas y sobrecarga operativa, - mayor complejidad en planificación y priorización, - presión constante para seguir invirtiendo en la plataforma legada. La restricción crítica es la governanza. > **Sin autoridad clara de desmantelamiento, dueño definido y mandato ejecutivo, el *parallel replacement* falla más rápido que los *big‑bang rewrites*.** Esto no es un problema técnico. Es una responsabilidad directa del liderazgo. ## 9\. ¿Por qué el *Parallel Replacement* falla en la práctica? Cuando el *parallel replacement* falla, las causas suelen ser organizacionales, no técnicas. Entre los modos de fallo más comunes se encuentran: - bases de datos compartidas que acoplan el sistema nuevo con el antiguo, - perseguir paridad de funcionalidades en lugar de priorizar la migración, - ausencia de *sponsorship* ejecutivo explícito para retirar la plataforma legada, - coexistencia indefinida sin un *sunset* plan creíble. Estos patrones conducen a duplicación permanente, no a una transición controlada. ## 10\. ¿Cuándo *Parallel Replacement* es la opción incorrecta? El *parallel replacement* no es una solución universal. Debe evitarse cuando: - los sistemas son pequeños o de bajo riesgo, - los productos tienen una vida útil corta, - los *domains* están poco acoplados y permiten refactor incremental, - la madurez de governanza es insuficiente para forzar el desmantelamiento. En estos casos, no elegir *parallel replacement* puede ser la decisión más responsable. ## 11\. Un *Decision Framework* para líderes El *parallel replacement* se vuelve una estrategia viable cuando la mayoría de estas condiciones están presentes: - el sistema es crítico para el negocio, - la demanda de cambios es continua, - el impacto del fallas es alta o irreversible, - existe exposición regulatoria o reputacional, - el desgaste del talento senior ya es visible. Si estas señales no están presentes, enfoques más simples suelen ofrecer una mejor relación costo‑beneficio. ## 12\. El talento no es un efecto secundario — es una señal Los sistemas legados no solo acumulan *technical debt*; también acumulan **people debt**. Los ingenieros se desgastan manteniendo plataformas que nunca mejoran de forma estructural. Con el tiempo, la organización pierde exactamente el talento que necesita para modernizar con seguridad. El *parallel replacement* crea un camino creíble hacia adelante. Incluso antes de completar la migración, restablece la motivación y la confianza en que el cambio es posible. Ignorar estas señales de talento suele preceder al fallo arquitectónico. ## 13\. Cierre: reemplazar es controlar, no transformar Reemplazar software crítico es, en última instancia, una decisión estratégica sobre: - cómo se distribuye el riesgo en el tiempo, - cuánta volatilidad puede tolerar la organización, - quién asume *outcomes* irreversibles. El *parallel replacement* no es una bala de plata. Introduce costo, complejidad y tensión organizacional. Sin embargo, en organizaciones grandes, reguladas y de ritmo lento, suele ser el **camino menos peligroso disponible**. > El objetivo no es la elegancia técnica. El objetivo es **progreso controlado sin dejar al azar el negocio**.