Migration (Stage 3)

Migration translates each unit in the approved plan from the source language to the target language using AI with language-pair-specific idiom mappings, dependency context, and knowledge base lookups.

Migration unlocks after you click Approve Plan → in Stage 2.

Translation Loop

For each unit, the IDE runs a 5-step loop:

1. Context assembly — resolves inlined dependencies (copybooks, headers, imports) and loads the knowledge base context for the unit (type mappings, naming decisions, rule interpretations)
2. Prompt build — constructs the LLM prompt with XML-tagged source, context, and output format instructions
3. LLM call — sends to the configured model (uses the Checks model if configured, falls back to Chat)
4. Parse — extracts translated output from <translation>...</translation> and metadata from <metadata>{...}</metadata> response tags using 4 extraction strategies with a lenient JSON fallback
5. Verify — runs 8 verification checks; blockers halt the unit, warnings are surfaced for review

Verification Checks

Language Pair Profiles

The translation engine selects a language pair profile based on the session's migration pattern. Profiles define idiom mappings, type equivalences, and naming conventions.

Supported Profiles

A generic profile applies when no specific profile matches the language pair.

Idiom Mapping Example (COBOL → Java)

Context Budget

The translation context is assembled with a 6-priority budget (trimmed if context exceeds the model's limit):

Human Decisions

The translation model raises decisions when it encounters a construct that requires human input. Decisions are either blocking or non-blocking.

Decision Types

Blocking decisions halt the unit and must be resolved before re-translation. Non-blocking decisions are surfaced as annotations on the translated output.

Resolved decisions are stored in the knowledge base and automatically applied to future units with the same construct.

Re-translating a Unit

You can re-translate any unit at any time:

• Click Re-translate to run with default settings
• Provide custom instructions to guide the model on specific constructs
• Re-translation creates a new version; the previous version is preserved in the unit history

Approving a Unit

After reviewing the translated output:

• Approve — marks the unit as approved and writes its translation to the knowledge base
• Skip — marks as skipped; the unit is excluded from cutover
• Reject — marks as rejected for re-translation

The compliance fingerprint comparison result is shown for each unit:

• ≥90% match: auto-approvable
• 70–89% match: warning, manual review recommended
• <70% match: compliance officer sign-off required

Progress

The migration pane shows:

• Units by phase and status (pending, translating, awaiting-review, approved, skipped, rejected)
• Overall progress percentage
• Critical path units highlighted
• Blocked units with blocker description

---

---