Riesgos de una migración de frontend y cómo reducirlos

Muchos de los problemas de una migración vienen del alcance, las sorpresas y las personas. Esta guía lista los riesgos que importan, cómo detectarlos temprano y qué hacer con cada uno.

Un registro de riesgos que puedes copiar

Las secciones siguientes explican los cuatro primeros en detalle, porque son los que más daño causan.

Alcance que crece

Una migración abre todas las pantallas del producto. Cada una invita a mejorar algo: un diseño mejor, un flujo más limpio, un campo que alguien siempre quiso. Cada mejora parece pequeña. Juntas convierten una migración de tamaño conocido en un rediseño sin final.

Qué hacer

• Declara la regla al inicio: mismo diseño, mismo comportamiento. Los interesados la firman.
• Mantén una lista aparte para las ideas de mejora. Producto las prioriza después de migrar la pantalla.
• Permite una sola categoría de excepción: corregir un error es aceptable cuando mantenerlo cuesta más que eliminarlo. Registra cada caso.
• Revisa el alcance en cada punto de control. Si una fase creció, dilo y vuelve a estimar.

Regresiones

Los usuarios juzgan la migración según si su trabajo diario sigue funcionando. Unos pocos errores visibles en una pantalla migrada pueden costarle la credibilidad al programa.

Qué hacer

• Escribe pruebas end-to-end de los flujos críticos contra la app legacy antes de migrarlos. Las mismas pruebas verifican después la versión nueva.
• Publica cada pantalla detrás de un interruptor, primero para un grupo pequeño. Revisa feature flags en una migración incremental.
• Monitorea los errores de frontend por pantalla y por versión, para ver un aumento en minutos.
• Ensaya el rollback durante el piloto. Un rollback que nunca se probó es una esperanza.
• Conserva la versión legacy por un período corto y fijo después de publicar. Luego bórrala.

Reglas de negocio ocultas

Los frontends antiguos contienen reglas que no existen en ningún otro lugar. Un descuento que aplica solo a un tipo de cliente. Un campo que se vuelve obligatorio el último día del mes. Un redondeo que alguien eligió hace años. Viven en controladores y templates, sin pruebas ni documentos, y quien las escribió puede haberse ido.

Qué hacer

• Lee el template y el controlador de cada pantalla antes de estimarla. Las condiciones en el markup son reglas.
• Escribe pruebas de caracterización: pruebas que registran lo que el código hace hoy, haya o no alguien que pueda explicarlo.
• Haz una revisión de paridad con alguien que use la pantalla a diario. Esa persona nota lo que a un desarrollador se le escapa.
• Cuando una regla parezca incorrecta, pregunta antes de "arreglarla". Alguien puede depender de ella.
• Lleva cada regla descubierta a una función con nombre y con pruebas en el código nuevo. Así la migración deja las reglas mejor documentadas de lo que las encontró.

Dependencia de personas clave

Normalmente hay una o dos personas que entienden la app legacy. La migración necesita su conocimiento todos los días, y también se las necesita para incidentes y funcionalidades. Si una se va o se agota, el trabajo se detiene.

El mismo riesgo aparece del otro lado. Si un solo especialista en migración, interno o externo, concentra todo el conocimiento de la arquitectura nueva, cambiaste una dependencia por otra.

Qué hacer

• Agenda el tiempo de los expertos de forma explícita. Un bloque semanal fijo para preguntas funciona mejor que las interrupciones.
• Registra las respuestas. Una nota breve por módulo alcanza.
• Trabaja en pareja en las pantallas migradas, para que al menos dos personas conozcan cada área.
• Documenta los patrones del código nuevo: cómo se estructura una pantalla, cómo se comparte el estado, cómo se agrega una ruta.
• Rota a quienes revisan los pull requests.

Riesgos que crecen en silencio

Híbrido para siempre. La migración cubre la mayor parte de la app y pierde impulso. Las pantallas legacy que quedan son las más difíciles, y el presupuesto se acabó. Evítalo programando temprano al menos un módulo difícil y financiando la limpieza desde el inicio.

Funcionalidades en paralelo. Las funcionalidades y la migración chocan en el mismo módulo. La guía sobre seguir entregando durante la migración cubre las reglas de congelamiento que lo evitan.

Cómo revisar los riesgos

Más en esta sección

• El patrón strangler fig aplicado a frontends
• Feature flags y cambios de ruta en una migración incremental
• Salir de AngularJS: ¿Angular o React?
• Migrar una app con mucho jQuery a un framework de componentes