What a Durable Migration Portfolio Looks Like

Memory-safety migration is durable only when it connects a safer programming model to the system around it. The final question is not whether an organization can announce a preferred language or generate a large volume of translated code. It is whether the organization can reduce a consequential failure surface, preserve the behavior that other components depend on, validate the new boundary, and keep improving while legacy risk remains. The evidence supports a conditional portfolio: safer defaults for suitable new work, targeted attention to high-risk legacy components, explicit interfaces and dependencies, governed translation assistance, and controls for the risks that language choice cannot remove.

One objective, several lanes

The objective of the portfolio is not “rewrite the codebase.” It is to reduce memory-safety exposure in a way that remains maintainable under real delivery pressure. That objective has a technical core: bounds, type, lifetime, initialization, and concurrency rules can prevent or reject important classes of invalid memory use. It also has a system condition: those guarantees apply only within the language model and the boundaries that preserve its assumptions. A safe component connected to an opaque dependency through an ambiguous interface is not the same thing as a safe system.

This distinction makes language choice a means rather than the portfolio’s definition. The government guidance describes memory-safe languages as a way to shift part of the safety burden from individual discipline and after-the-fact analysis into language rules, compilers, libraries, and runtimes. That is a major change in the failure surface. It can make a use-after-free or an out-of-bounds access harder to express, expose an invalid state earlier, and reduce recurring debugging and reliability work. But it does not decide whether the component’s logic is correct, whether a dependency is trustworthy, or whether a service handles a rejected input safely.

A durable program therefore needs distinct work lanes.

The new-code lane prevents accumulation. Suitable new projects and components should start under a memory-safe default when the language, libraries, performance characteristics, and team capability fit the job. This is the lane Android made central when it prioritized Rust and Java for new development rather than attempting a wholesale rewrite. The guidance reports a decline in the share of Android vulnerabilities attributed to memory safety from 76% in 2019 to 24% in 2024. That case supports the value of changing the inflow of new exposure, while its limits remain important: the figures are reported through the guidance, and they show an association with a broader strategy rather than proving that language choice alone caused the entire change.

The high-risk legacy lane reduces concentrated exposure. New-code adoption does not repair a network-facing service, parser, codec, or cryptographic component that is already deployed. Those areas deserve attention when their attack surface or operational consequence is high, even if they are difficult to isolate. The right target is not automatically the smallest module. It is the responsibility whose risk matters and whose behavior can be understood well enough to replace, isolate, or harden without creating a larger failure.

The interface and dependency lane makes mixed operation governable. A memory-safe component may need to call older code, convert data, share state, or rely on a library developed under a different safety model. The boundary must define what crosses it, who owns the data, how long it remains valid, what happens when the receiver rejects it, and what performance cost the conversion adds. Dependency review and version discipline are part of this lane because a new language does not make an external library safe by association.

The validation and capability lane keeps the first three lanes honest. A new component must preserve the behavior its callers rely on, handle malformed inputs and resource pressure, meet operational expectations, and remain observable after deployment. Teams need training, tooling, maintainers, and review practices that fit the component’s actual work. A safety property that nobody can debug or maintain under release pressure is weaker in practice than it appears in a design document.

The fallback lane manages what cannot yet move.