Costo de una migración de AngularJS: qué lo determina y cómo estimarlo
Nadie puede ponerle precio a una migración sin leer el código. Esta guía explica los factores que definen el costo y los pasos para convertirlos en una estimación que puedas defender.
Por qué nadie puede cotizar desde afuera
Dos apps AngularJS con la misma cantidad de pantallas pueden requerir esfuerzos muy distintos. Una tiene componentes limpios y una suite de pruebas. La otra tiene reglas de negocio dentro de los templates y un plugin de grilla que nadie mantiene. Un precio dado antes de leer el código es una suposición, y esa suposición suele venir inflada para proteger a quien la hizo.
Esta guía no trae cifras de precios, porque cualquier cifra que ignore tu código te llevaría a error. Te entrega la lista de factores y un método para llegar a tu propio número.
Los factores
Pantallas y su complejidad
La pantalla es la unidad natural de trabajo. Cuenta las pantallas y luego clasifícalas. Un listado de solo lectura es barato. Un formulario de varios pasos con validación condicional, autoguardado y campos por rol es caro. Tres tamaños (pequeña, mediana, grande) alcanzan para una primera estimación.
Revisa también el uso. Las pantallas que nadie abre se borran, y una pantalla borrada no cuesta nada. Analytics o los logs del servidor suelen responder esto rápido.
Widgets de terceros
Grillas, selectores de fecha, editores de texto enriquecido, gráficos y componentes de carga de archivos son una fuente frecuente de sorpresas. Cada uno necesita una decisión: reemplazarlo por un equivalente moderno, envolverlo por un tiempo o reconstruirlo. Una grilla con editores de celda propios, columnas guardadas por usuario y exportación puede costar más que varias pantallas comunes juntas. El índice de migración de librerías lista las librerías de AngularJS más usadas y sus reemplazos habituales.
Pruebas
Las pruebas end-to-end de los flujos críticos bajan el costo, porque verifican cada pantalla migrada de forma automática. Si no existen, alguien tiene que escribirlas primero o revisar la paridad a mano en cada publicación. Las dos cosas toman tiempo. Presupuéstalo de forma explícita.
Forma del código
- Los componentes escritos al estilo de AngularJS 1.5 se migran casi de forma mecánica.
- Los controladores con mucho
$scope, eventos en$rootScopey lógica dentro de los templates hay que desenredarlos antes. - La manipulación directa del DOM con jQuery hay que aislarla antes de poder reemplazarla.
Infraestructura compartida
Autenticación, sesión, capa HTTP, rutas y cadena de build se pagan una sola vez, al inicio. Esa parte fija es parecida en una app pequeña y en una grande. Por eso las migraciones pequeñas parecen caras por pantalla.
Disponibilidad del equipo
Quienes conocen las reglas de negocio suelen ser los mismos que entregan funcionalidades. Si solo pueden dedicarle unas horas por semana a la migración, las preguntas esperan y el trabajo se detiene. Si las respuestas llegan en un día, el mismo alcance termina mucho antes. La disponibilidad cambia el costo tanto como cualquier factor técnico.
Cómo llegar a un número
- Inventario. Lista cada ruta y pantalla, cada servicio y cada librería de terceros. Marca lo que no se usa.
- Clasificación. Asigna un tamaño a cada pantalla. Asigna una decisión a cada widget: reemplazar, envolver o reconstruir.
- Piloto. Migra una pantalla real de tamaño mediano, con la infraestructura compartida que necesite. Registra el esfuerzo real.
- Calibración. Usa el esfuerzo del piloto como referencia del tamaño mediano. Ajusta pequeña y grande en relación con ese valor.
- Partidas fijas. Infraestructura, preparación de pruebas, limpieza final y las horas que tu propio equipo dedica a responder preguntas y revisar.
- Fases. Agrupa y cotiza cada fase por separado, para aprobarlas de a una.
Por qué primero va un diagnóstico corto
Un diagnóstico corto produce el inventario, la clasificación y la elección del piloto. Es pequeño comparado con la migración, y reemplaza una suposición inflada por una estimación por fase que ambas partes pueden contrastar con el código.
El diagnóstico también muestra qué puedes evitar. Una parte de la app puede estar lista para borrarse. Un módulo puede quedarse como está hasta su retiro. Un solo widget puede definir una porción grande del presupuesto. La hoja de ruta por fases describe lo que sigue después.
Precio fijo o tiempo y materiales
El precio fijo por fase funciona cuando el inventario existe y el alcance de cada fase está escrito. Tiempo y materiales encaja con el diagnóstico y el piloto, donde el objetivo es aprender. Un precio fijo por toda la migración antes de cualquier diagnóstico obliga al proveedor a sumar un margen grande o a recortar calidad más adelante.
Costos que se olvidan
- Mantener los dos frameworks durante el período híbrido, con su tiempo de build y su tamaño de bundle.
- Las pruebas de regresión que hace tu gente de QA o de producto.
- La capacitación de los desarrolladores que no han usado Angular moderno.
- La fase de limpieza que elimina AngularJS y la capa de compatibilidad.
- El costo de esperar. Cada trimestre el código legacy crece y quienes lo entienden pueden irse. La guía del caso de negocio muestra cómo incluirlo en la comparación.
Más en esta sección
- ¿Cuánto tarda una migración de AngularJS?
- 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
¿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