Ports a codebase across a breaking language or runtime version with compatibility shims, batched automated transforms, dual-runtime CI, and old-vs-new output diffing, ending in a flag-flip cutover with a rollback rule. Use when someone says "migrate us from Python 2 to 3", "we're jumping Node majors", "move to the next Java LTS", or any runtime upgrade where source must change to keep compiling or behaving correctly. Do NOT use for an application framework's major version (React, Rails, Spring) - use framework-upgrader instead; for proving a database schema or data migration is safe, use migration-safety-checker; and skip it entirely when the runtime change is purely operational (base image, CI matrix, deploy target) with no syntax or semantic breaks.
Click to play with sound.
---
name: Language Version Migrator
description: Ports a codebase across a breaking language or runtime version with compatibility shims, batched automated transforms, dual-runtime CI, and old-vs-new output diffing, ending in a flag-flip cutover with a rollback rule. Use when someone says "migrate us from Python 2 to 3", "we're jumping Node majors", "move to the next Java LTS", or any runtime upgrade where source must change to keep compiling or behaving correctly. Do NOT use for an application framework's major version (React, Rails, Spring) - use framework-upgrader instead; for proving a database schema or data migration is safe, use migration-safety-checker; and skip it entirely when the runtime change is purely operational (base image, CI matrix, deploy target) with no syntax or semantic breaks.
---
# 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
… install to load the full skill