Cuándo NO migrar

Un nivel dedicado a migrar tiene la obligación de terminar explicando cuándo no hacerlo, porque las cuatro lecciones anteriores enseñan a ejecutar bien un proyecto cuya principal fuente de desperdicio no es la mala ejecución sino la mala elección de emprenderlo. Migrar el estado de una aplicación en producción no es una mejora incremental: es consumir semanas de la capacidad del equipo para llegar a un sitio donde el usuario no percibe absolutamente nada distinto. Eso puede estar plenamente justificado —cuando el modelo actual bloquea el desarrollo, multiplica los bugs o hace inviable incorporar gente— y puede ser también la forma más elegante de desperdiciar un trimestre. La diferencia entre ambos casos no la marca la calidad de la herramienta destino, sino un cálculo que casi nadie hace por escrito y que esta lección obliga a hacer antes de escribir la primera línea.

El coste que ninguna estimación incluye

Las estimaciones de migración se hacen casi siempre en unidades equivocadas: se cuentan los slices a convertir y se multiplican por un tiempo medio optimista. Ese cálculo omite tres partidas que en la práctica suman más que la propia conversión. La primera es la revisión y el aprendizaje: cada cambio lo lee alguien más, y cada persona del equipo paga una curva con el modelo nuevo. La segunda es el arrastre sobre el trabajo en curso, porque durante meses toda funcionalidad nueva se escribe dos veces o se escribe mal, según el slice que toque. La tercera, y la mayor, es lo que el equipo no construye mientras tanto.

// el presupuesto real de una migracion, en semanas de equipo
interface Presupuesto {
  conversion: number      // lo unico que suele estimarse
  revision: number        // leer, discutir y corregir cada cambio
  arrastre: number        // funcionalidades ralentizadas mientras conviven dos modelos
  incidencias: number     // bugs silenciosos descubiertos despues de desplegar
  oportunidad: number     // lo que no se construye: la partida mayor y la nunca escrita
}

const total = (p: Presupuesto) =>
  p.conversion + p.revision + p.arrastre + p.incidencias + p.oportunidad

La utilidad de escribir el presupuesto así no está en la precisión de los números, que será mala, sino en que obliga a nombrar partidas que de otro modo permanecen invisibles. En cuanto la línea de oportunidad tiene un valor explícito, la conversación cambia de naturaleza: ya no se discute si Zustand es mejor que Redux, sino si esta migración vale más que las tres cosas que no haremos por hacerla. Esa segunda pregunta tiene respuesta; la primera, en abstracto, no la tiene.

Hay una asimetría adicional que conviene explicitar al presentar el presupuesto: las partidas de conversión y revisión se pagan seguro, mientras que el beneficio prometido es probabilístico. Menos bugs, incorporaciones más rápidas, funcionalidades desbloqueadas: todo eso puede ocurrir, y ocurrirá en la medida en que el diagnóstico fuera correcto. Comparar un coste cierto con un beneficio esperado sin decir en voz alta que uno es cierto y el otro no es la manera silenciosa en que estos proyectos se aprueban con números que nadie habría firmado de haberlos visto etiquetados.

Por qué el riesgo aquí es peor

No todas las migraciones tienen el mismo perfil de riesgo, y la de gestión de estado está en el extremo desfavorable por una razón estructural: sus fallos no son ruidosos. Cambiar de empaquetador falla en la compilación, y el problema aparece antes de desplegar. Cambiar de gestión de estado produce fallos que compilan perfectamente, pasan la revisión y solo se manifiestan como un panel que no se actualiza en cierta secuencia de navegación, un valor que se pierde al volver atrás o un renderizado de más que degrada una pantalla concreta.

flowchart TD
M[migracion de estado] --> S[fallo silencioso]
M --> D[fallo difuso]
S --> T1[compila y pasa revision]
D --> T2[aparece semanas despues en un flujo raro]
T1 --> R[coste real muy superior al estimado]
T2 --> R
style S fill:#f38ba8,color:#11111b
style D fill:#f38ba8,color:#11111b
style R fill:#fab387,color:#11111b

A esa característica se suma otra: el estado es transversal. Un cambio de librería de gráficas afecta a las pantallas que dibujan gráficas, y su radio de explosión es acotado y conocido. El estado global lo lee media aplicación, de modo que un error de suscripción en un slice central se manifiesta en pantallas que nadie relacionó con el cambio, semanas después, cuando el contexto ya se perdió. Por eso las migraciones de estado incumplen sus plazos con una regularidad que no se explica por incompetencia: la parte que se estima es la conversión, y la parte que se paga es la cola larga de fallos difusos.

Las señales de parada y la alternativa de contener

Ese perfil tiene una consecuencia práctica sobre las pruebas que casi nadie extrae. Si los fallos de una migración de estado son silenciosos, entonces la única defensa proporcionada al riesgo son pruebas que ejerciten los flujos de estado de extremo a extremo, y no pruebas unitarias de reductores, que seguirán pasando exactamente igual porque la lógica no cambia. Un equipo que se dispone a migrar con buena cobertura unitaria y ninguna prueba de flujo está protegido justo en la parte donde no había peligro y desnudo en la parte donde lo hay.

Cinco situaciones deberían detener el proyecto antes de empezarlo, y ninguna de ellas es una opinión sobre la calidad de las herramientas. La primera: el store funciona y no genera bugs recurrentes. Un modelo aburrido que nadie toca no es deuda técnica, es infraestructura amortizada. La segunda: el equipo no domina el destino; migrar mientras se aprende produce en la herramienta nueva los mismos errores que se querían dejar atrás, con menos experiencia para detectarlos. La tercera: no hay tests alrededor del estado, de modo que la migración se hace sin red y con fallos silenciosos, la peor combinación posible. La cuarta: la aplicación está en un momento de presión de producto, y competir por la capacidad del equipo con trabajo invisible siempre pierde y debe perder. La quinta: la motivación real es el desagrado estético con el código antiguo, sentimiento legítimo pero que no es un argumento de negocio ni de ingeniería.

El caso legítimo, y cómo se reconoce

Una lección sobre no migrar sería deshonesta si no describiera con la misma precisión el caso contrario, porque existe y es nítido. Tres condiciones deben cumplirse a la vez, y la conjunción importa: cualquiera de ellas por separado justifica una conversación, no un proyecto.

flowchart TD
A[quiero migrar el estado] --> B[hay dano recurrente y medible]
B -->|no| N1[no migrar y contener]
B -->|si| C[el equipo domina el destino]
C -->|no| N2[aprender primero en algo pequeno]
C -->|si| D[hay pruebas alrededor del estado]
D -->|no| N3[escribir la red antes de mover nada]
D -->|si| E[hay ventana sin presion de producto]
E -->|no| N4[posponer con fecha de revision]
E -->|si| S[migrar por etapas segun este nivel]
style S fill:#a6e3a1,color:#11111b
style N1 fill:#f38ba8,color:#11111b

Falta una condición implícita que el árbol no dibuja porque no es binaria: haber ejecutado antes el paso uno del nivel. Decidir sobre una migración de librería sin haber extraído el estado del servidor es decidir con el inventario equivocado, porque el daño que se atribuye al store incluye entonces todo el sufrimiento de sostener una caché a mano. Ese daño es real, pero su cura no es la que se está proponiendo, y confundirlas lleva a aprobar el proyecto caro para arreglar lo que el barato ya resolvía.

El árbol tiene una propiedad deliberada: casi todas sus ramas terminan en algo que hacer, no en una negativa seca. No migrar no significa quedarse quieto, significa gastar el presupuesto en el eslabón que falta —escribir las pruebas, ganar experiencia con el destino en un proyecto menor, contener el store actual— y volver a recorrer el árbol cuando ese eslabón exista. Un proyecto pospuesto con la condición objetiva escrita al lado es una decisión de ingeniería; uno pospuesto sin condición es simplemente una discusión que se repetirá cada trimestre con los mismos argumentos y ninguna información nueva.