Docs / OUTPUT & MIGRATION
OUTPUT & MIGRATION
Auto Migration
Written and maintained by Hendrik Schneider · Last reviewed · How we check this
Auto Migration closes the loop between finding a cryptographic weakness and fixing it. Instead of producing a migration plan for a human to execute by hand, the engine generates the actual code changes - context-aware, across files, and fully automatic - and presents them as a reviewable diff before anything lands in your repository. Status - planned for Korthex V2. Korthex V1 already supports migration planning and simulation (see the korthex plan create and korthex migrate --dry-run commands). The fully automatic, context-aware execution path described below is on the V2 roadmap. The exact V2 release timeline will be announced separately.
V1 vs. V2 at a Glance
The migration story is staged: V1 helps you understand and rehearse a migration; V2 actually performs it.
| Capability | Korthex V1 | Korthex V2 (planned) |
|---|---|---|
| Generate migration plan from findings | Yes | Yes |
| Estimate impact (files, modules, blast radius) | Yes | Yes |
| Simulate migration (preview changes without writing) | Yes | Yes |
| Context-aware code rewrites (cross-file, dataflow-aware) | No | Yes |
| Apply changes automatically | No | Yes |
| Generate verification tests for changed call sites | No | Yes |
| One-click rollback to pre-migration baseline | No | Yes |
Today: Plan & Simulate (V1)
V1 ships the read-only half of the migration workflow. You can plan, estimate, and dry-run any migration the Scanner identifies - nothing on disk changes until you act on the output yourself. # 1. Run a scan korthex scan . # 2. Generate a migration plan from the latest report korthex plan create # 3. Read the plan back korthex plan list korthex plan view <plan-id> # 4. Preview the changes without writing anything korthex migrate --dry-run The stored plan captures the planned migration in a portable encrypted format you can review, share, or feed into V2's auto-apply pipeline once it ships. Blast-radius estimation lives under its own command rather than under the planner: korthex impact cost , korthex impact roadmap , korthex impact audience , korthex impact compliance and korthex impact executive-summary . There is no migrate impact .
Coming in V2: Context-Aware Auto-Migrate
V2 takes the same .krx plan and executes it. The execution is context-aware : it doesn't blindly find-and-replace, it understands the surrounding code - the algorithm's call graph, the way keys and IVs flow through your modules, the testing patterns you use, and the language-specific idioms of every file it touches. What "context-aware" means Dataflow follows the value. If a deprecated primitive is wrapped inside three layers of utility functions across four files, the migration rewrites all the call sites consistently - not just the one the Scanner flagged. API shape is preserved. When a replacement algorithm has a different parameter list or return shape, the engine adapts call sites so the surrounding code keeps compiling. Language- and framework-idiomatic output. Java migrations follow Java conventions, Go migrations follow Go conventions; framework-specific helpers (Spring Security, Django, ASP.NET Data Protection, ...) are used where applicable. Tests are migrated and generated. Existing tests that exercise the replaced primitive are updated; new verification tests are added where coverage gaps are detected. Imports, dependencies, and config files are reconciled in lockstep with the code changes - nothing is left dangling. The intended workflow The V2 command surface is not designed yet, so no syntax is shown here - an example you could copy would be one you could not run. The intended sequence is: create the plan exactly as in V1, have V2 perform the rewrites against a working copy, then review the generated diff, run your test suite, and accept or revert. Of that sequence only plan creation and the dry-run exist today; execution against a working copy, the review gate, and accept/revert do not. Nothing lands silently. Even with full auto-migration, the default workflow is diff → review → accept . The engine prepares the work; you approve before it touches your main branch. Headless modes for trusted automation pipelines are planned but always opt-in.
Safety Model
An auto-migration tool is only as good as the safety net around it. The V2 design is built on three guarantees: Always reviewable. Every change shows up as a normal diff against your working tree. No hidden writes, no out-of-band edits. Always reversible. The pre-migration baseline is captured in the .krx plan file. A single command rolls every change back. Always tested. The engine compiles the result and runs your test suite before reporting success. If anything fails, the migration is left staged for human inspection rather than committed. Auto Migration will respect the same policy engine ( .kxp files) that governs Scanner: organizational restrictions on permitted algorithms, key sizes, and configurations are honored automatically during code generation.