Accelerating Legacy Code Translation in Secure Enclaves

Every defense program and regulated enterprise carries at least one system nobody wants to touch. It runs on Ada, or COBOL, or a dialect of Fortran that predates most of the engineers now responsible for it. It works, which is precisely the problem. It works well enough that rewriting it has never won a budget fight, and poorly enough that every year it keeps running is another year of accreting risk. The people who understood its logic well enough to safely modify it are retiring. The compiler toolchain it depends on is itself a maintenance liability. And the source code, because of what the system does and who built it, cannot be pasted into a cloud model to get help.

That last constraint is usually treated as a footnote to the real problem, the scale of the migration itself. It shouldn't be. For legacy systems in defense, government, and classified-adjacent environments, the data-handling constraint and the technical constraint are the same constraint. A translation effort that requires shipping source fragments to an external API is disqualified before anyone evaluates whether the translation itself would even be any good.

Why legacy translation is a language-model problem now

Language translation, porting working logic from one language to another while preserving behavior, has historically been done by hand, by teams that understood both the old language and the target one, reading routine by routine and reasoning through what each block actually did. It is slow not because the individual translations are hard, but because legacy codebases accumulate implicit behavior: an off-by-one quirk that a downstream routine has silently come to depend on, a comment that describes what the code used to do rather than what it does now, a subroutine called from twelve places with eleven different assumptions about its inputs. Preserving all of that correctly, at scale, is exactly the kind of task where a model that can hold wide context and reason across call graphs earns its keep, reading not just the function being translated but everywhere it's called from, everywhere it calls into, and the surrounding system's actual behavior rather than its stated intent.

That's a meaningfully different job than autocomplete-style code assistance. Translation work needs an assistant that can be pointed at an entire legacy module, asked to explain what it does before being asked to rewrite it, and trusted to flag the parts of the original where behavior is ambiguous rather than silently guessing. It is closer to a research task performed against the whole codebase than a line-by-line suggestion tool. That's also why it tends to be a heavier, more sustained workload than day-to-day coding assistance, the kind of thing worth planning capacity for rather than treating as incidental usage on top of a team's regular assistant traffic.

The part that makes this a sealed-appliance problem, not a tooling choice

Legacy defense and government code is disproportionately likely to be the code that cannot leave a controlled environment in the first place: targeting logic, weapons-adjacent control systems, classified research infrastructure, decades of accumulated institutional logic that was never meant to be portable. That is usually exactly the code most in need of translation, because it is also the code that has been running longest and drifting furthest from any team's current expertise. The organizations most exposed to legacy risk are, structurally, the same organizations for whom a cloud-based translation tool was never a legal or contractual option to begin with.

That leaves two real paths: keep doing it by hand at the pace hand-translation allows, accepting the compounding risk of an aging system nobody fully understands, or bring an AI-assisted translation workflow inside the same boundary the source code already lives behind. Forge exists for exactly that second path. It's a sealed appliance where the model, the retrieval layer, and the repository index all run inside the enclave, so asking an assistant to reason across an entire legacy system doesn't require deciding whether any of that system is allowed to leave the building first.

What actually accelerates, and what doesn't

The speedup in a workflow like this doesn't come from the model "knowing" the target language better than a senior engineer does. It comes from collapsing the two slowest parts of manual translation, comprehension and drafting, into a single pass that a human then reviews, rather than two sequential slow passes done entirely by hand.

Comprehension is usually the larger cost. A translator who doesn't yet understand a legacy routine has to read it, trace its callers, check for side effects, and often go find whoever last touched it. An assistant with the full repository indexed can surface that context immediately: every call site, every related routine, the commit history where behavior last changed. That turns "go figure out what this actually does" from a multi-hour archaeology exercise into a starting point a reviewer can quickly confirm or correct. Drafting a first-pass translation is the second cost, and it's the more mechanical of the two: producing idiomatic code in the target language that mirrors the original's behavior, including its edge cases, so the reviewing engineer is validating and refining rather than writing from a blank file.

What doesn't get faster, and shouldn't, is verification. Legacy systems in these environments typically carry consequences that make "the tests pass" an insufficient bar. Behavioral equivalence has to be established deliberately, often against the original system running side by side, not inferred from a translated diff looking plausible. A translation workflow built on Forge is meant to compress the comprehension-and-drafting loop, not to compress the review discipline around it. Treating the two as separable is what keeps this an acceleration of engineering judgment rather than a replacement for it.

Working a codebase, not a snippet

The practical shape of this workflow looks different from typical coding-assistant usage. Rather than short, interactive completions scattered across a normal workday, legacy translation tends to run as sustained, directed sessions against specific modules: an engineer working through a subsystem over days or weeks, holding a large amount of source and its call graph in active context the whole time. That has real implications for how a Forge deployment supporting this kind of work should be sized and scheduled. Session context for a translation effort needs to stay resident and warm for far longer than a typical interactive coding session, and the retrieval layer needs to comfortably index a legacy codebase's full scope rather than just the files a developer happens to have open.

None of that changes Forge's underlying architecture. It is the same sealed appliance, the same on-enclave model and retrieval stack that serves day-to-day coding assistance. What changes is the usage pattern it needs to support well, and that's a planning conversation worth having explicitly before a translation effort starts, rather than discovering mid-project that a workload shaped like sustained research doesn't fit a deployment sized for quick completions.

The system that shouldn't be touched becomes the system that finally can be

The organizations carrying the oldest, riskiest legacy systems have historically faced a bad tradeoff: modernize slowly by hand, or accept a security posture their contractual and regulatory obligations don't actually allow in order to modernize faster. A sealed appliance built for exactly this class of work removes the tradeoff rather than negotiating a compromise within it. The code never has to leave the boundary it was already required to stay inside, and the translation effort gets an assistant capable of reasoning across the whole system rather than one file at a time. That is, in the end, the only way a legacy system this size and this sensitive was ever going to get modernized without simply accepting the risk of leaving it alone.