Carlos Cifuentes
Modernización · Feature flags

Feature flags y cambios de ruta en una migración incremental

Una pantalla migrada debe llegar a producción detrás de un interruptor. Si algo sale mal, lo apagas y los usuarios vuelven a la versión anterior en minutos. Así se monta y se mantiene ordenado.

Por Carlos Cifuentes · Arquitecto frontend · Actualizado 2026-10-02

Qué hace el interruptor

Durante una migración incremental, la versión antigua y la versión nueva de una pantalla existen al mismo tiempo por un período corto. Un interruptor decide cuál recibe cada usuario. Primero despliegas el código, lo activas para pocas personas, observas y amplías la audiencia cuando estás conforme.

Hay dos formas comunes:

  • Cambio de ruta. El router decide si una URL la atiende la pantalla nueva o si cae a la pantalla legacy.
  • Feature flag. Un ajuste con nombre, evaluado por usuario o por cliente, que el cambio de ruta consulta.

En la práctica se usan juntos: un flag por pantalla o módulo migrado, leído por el router.

Un cambio de ruta mínimo

En Angular, una ruta puede ser condicional con un guard canMatch. Si el guard devuelve false, el router sigue con la próxima ruta que coincida, que es el respaldo legacy.

export const routes: Routes = [
  {
    path: 'invoices',
    canMatch: [() => inject(FlagService).isOn('invoices-v2')],
    loadComponent: () => import('./invoices/invoices.component')
      .then(m => m.InvoicesComponent),
  },
  // lo que no coincide arriba lo renderiza la app legacy
  { path: '**', component: LegacyHostComponent },
];

FlagService y LegacyHostComponent son nombres de ejemplo para tu lector de flags y para el componente que aloja la aplicación legacy. La URL es la misma en ambos casos, así que los marcadores y los enlaces siguen funcionando con cualquiera de las dos versiones.

Dónde viven los flags

No necesitas un producto pagado para empezar.

OpciónCómo funcionaSirve para
Endpoint de configuraciónLa app carga al iniciar un JSON pequeño con los flagsLa mayoría de las migraciones de un solo equipo
Ajuste por usuario o por clienteEl backend devuelve los flags junto con el perfil del usuarioDespliegue por cliente o por rol
Plataforma de flagsUn servicio dedicado con reglas de segmentación y un panelVarios equipos, despliegues por porcentaje, registro de auditoría

La propiedad esencial es que un flag pueda cambiar sin un nuevo despliegue. Un flag compilado dentro del bundle solo ayuda durante el desarrollo.

Una secuencia de despliegue

  1. Desplegar apagado. La pantalla nueva está en producción con su flag apagado. Nada cambia para los usuarios.
  2. Usuarios internos. Activa el flag para el equipo y para QA. Corre las pruebas end-to-end contra las dos versiones.
  3. Un grupo real pequeño. Algunos clientes cercanos o una oficina. Observa errores y tickets de soporte.
  4. Todos. Activa el flag para todos los usuarios.
  5. Período de observación. Mantén disponible la versión legacy por un plazo fijo, acordado de antemano.
  6. Borrar. Elimina la pantalla legacy y el flag mismo.

Qué hace seguro un rollback

Un rollback solo funciona si la pantalla antigua todavía puede manejar los datos que produjo la nueva.

  • Mantén el mismo API durante el cambio. Si ambas versiones llaman a los mismos endpoints con los mismos datos, un usuario puede pasar de una a otra sin problema.
  • No cambies el modelo de datos en la misma publicación. Los cambios de backend que la pantalla legacy no puede leer vuelven el cambio de un solo sentido.
  • Mantén la URL idéntica. Misma ruta y mismos parámetros.
  • Comparte la sesión. Apagar un flag nunca debe cerrar la sesión de nadie.

Si una pantalla migrada necesita un cambio de backend, publica primero ese cambio, en una forma que ambas versiones puedan usar. Después cambia la pantalla. Dos cambios detrás de un mismo flag no se pueden revertir por separado.

Observa las dos versiones

Un flag solo sirve si puedes ver qué pasa después de activarlo.

  • Etiqueta los errores de frontend con la pantalla y la versión que los produjo.
  • Compara la tasa de errores de la versión nueva con la de la versión legacy en la misma pantalla.
  • Sigue la acción clave de la pantalla, por ejemplo los pedidos enviados. Una caída es una señal aunque no se registre ningún error.
  • Acuerda de antemano quién puede apagar un flag y en qué condiciones. Durante un incidente nadie debería tener que pedir permiso.

Higiene de flags

Los flags de migración son temporales. Si se dejan solos, se acumulan y se convierten en un segundo tipo de legacy.

  • Asigna a cada flag un responsable y una fecha de eliminación al crearlo.
  • Usa una regla de nombres, por ejemplo el prefijo migration-, para listarlos con facilidad.
  • Incluye la eliminación del flag en la definición de terminado. Una pantalla está terminada cuando el código legacy y el flag ya no existen.
  • Reporta cada mes la cantidad de flags de migración abiertos. Debe mantenerse baja y estable. Revisa medir el avance de la migración.

Cómo encaja en el patrón general

Los flags son el mecanismo de publicación del patrón strangler fig. El patrón dice qué pieza se mueve después. El flag decide quién la ve y te da el camino de vuelta. Juntos atienden el riesgo de regresiones descrito en riesgos de migración y cómo reducirlos. La migración paso a paso está en Cómo migrar de AngularJS a Angular sin downtime.

Más en esta sección

¿Planeas una migración o una plataforma de microfrontends?

En una llamada de 20 minutos me cuentas tu situación y te digo cómo la abordaría. Si todavía no vale la pena, también te lo digo.

Escríbeme por LinkedIn