¿Cuánto tarda una migración de AngularJS?

La respuesta honesta es un rango que se va cerrando a medida que aprendes. Esta guía explica qué define la duración, qué trabajo se puede solapar y cómo proyectar con datos reales.

La respuesta corta

La duración depende del alcance, de cuánto trabajo puede avanzar al mismo tiempo y de la velocidad con que se toman decisiones. Las apps son demasiado distintas entre sí para que los promedios de la industria sirvan. La base confiable es un poco de datos reales de tu propio código y una proyección que actualizas a medida que el trabajo avanza.

Qué determina la duración

• Alcance en uso. La cantidad de pantallas que la gente todavía abre, ponderada por complejidad. Borrar pantallas sin uso es un trabajo rápido y no requiere migración.
• Widgets de terceros. Una grilla o un editor que necesita reemplazo puede bloquear todas las pantallas que lo usan hasta que el reemplazo esté listo.
• Preparación necesaria. El código que ya usa componentes y un build moderno avanza rápido. El código basado en $scope, eventos globales y etiquetas script necesita antes un paso de preparación.
• Demora en las decisiones. Cada pantalla genera preguntas sobre reglas de negocio. Si las respuestas tardan una semana, el calendario se alarga aunque el esfuerzo de ingeniería sea el mismo.
• Proceso de publicación. Un equipo que publica a diario puede lanzar una pantalla migrada y aprender de ella esa misma semana. Un equipo con una publicación mensual espera un mes por cada aprendizaje.

Las fases

La versión paso a paso está en Cómo migrar de AngularJS a Angular sin downtime.

Qué puede ir en paralelo

Hay trabajo que se solapa bien:

• Módulos independientes. Cuando la infraestructura compartida existe, dos desarrolladores pueden migrar dos módulos sin relación al mismo tiempo.
• Reemplazo de widgets. Una persona puede preparar la nueva grilla o el nuevo selector de fechas mientras otras migran pantallas que no lo necesitan.
• Escritura de pruebas. Las pruebas end-to-end contra la app legacy se pueden escribir antes de migrar las pantallas que cubren.

Hay trabajo que no se solapa:

• La infraestructura compartida va primero. Autenticación, convivencia de rutas y build tienen que funcionar antes de mover pantallas.
• Los servicios compartidos van antes que las pantallas que los usan. Si no, cada lado guarda su propia copia del estado.
• El piloto va antes de escalar. Sumar gente antes de probar los patrones multiplica el retrabajo.
• La limpieza va al final. Solo puede empezar cuando desaparece la última pantalla legacy.

Cómo proyectar una fecha

1. Termina el diagnóstico. Ya tienes una lista de pantallas con tamaños.
2. Termina el piloto. Ya conoces el esfuerzo real de una pantalla, con sus sorpresas.
3. Ejecuta la primera fase de migración y cuenta las pantallas completadas por semana o por sprint. Completada significa publicada para todos los usuarios y con la versión legacy borrada.
4. Divide las pantallas restantes por ese ritmo. Entrega el resultado como un rango.
5. Repite el cálculo al final de cada fase y comparte el rango nuevo.

La primera proyección es gruesa. Hacia la segunda o tercera fase el rango suele ser lo bastante estrecho para planificar producto. Es la misma idea que se usa al medir el avance de la migración: reporta lo terminado y deja que la tendencia entregue la fecha.

Qué alarga el plazo

• Un rediseño mezclado con la migración. Los diseños nuevos requieren decisiones, aprobaciones y pruebas nuevas.
• Reglas de negocio que solo una persona entiende, cuando esa persona está ocupada.
• Pantallas legacy que se mantienen vivas "por si acaso" después de publicar su reemplazo.

Qué lo acorta de verdad

• Borra lo que no se usa antes de migrar cualquier cosa.
• Mantén el mismo diseño y el mismo comportamiento. Mejóralos después de la migración.
• Elige un solo reemplazo por tipo de widget y reutilízalo en todas partes.
• Nombra a una persona de producto que pueda responder preguntas en un día.
• Asigna personas dedicadas. El trabajo que se hace solo en los ratos libres rara vez termina.

Qué decirle a la dirección

Entrega un rango y explica de qué depende. Comprométete con una fecha para la fase siguiente y con un rango para la migración completa, que vas a actualizar. La dirección suele aceptarlo cuando cada fase entrega algo visible. La guía de costos usa el mismo inventario, así el presupuesto y el plazo se mantienen coherentes entre sí.

Más en esta sección

• Riesgo de seguridad y cumplimiento de AngularJS
• Soporte extendido de AngularJS: un puente y sus límites
• Cómo armar el caso de negocio para modernizar el frontend
• Una hoja de ruta por fases para modernizar el frontend