Language Version Migrator

Port code across a breaking language or runtime version by making it run on both versions first, then flipping the interpreter. The failure this skill prevents is the big-bang migration branch: a months-long fork that cannot merge, cannot ship, and cannot roll back, where the team discovers the semantic breaks (encoding, division, ordering) in production. Dual compatibility turns cutover into a config flip.

Operating procedure

Run the steps in order. Dependencies gate the interpreter, tests gate the transforms, and the transforms gate the cutover - skipping ahead is how migrations stall.

Step 1: Gather inputs

Collect these before planning. Label any estimate as a guess and refine as the inventory lands.

1. Source and target versions, and whether intermediate stops are required (Java 8 to 21 usually staged through 11 and 17; Python 2 to 3 is direct).
2. Codebase size: LOC and module count. This sets the batch count.
3. Test coverage per module. Any module under roughly 60 percent line coverage on migration-affected paths needs characterization tests first (pair with characterization-test-writer).
4. Dependency count and lockfile state. Every dependency needs a compatibility verdict.
5. Deployment shape: one deployable or many services (many services migrate independently - sequence leaf services first).
6. Deadline and any code-freeze windows.

Step 2: Inventory the breaking surface