Reescribir, híbrido o microfrontends: cómo elegir

No hay una sola forma correcta de salir de un frontend legacy. El camino depende del tamaño de la app, la cantidad de equipos y cuánto riesgo puedes asumir. Así se decide.

Los tres caminos

• Reescritura. Construir la app de nuevo en Angular moderno y cambiar de una vez.
• Migración híbrida. El framework viejo y el nuevo corren en la misma app; las pantallas se mueven de a una.
• Microfrontends. La app se divide en partes que se construyen y despliegan de forma independiente, compuestas por un host. Cada equipo migra y publica su parte.

Son herramientas para situaciones distintas, y las migraciones grandes suelen combinarlas.

Los criterios que de verdad importan

1. Tamaño de la app. Cuenta pantallas y módulos; las líneas de código dicen menos. Diez pantallas y cien pantallas son problemas distintos.
2. Cantidad de equipos. Un equipo se coordina en una daily. Cinco equipos compartiendo un despliegue, no.
3. Acoplamiento de las publicaciones. Si cada publicación necesita la aprobación de todos, la arquitectura del frontend ya es un cuello de botella.
4. Tolerancia al riesgo. Una herramienta interna y un producto que genera ingresos no pueden permitirse las mismas fallas.
5. Presión del roadmap. ¿Puede detenerse el desarrollo de funcionalidades por tres meses? Casi nunca.
6. Cobertura de pruebas. Sin pruebas, cada cambio grande es una apuesta.
7. Forma del presupuesto. ¿Un pago grande por adelantado, o fases que se aprueban de a una?

Reescritura

Ideal para: apps pequeñas (menos de diez pantallas, aproximadamente), un desarrollador o un equipo chico, baja complejidad de integración.

Por qué funciona ahí: el resultado es limpio, no hay capa de compatibilidad que mantener, y todo toma semanas en vez de meses.

Por qué falla en otros casos: el desarrollo de funcionalidades se congela; la app nueva tiene que igualar años de comportamiento no documentado antes de que alguien pueda usarla; el cambio es un único evento de alto riesgo; y si las prioridades cambian a mitad de camino, quedas con dos productos a medias. Las reescrituras además tienden a convertirse en rediseños, lo que duplica el alcance.

Migración híbrida

Ideal para: apps medianas de un solo equipo, donde el producto tiene que seguir evolucionando durante la migración.

Por qué funciona: ambos frameworks corren dentro de una sola aplicación, así que cada pantalla se puede migrar, publicar y revertir por separado. Los usuarios nunca notan un cambio. El equipo sigue entregando. Puedes parar después de cualquier fase y seguir teniendo un producto que funciona.

Costos: una capa de compatibilidad que hay que montar bien (sesión compartida, convivencia de rutas, servicios compartidos), un bundle más grande durante la fase híbrida, y disciplina de ingeniería para borrar de verdad el código viejo a medida que avanzas. Un híbrido que vive para siempre es el modo de falla de este camino.

El paso a paso está en Cómo migrar de AngularJS a Angular sin downtime.

Microfrontends

Ideal para: plataformas grandes donde varios equipos son dueños de distintas áreas del negocio y necesitan publicar de forma independiente.

Por qué funciona: una aplicación host se encarga del enrutamiento, el login y el layout compartido, y carga cada área en tiempo de ejecución. Cada equipo tiene su propio repositorio, su propio pipeline y su propio calendario de publicaciones. La migración puede avanzar área por área, al ritmo de cada equipo, sin congelar toda la plataforma.

Costos, y son reales: infraestructura compartida (host, carga de módulos, versionado), un design system compartido para que el producto siga pareciendo un solo producto, contratos entre equipos para navegación y eventos, y trabajo de rendimiento para que varios bundles sigan siendo rápidos. Para un solo equipo, todo esto es costo sin beneficio.

Lado a lado

Las estrategias mixtas son normales

El plan más común en una plataforma grande es: microfrontends entre áreas de negocio, y migración híbrida dentro de cada área. Las herramientas pequeñas y aisladas que están al lado de la plataforma se reescriben directamente. La decisión de arquitectura se toma por área.

Siete preguntas antes de decidir

1. ¿Cuántas pantallas tiene la app, y cuántas se usan de verdad?
2. ¿Cuántos equipos cambian el frontend, y con qué frecuencia se bloquean entre sí?
3. ¿El roadmap del producto tolera congelar funcionalidades? ¿Por cuánto tiempo?
4. ¿Qué flujos dolerían más si se rompieran por una hora?
5. ¿Tenemos pruebas de esos flujos?
6. ¿Necesitamos la opción de parar después de una primera fase?
7. ¿Quién va a ser dueño de la capa de compatibilidad o del host, y por cuánto tiempo?

Una regla simple

Pequeña y aislada: reescribir. Mediana y un equipo: híbrido. Grande y muchos equipos: microfrontends, con híbrido adentro. Ante la duda, haz un diagnóstico de una o dos semanas antes de comprometer presupuesto. Elegir mal el camino cuesta mucho más que dos semanas de análisis.