Una hoja de ruta por fases para modernizar el frontend
Una migración funciona cuando cada fase tiene un resultado claro y alguien decide si se continúa. Esta plantilla te entrega las fases, los criterios de salida y el gobierno que las rodea.
Cómo usar esta plantilla
La hoja de ruta tiene cuatro etapas. Cada una termina con un punto de control donde una persona definida decide si se continúa, se ajusta o se detiene. Copia la estructura, reemplaza los ejemplos por tus módulos y agrega fechas cuando el diagnóstico te dé datos reales.
| Etapa | Objetivo | Resultado principal | Decisión en el punto de control |
|---|---|---|---|
| Diagnóstico | Saber qué tienes | Inventario, enfoque, plan de fases | Aprobar el piloto |
| Piloto | Probar el enfoque en producción | Una pantalla real publicada con el stack nuevo | Aprobar la fase 1 y las estimaciones |
| Fases de migración | Mover el producto por grupos | Pantallas publicadas, legacy borrado | Aprobar la fase siguiente |
| Limpieza | Eliminar el framework antiguo | Nada de código legacy en el bundle | Cerrar el programa |
Etapa 1: Diagnóstico
Actividades
- Inventario de pantallas, rutas, servicios y librerías de terceros, con datos de uso.
- Revisión de pruebas, cadena de build y proceso de despliegue.
- Elección del enfoque: reescritura, híbrido o microfrontends. Revisa cómo elegir.
- Elección del módulo piloto.
- Borrador de las fases con un tamaño aproximado para cada una.
Criterios de salida
- Cada pantalla está listada y marcada como migrar, borrar o dejar.
- Cada widget de terceros tiene una decisión.
- El piloto tiene alcance y definición de terminado.
Etapa 2: Piloto
Actividades
- Montar la aplicación híbrida o el shell.
- Compartir autenticación y sesión entre el código viejo y el nuevo.
- Hacer convivir las rutas viejas y las nuevas.
- Migrar una pantalla real y publicarla detrás de un interruptor.
- Preparar las pruebas end-to-end de los flujos críticos.
Criterios de salida
- La pantalla está publicada para todos los usuarios y la versión legacy está borrada.
- Se ensayó un rollback al menos una vez.
- Se registró el esfuerzo y con él se recalibraron las estimaciones de las fases.
Etapa 3: Fases de migración
Agrupa las pantallas en fases que tengan sentido para el negocio, normalmente por módulo. Una buena fase es lo bastante pequeña para terminar en semanas y lo bastante grande para entregar algo que un interesado reconozca.
Cómo ordenar las fases
- Servicios compartidos y piezas de las que dependen muchas pantallas.
- Módulos de bajo riesgo y límites claros, para tomar ritmo.
- Módulos con funcionalidades planificadas, para que lo nuevo caiga en código nuevo.
- Los módulos más usados y complejos, cuando los patrones ya estén probados.
- El shell: navegación, layout y login, cuando sea conveniente.
Definición de terminado para cada pantalla
- Mismo comportamiento que la versión legacy, verificado con pruebas o con una revisión de paridad.
- Publicada para todos los usuarios.
- Código legacy y feature flag eliminados.
Criterios de salida de cada fase
- Todas las pantallas de la fase cumplen la definición de terminado.
- No hay regresiones abiertas de severidad alta.
- La proyección de las fases restantes está actualizada.
Los pasos técnicos dentro de una fase están en Cómo migrar de AngularJS a Angular sin downtime.
Etapa 4: Limpieza
- Eliminar el framework legacy y sus librerías de las dependencias.
- Borrar la capa de compatibilidad, el router legacy y los flags que queden.
- Simplificar el build y el pipeline.
- Actualizar la documentación y la guía de incorporación.
- Terminar cualquier suscripción de soporte extendido.
Una migración sin esta etapa deja un híbrido que vive por años. Ponla en el plan y en el presupuesto desde el primer día.
Gobierno
Roles
- Sponsor. Es dueño del presupuesto y toma las decisiones en los puntos de control.
- Product owner. Responde las preguntas sobre comportamiento y acepta cada pantalla.
- Líder técnico. Es dueño del enfoque y de las reglas de calidad.
- Líder de migración. Conduce el trabajo diario y reporta el avance. Puede ser una persona interna o un partner externo.
Reglas que mantienen honesta la hoja de ruta
- No hay rediseño dentro de la migración. Los cambios de diseño o de comportamiento van al backlog de producto.
- Las pantallas nuevas se construyen solo en el stack nuevo.
- Una pantalla cuenta como migrada solo cuando su versión legacy está borrada.
- Los cambios de alcance pasan por el sponsor en un punto de control.
Puntos de control
| Punto de control | Frecuencia | Quién | Contenido |
|---|---|---|---|
| Reunión de trabajo | Semanal | Líder de migración, product owner, líder técnico | Bloqueos, preguntas, próximas pantallas |
| Reporte de avance | Mensual | Sponsor e interesados | Pantallas terminadas, proyección, riesgos, decisiones pendientes |
| Revisión de fase | Al cierre de cada fase | Sponsor | Resultado frente a los criterios de salida, aprobación de la fase siguiente |
Las métricas del reporte mensual están en medir el avance de la migración.
El sponsor puede detenerse en cualquier punto de control y conservar todo lo entregado hasta ahí. Eso hace que una hoja de ruta por fases sea más fácil de aprobar que un solo proyecto grande.
Más en esta sección
- Cómo elegir un partner para migrar tu frontend
- Riesgos de una migración de frontend y cómo reducirlos
- El patrón strangler fig aplicado a frontends
- Feature flags y cambios de ruta en una migración incremental
¿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