Reescritura big bang

Una reescritura big bang reemplaza una aplicación completa por una nueva hecha desde cero y pasa a todos los usuarios en un solo corte.

En una reescritura big bang el equipo construye un reemplazo completo en paralelo a la aplicación existente. La vieja sigue en producción hasta que la nueva está lista. Luego, en una fecha elegida, todos se cambian. Los usuarios no reciben nada del sistema nuevo antes de esa fecha.

El atractivo es claro: empezar limpio, un stack moderno y nada de código puente entre lo viejo y lo nuevo. Para una aplicación pequeña con requisitos estables puede ser la decisión correcta.

Ejemplo

Una empresa decide reescribir en Angular moderno su producto AngularJS, que tiene bastante más de cien pantallas. La estimación es de doce meses. Durante ese año el producto viejo sigue necesitando correcciones y funcionalidades nuevas, porque los clientes no esperan. Cada uno de esos cambios hay que construirlo dos veces o sumarlo al backlog de la reescritura, así que el objetivo se sigue moviendo. La fecha de corte llega con pantallas faltantes y con comportamientos que nadie recordó copiar. El primer feedback real de los usuarios llega todo junto.

Confusión frecuente

Se suele asumir que reescribir es más rápido porque el equipo se libera del código legacy. Ese código también contiene años de reglas de negocio, casos borde y correcciones que no están documentados en ningún otro lugar. Redescubrirlos consume gran parte del tiempo.

El otro costo oculto es la concentración del riesgo. Todo el valor y todos los defectos llegan el mismo día, y volver atrás es difícil una vez que los datos se movieron.

Antes de elegir esta ruta, revisa el tamaño de la aplicación, si el negocio puede congelar funcionalidades y si existe una alternativa ruta por ruta. La guía Reescribir, híbrido o microfrontends compara las opciones.

Términos relacionados

• Migración incremental
• Patrón strangler fig (higuera estranguladora)
• Rollback (reversión)