When I lead a framework migration, whether to bring in TypeScript is almost never the first question I get asked — but it should be. Migrating without types means migrating blind: every large refactor introduces errors that only surface in production, exactly when you least want to find them.
Types reveal what the code hides
An untyped component looks fine until a change in a data shape silently breaks three unrelated screens. TypeScript turns that kind of failure into a compile-time error, visible before you ever commit. In a migration, where large parts of the codebase get touched, that difference is what separates a calm release from one full of surprises.
You don't need to type everything at once
The strategy that has worked best for me is typing the data layer first: domain models and API responses. Once those types exist, the components consuming them inherit type safety almost for free, and the rest of the migration becomes incremental instead of a full rewrite.
The real cost is organizational, not technical
Adopting TypeScript during a migration costs less development time than it costs team agreement: how strict the typing should be, how much temporary any is tolerable, and who reviews those decisions. Settling that before writing the first type saves more arguments than any tsconfig setting ever will.
In the end, the reason to bring TypeScript into a migration isn't a technical preference — it's reducing the margin for error at the exact moment in a project when the most code surface changes at once.