Tooling migrations are the kind of work that everyone agrees is important but nobody wants to do. They require deep research, careful changes across the codebase, and hours of debugging cryptic errors. High-effort, low-glory tasks that sit at the bottom of the backlog for months.

I recently needed to migrate our TypeScript compiler from tsc to tsgo. In the past, this would have been a multi-day project. Instead, I let Claude Code run in the background while I worked on other things, and the whole migration took a fraction of the time. The tsgo part matters less than what it taught me: working with Claude changes the economics of these projects entirely.

The real cost of migrations isn't the code changes

When I think about why migrations get deprioritized, it's not because the code changes are hard. It's because the research phase is so draining. You have to read documentation, compare feature sets, understand breaking changes, test edge cases, and build enough context to make confident decisions. That research phase is what turns a one-day task into a week-long project.

Our TypeScript compilation was taking 44 seconds in CI, and tsgo promised to bring that down dramatically. But evaluating whether tsgo was production-ready, understanding the migration path, and actually making the changes? That's the kind of work I used to budget 3-4 days for.

Letting Claude run in the background while I do other work

The most valuable part of working with Claude Code on migrations is that it doesn't require my constant attention. I wrote a fairly casual prompt explaining what I wanted to accomplish, pointed Claude at our tsconfig and build setup, and let it work in a separate git worktree while I focused on tasks that actually needed my undivided attention.

This isn't pair programming. It's more like delegating to a colleague who's great at reading documentation and making systematic changes. I'd check in every so often to see how things were progressing or provide some guidance, but mostly Claude just churned through the work on its own. It read the tsgo docs, identified configuration differences, and implemented the migration step by step.

Migrations are mostly mechanical work punctuated by a few critical decisions. Claude handles the mechanical parts while I stay focused on higher-leverage work. When it finishes, I come back and focus my energy on the parts that actually require human judgment.

Pairing with Claude to understand what changed

Once Claude completed the migration, the collaboration shifted to understanding what actually changed. New compilers inevitably surface different type errors, and this is where most of the risk lives in any migration. Are these errors revealing real problems? Are they false positives? Is the new tool being stricter in ways that improve safety, or is it breaking things that worked fine before?

This is where I paired directly with Claude to work through the errors together. Instead of spending hours researching each error type on my own, I could ask Claude to explain what each error meant, why the new compiler was flagging it, and whether it was actually a type safety problem or just a difference in compiler behavior.

For each category of error, I'd cross-check Claude's analysis against regular tsc to make sure the new compiler wasn't being overly strict or missing something important. Claude helped me sort the errors into buckets: ones that pointed to real issues, ones that needed small code updates, and noise I could ignore.

What would have taken me a full day of reading compiler source code and Stack Overflow threads took about an hour of conversation with Claude. I came away with a better understanding of the errors than I would have from a solo research session, because I could ask follow-up questions and pressure-test Claude's explanations in real time.

This changes which projects are worth doing

The tsgo migration brought our TypeScript compilation from 44 seconds down to 7 seconds. That matters for the whole team. But this migration would have sat in our backlog for months if it required 3-4 days of dedicated work. With Claude handling the research and implementation in the background, the actual cost to me was a few hours of review and error analysis spread across two days.

This changes the calculus on which technical improvements are "worth it." Projects that used to get deprioritized because the effort-to-impact ratio was too high suddenly become tractable. Dependency upgrades, compiler migrations, build tool swaps, linter rule changes. All the infrastructure work that makes teams faster but nobody has time for.

The two modes of working with Claude

What I've learned is that Claude is most valuable for migrations in two distinct modes.

In background mode, Claude works autonomously on the research and implementation while you focus on other tasks. This is where you get the time savings. You're not blocked, and neither is Claude. You check in periodically, provide guidance when needed, and let it handle the grunt work.

In pairing mode, you sit down with Claude once the changes are made to understand what happened. You work through the diff together, evaluate risk, understand error messages, and decide what's safe to merge. This is where you get the confidence to ship.

The combination is what made this migration work. I got the speed of not doing the research myself, but I still understood every change before it landed.

If you've got infrastructure work sitting in your backlog, try letting Claude run in the background on one of those projects. The cost might be lower than you think.