Cuando lidero una migración de framework, la pregunta de si incorporar TypeScript casi nunca es la primera que me hacen — pero debería serlo. Migrar sin tipado es migrar a ciegas: cada refactor grande introduce errores que solo aparecen en producción, precisamente cuando menos conviene descubrirlos.
El tipado revela lo que el código oculta
Un componente sin tipos parece funcionar hasta que un cambio en la forma de un dato rompe silenciosamente tres pantallas distintas. TypeScript convierte ese tipo de error en un error de compilación, visible antes de hacer commit. En una migración, donde se toca gran parte de la base de código, esa diferencia es la que separa una entrega tranquila de una llena de sorpresas.
No hace falta tipar todo de una vez
La estrategia que mejor me ha funcionado es tipar primero la capa de datos: los modelos de dominio y las respuestas de API. Una vez que esos tipos existen, los componentes que los consumen heredan seguridad de tipos casi gratis, y el resto de la migración se vuelve progresivo en vez de una reescritura total.
El costo real es organizativo, no técnico
Adoptar TypeScript durante una migración no cuesta tiempo de desarrollo tanto como cuesta acuerdo de equipo: decidir qué tan estricto es el tipado, cuánto any se tolera temporalmente, y quién revisa esas decisiones. Resolver eso antes de escribir el primer tipo ahorra más discusiones que cualquier configuración de tsconfig.
Al final, la razón para incorporar TypeScript en una migración no es preferencia técnica, es reducir el margen de error en el momento del proyecto donde más superficie de código cambia a la vez.