Migrating Legacy Like a North Star Engineer

Microsoft wishes to get rid of a billion lines of C/C++ code. They target a rewrite to Rust by 2030, according to a recently posted job ad. Betting on AI, their “North Star” is:

1 engineer, 1 month, 1 million lines of code.

I admire the bold ambition, turning legacy modernization into the pinnacle of engineering excellence.

It also dangerously naive to suggest that thanks to AI a few engineers can modernize a multi-million line code base in a matter of months. I know too many board members (in government, finance, and other sectors) who would love to believe this suggestion. Legacy is their main headache. What can be more tempting than just waiting a little until the North Star Engineer emerges? And, lo and behold, there will even be vendors promising they can deliver exactly such engineers, together with tools powered by AI magic.

For board members contemplating to await this north star revolution, here is some advice on things to do without delay:

  1. Disentangle the legacy landscape. Break dependencies. Ensure the legacy system can be modernized incrementally, component by component.
  2. Invest in domain knowledge and deep understanding of the desired behavior. Ensure any discrepancies between old and new functionality can be interpreted correctly.
  3. Invest in an idiomatic, uniform code base. The less variability, the easier any (automated) translation will be.
  4. Invest in testing. Boost the automated test suites so that they exercise all key business logic. As the legacy system delivers mostly correct functionality, use it to (automatically) derive test suites achieving high coverage (which can subsequently be used to test migrated components).
  5. Bring the legacy system in a state in which it is possible to deploy old and new versions of a component in parallel, and results can be compared.

None of these steps do any actual translation. They are, however, the starting point from which translation can be attempted. They bring the legacy system in a more manageable state, in which the risks of the migration can be mitigated by an incremental approach focused on gradual replacement and continuous feedback on correctness.

For some of these steps, program analysis tools and modern AI may help. But there are no free lunches. Each of the steps requires a substantial investment of effort and resources.

It is safe to assume that Microsoft is well aware of the need for these steps. What’s more, their systems are likely in relatively good starting position, with high levels of automated testing in place already. But even then, for automated translation to work substantial additional investments will be necessary.

This brings us back to the board members of ‘normal’ legacy-owning organizations.
Perhaps Microsoft can pull off some North Star Engineering magic. But for the legacy code that runs our taxes, payments and social security, it won’t make a difference. The legacy systems that run our society need continuous attention and investment, starting now, to ensure they stay ready for the decades ahead.


The Original Post

Galen Hunt, December 20, 2025.

I have an open position in my team for a IC5 Principal Software Engineer. The position is in-person in Redmond.

My goal is to eliminate every line of C and C++ from Microsoft by 2030. Our strategy is to combine AI and Algorithms to rewrite Microsoft’s largest codebases. Our North Star is “1 engineer, 1 month, 1 million lines of code”. To accomplish this previously unimaginable task, we’ve built a powerful code processing infrastructure. Our algorithmic infrastructure creates a scalable graph over source code at scale. Our AI processing infrastructure then enables us to apply AI agents, guided by algorithms, to make code modifications at scale. The core of this infrastructure is already operating at scale on problems such as code understanding.

The purpose of this Principal Software Engineer role is to help us evolve and augment our infrastructure to enable translating Microsoft’s largest C and C++ systems to Rust. A critical requirement for this role is experience building production quality systems-level code in Rust—preferably at least 3 years of experience writing systems-level code in Rust. Compiler, database, or OS implementation experience is highly desired. While compiler implementation experience is not required to apply, the willingness to acquire that experience in our team is required.

Our team is driven by a growth mindset. We are diverse team with a wide range of skills and perspectives. We take on bold risks. We work and play well with others. We love to bring value to internal and external customers. We have learned that our diversity and growth mindset is critical to success in the rapidly changing word of AI-based tools.

Our team is part of the Future of Scalable Software Engineering group in the EngHorizons organization in Microsoft CoreAI. Our mission is to build capabilities to allow Microsoft and our customers to eliminate technical debt at scale. We pioneer new tools and techniques with internal customers and partners, and then work with other product groups to deploy those capabilities at scale across Microsoft and across the industry.


Four days after posting, Galen Hunt placed an update:

Update:
It appears my post generated far more attention than I intended… with a lot of speculative reading between the lines.

Just to clarify… Windows is NOT being rewritten in Rust with AI.

My team’s project is a research project. We are building tech to make migration from language to language possible. The intent of my post was to find like-minded engineers to join us on the next stage of this multi-year endeavor—not to set a new strategy for Windows 11+ or to imply that Rust is an endpoint.