Most articles about migrating from C++ to Rust are written for engineers who’ve already decided. This one is for anyone who still needs to convince a board — or hasn’t worked out whether the cost is worth it yet.
Microsoft, Google, and AWS are all moving away from C++ for the same reason. Memory-safety vulnerabilities are a structural cost, not a temporary problem. The broader industry shift toward memory-safe software is reshaping how technology organisations think about long-term security risk.
And yet there’s almost no worked TCO framework calibrated to a 50–500 employee SaaS, FinTech, or HealthTech company. Most content offers generic frameworks with no real numbers, or enterprise-scale examples that don’t apply. This article fills that gap: a worked TCO model with explicit numerical assumptions, a migration sequencing approach grounded in real case studies, FFI boundary guidance, a hire-versus-train framework, and a board-ready business case structure. Incremental adoption is the only viable approach — and the data backs it up.
Why Is a Rust Business Case Different from a Typical Technology Migration?
Most technology migrations swap one tool for another. A C++-to-Rust migration changes the memory model of the codebase — that’s a structural safety change, not a tooling upgrade. The primary benefit is a reduction in a class of vulnerabilities that are invisible until they become incidents, not a performance improvement that shows up in a dashboard.
The right frame is risk-adjusted cost avoidance. Standard ROI frameworks measuring build times or cloud costs don’t capture it.
Memory safety as a business concept
About 70% of the CVEs Microsoft assigns each year are memory-safety issues in C and C++ code. Google reports the same for Chrome and Android. The vulnerability classes involved — buffer overflow, use-after-free, null pointer dereference, and data race — simply cannot exist in safe Rust. That’s not a marginal improvement; it eliminates an entire category of attack surface.
For boards, the question is concrete: what does it cost to keep maintaining a codebase where this class of vulnerability remains possible?
The regulatory pressure argument
CISA and the NSA have jointly recommended transitioning away from C and C++ to memory-safe languages. The White House’s National Cybersecurity Strategy reinforces this. The strategic case Microsoft is making for Rust is about aligning with where regulators are headed, not performance.
Continuing to maintain a C++ codebase is not a neutral default. It is an active choice to accept memory-safety vulnerability risk — and the regulatory cost of that choice is rising.
What Should a Rust Migration TCO Model Actually Include?
A Rust migration TCO model has four cost inputs and one primary benefit input. Most models include only the costs and ignore risk-adjusted benefits — and that’s the most common reason migration business cases fail to get board approval.
Cost inputs:
- Training cost per developer (productivity ramp during onboarding)
- Talent premium for Rust-experienced hires (recurring annual cost)
- Ongoing supply chain governance overhead (cargo-deny, cargo-audit, SBOM maintenance)
- FFI boundary engineering cost during incremental migration
Benefit input: Security breach cost avoidance, quantified using Google’s 1,000x vulnerability density reduction as the primary calibration input.
The TCO model in detail
The figures below are illustrative, calibrated to a 50–500 employee company. These are stated assumptions, not industry standards. Adjust for your actual salary bands, team size, and incident history.
Training cost per developer — 4 months at 30% reduced productivity, $150k/year salary: approximately $15,000 per developer.
Talent premium (Rust hire vs C++/Go hire) — approximately $25,000 above market annually, recurring per Rust specialist hired.
Supply chain governance overhead — 0.25–0.5 FTE-equivalent ongoing: approximately $25,000–$50,000/year at $100k loaded cost.
FFI boundary engineering (per integration point) — 2–4 weeks of senior engineer time: approximately $10,000–$20,000 per FFI boundary.
Security breach cost avoidance — range of $50,000–$5M+ depending on incident history (see the worked calculation below).
One thing most TCO models get wrong: treating training as a one-time cost when it actually recurs with every new hire, ignoring ongoing governance overhead, and leaving out FFI engineering cost entirely.
ClickHouse — covered in the enterprise case studies that ground the TCO model — remains 98% C++ after years of active adoption. The TCO needs a five-year horizon: costs are front-loaded, benefits accrue over years.
How Do You Quantify the Security Benefit Using the Google 1000x Stat Honestly?
Google reduced memory-safety vulnerability density in Android from ~1,000 vulnerabilities per million lines of C/C++ to ~0.2 per million lines of Rust — more than 1,000x. Memory-safety bugs dropped from over 75% of total Android vulnerabilities to under 20% in four years.
Derive a vulnerability reduction rate from Google’s data, apply it to your historical incident frequency, and multiply by your average incident cost. The result is a range, not a guarantee.
Worked calculation (illustrative, stated assumptions):
Step 1 — Estimate what percentage of your historical incidents involved memory-safety bug classes. Industry average is 70%. Audit for use-after-free, buffer overflow, null pointer dereference, and race condition root causes.
Step 2 — Apply a conservative reduction rate, not the full 1,000x. For a 50-person team in year one: conservative (50x), base case (100x), optimistic (500x).
Step 3 — Estimate incident cost. A single critical incident typically costs $50,000–$500,000 factoring in engineer time, opportunity cost, and SLA credits. A serious breach can reach $5M+.
Step 4 — Multiply and present as a range. Example: one major memory-related incident per quarter at $100,000 average cost is $400,000/year. A conservative 50x reduction applied to the 70% memory-safety proportion implies ~$280,000 in expected annual saving. Present this with stated confidence levels, not as a projected saving.
For FinTech and HealthTech, add a separate line for regulatory fine risk — notification obligations and potential fines are a distinct input.
How Long Does It Really Take to Train a C++ Developer to Write Production Rust?
The consistent number across sources is 4–6 months for a C++ developer to reach production Rust productivity. This is not syntax familiarity — that takes weeks. It’s the time needed to internalise Rust’s ownership and borrowing model to the point where the borrow checker stops being a friction point.
Abstract training alone has poor retention. Pair Rust learning with a low-criticality real project from the start. The team learns toolchain, FFI patterns, and idioms in a context that actually matters to the business.
The 4–6 month ramp is the largest single cost input in the TCO model. At 30% reduced productivity for a developer earning $150,000/year: approximately $15,000 per developer. A team of 10 costs approximately $150,000 in productivity to onboard. Don’t start a migration during crunch time — the productivity dip is real and predictable, so schedule it.
Full idiomatic Rust fluency takes 12 months or more. The 4–6 month figure is the threshold for shipping production code, not for writing elegant Rust.
Should You Train Existing Engineers or Hire Rust Specialists?
If your team is primarily C++ engineers, training them is the more reliable path. Rust specialists are scarce, they command approximately $25,000 above market rate, and they’re a flight risk.
Train path: One-time ramp cost (~$15,000 per developer); permanent capability gain; no recurring premium; engineers understand the existing codebase.
Hire path: Recruiting cost plus ongoing salary premium; attrition risk takes Rust expertise with it; hired engineers need time to learn your domain.
According to JetBrains‘ 2026 State of Developer Ecosystem survey, 26% of developers use Rust professionally — but senior engineers with production C++ migration experience are rare. Most candidates have hobby or side-project experience, not production systems experience.
The practical recommendation: identify 2–3 internal engineers interested in Rust, invest in them first, let them lead the pilot, and use the productivity data from your own organisation for the board case. That’s a stronger input than industry averages.
If no one on your team will champion Rust adoption, hiring one senior Rust engineer as a migration lead can seed the programme. That is a specialist hire, not a full-team strategy.
How Do You Sequence a C++ to Rust Migration Without Derailing Your Engineering Team?
The universal approach across every successful real-world C++/Rust migration is incremental adoption, not a big-bang rewrite. ClickHouse, Google, Meta, and Discord all used this approach — and ClickHouse remains 98% C++ after years of active adoption. That’s your calibration anchor.
The beachhead sequencing pattern:
- Identify a new, isolated, low-criticality component as the Rust beachhead — a new feature or service with minimal interface to the rest of the codebase, not a replacement for existing functionality
- Integrate via FFI/Corrosion — keep the unsafe surface minimal
- Validate with sanitisers and fuzzing before deploying to production
- Expand based on results — measure actual outcomes before committing to the next component
What makes a good first component: it is new (a failure does not break production), isolated (fewer FFI crossings), low-criticality (absorbs the learning-curve impact), and measurable (you need a concrete outcome for the board).
The ClickHouse example
ClickHouse — an open-source analytic database with 1.5 million lines of code — integrated delta-kernel-rs as their first production Rust library. The CTO: “We did not rewrite ClickHouse in Rust. We just opened the door for Rust.”
It was not a smooth journey. ClickHouse went from 156 C++ dependencies to managing an additional 672 transitive Rust dependencies. A memory sanitiser incompatibility appeared two days before a FOSDEM 2026 talk. “This and the entire project required a huge amount of effort. It was not easy.” Plan for this. It’s the difference between a successful pilot and a derailed programme.
The strangler fig pattern — replacing modules one by one while old and new run side by side — is the lowest-risk approach for teams that need to keep shipping. AI-assisted translation as a future cost modifier is worth noting in long-range roadmaps, but for current planning, assume manual migration.
What Does Managing the FFI Boundary Actually Cost?
Every integration point between C++ and Rust requires an FFI (Foreign Function Interface) boundary — a crossing point where Rust’s memory safety guarantees cannot be enforced automatically, marked with the unsafe keyword. The goal is a minimal unsafe surface: fewer FFI crossings, tighter interface contracts at each crossing, and more of your code stays under Rust’s safety guarantees.
For CMake-based C++ projects, Corrosion is the practical starting point — an open-source CMake integration tool that lets Rust libraries be compiled and linked into a C++ project without rewriting the build system. ClickHouse uses it in production.
What Corrosion does not solve: sanitiser integration, dependency management, or the SBOM growth from transitive Rust dependencies.
Integrating a single Rust library took ClickHouse from 156 to approximately 828 total dependencies. Each dependency is a supply chain audit obligation — and in regulated environments, a compliance event.
Budget estimate: 2–4 weeks of senior engineer time per FFI boundary, plus ongoing maintenance. Include this in the TCO model. See Rust supply chain governance as a migration cost for the governance obligations in detail.
How Do You Account for Supply Chain Governance in the Migration Budget?
Rust’s supply chain governance is an ongoing operational cost, not a one-time setup. Every crate you add is a supply chain obligation.
cargo-audit checks dependencies against the RustSec advisory database. cargo-deny enforces licence policies, detects duplicates, and bans problematic crates. Both need to run continuously — the advisory database is not static, and flagged crate decisions are human work, not automated work.
Rust’s supply chain is more manageable than npm or PyPI: static linking by default, reproducible builds via Cargo.lock. But it’s not immune — in December 2025, two malicious crates were found on crates.io attempting data exfiltration. cargo-deny and cargo-audit are the detection layer for exactly this.
For FinTech and HealthTech, SBOM maintenance is a compliance obligation. The EU Cyber Resilience Act and US Executive Order 14028 have both cemented SBOM requirements. ClickHouse’s 156 to ~828 dependency growth is not just a build system event — it’s a compliance event.
Budget: 0.25–0.5 FTE-equivalent of ongoing engineering time, recurring line item in the TCO model. See compliance requirements for regulated environments for sector-specific detail.
How Do You Build a Board-Ready Business Case Document?
A board-ready Rust migration business case has four components:
- The regulatory risk narrative — CISA/NSA guidance as the cost-of-inaction argument
- The TCO model with explicit assumptions — the worked calculation, not a generic framework
- The migration roadmap with realistic timelines calibrated to real case studies
- The recommendation with a clear ask — typically a funded pilot, not a full migration approval
The frame that works at board level is risk-adjusted cost avoidance. Boards approve spend to reduce risk. Quantify the risk; quantify the expected reduction; present the cost to achieve it.
Executive Summary: The risk you’re managing, the cost of inaction, the expected ROI horizon, and the ask.
Regulatory and Risk Context: CISA/NSA guidance; relevant incidents; the direction of regulatory travel in your sector.
TCO Model: The four cost inputs plus the security breach cost avoidance calculation, with all assumptions stated. Use conservative figures — it has to survive a CFO’s scrutiny.
Migration Roadmap: Phase 1 pilot (6 months, one component, defined success criteria); Phase 2 expansion (12–24 months, 3–5 components); Phase 3 programme (2–5 years, measured against annual security metrics). Anchor timelines to ClickHouse: 98% C++ after years of active adoption. Underpromise. The business case survives a slow migration; it does not survive a missed deadline.
The ask: “Fund a six-month pilot with one team, one component, and a defined success criterion.” That is the structure that gets approval from risk-averse boards.
Don’t include technical arguments about ownership and borrowing — save those for the engineering team. Don’t base current numbers on AI-assisted translation tools that are not yet externally available. Frame the cost of inaction directly: “Regulators are moving in one direction.”
The broader industry shift toward memory-safe software is the strategic backing for every section of the TCO model. For a deeper look at ecosystem stability as a long-term risk input, the governance and maturity analysis reinforces the business case at every stage.
FAQ
How long does a typical incremental Rust migration take?
ClickHouse is the calibration anchor: after several years of active adoption, 98% of the codebase remains C++. Incremental migration is measured in years, not quarters. For a 50–500 employee team: pilot in production within 6–12 months; 5–10% of new code in Rust after 2–3 years; meaningful reduction in memory-safety incidents after 3–5 years. The right question is not “how long until we finish?” but “how long until we see measurable security benefit?” — about 2–3 years for teams starting with security-critical new components.
What is a realistic budget for training a team of 10 engineers to write production Rust?
At 30% reduced productivity for 4 months at $150,000/year: approximately $15,000 per developer. For a team of 10: approximately $150,000 in training cost (productivity ramp only; does not include course fees or pair-programming time with external Rust expertise). Adjust for your actual salary band.
At what company size does a full-time Rust migration programme make sense?
50–100 employees: a dedicated pilot with 1–2 engineers makes sense; a full programme does not. 100–250 employees: a structured 3–5 engineer migration team with a multi-year roadmap is viable. 250–500 employees: a full programme with dedicated Rust advocates and internal training infrastructure is justified. Below 50 employees: the cost likely outweighs the benefit unless the product is highly security-critical or in a regulated environment.
What is the difference between a full rewrite and incremental adoption — and why does it matter?
A full rewrite discards the existing C++ codebase and rebuilds from scratch. Most organisations that attempt it do not survive — approximately 30% success rate, typically costing 2–3x more than planned. Incremental adoption integrates Rust into specific components while C++ stays in place everywhere else. ClickHouse, Google, Meta, and Discord all used this approach; the existing product never stops shipping. For teams of this scale, incremental adoption is not a compromise — it is the only viable approach.
What is FFI and why does it make incremental migration complex?
FFI (Foreign Function Interface) is the mechanism that lets Rust and C++ call each other. Every FFI crossing requires an unsafe block — where Rust’s compile-time guarantees are suspended. The complexity is in the downstream effects: transitive dependencies multiply (ClickHouse: 156 → ~828 total), sanitiser integration becomes harder, and build system changes are required.
What is Corrosion and why is it relevant for C++ projects?
Corrosion is an open-source CMake integration tool that lets Rust libraries compile and link into a C++ project using the existing build system. Without it, you need significant build system rework. ClickHouse uses it in production. For any C++ team on CMake, Corrosion is the practical starting point.
Is AI-assisted translation a viable option for our migration now?
Not yet for external teams. Microsoft CoreAI’s infrastructure is an internal research project as of 2026. Note it in multi-year roadmaps as a potential future cost modifier, but assume manual migration for current planning. See AI-assisted translation as a future cost modifier for the current state of the technology.
How do we handle the supply chain risk that comes with adding Rust crates?
Use cargo-deny to enforce licence policies and ban known-problematic crates; use cargo-audit to check the RustSec advisory database on every CI run. For regulated environments, generate an SBOM for every Rust component and maintain it as a compliance artefact. See Rust supply chain governance as a migration cost for the full framework.
What percentage of our C/C++ vulnerabilities are likely to be memory-safety-class bugs?
Industry-wide data consistently cites approximately 70%. Audit your own incident history for use-after-free, buffer overflow, null pointer dereference, and race condition root causes. If your proportion matches the average, this is a strong TCO input. If it doesn’t, lean more heavily on the regulatory risk argument.
What does CISA/NSA guidance mean for regulated-sector teams specifically?
CISA and the NSA recommend transitioning from C and C++ to memory-safe languages. For FinTech teams subject to US federal regulation: memory-safe adoption is moving from recommendation to procurement criterion. For HealthTech: IEC 62304 does not yet mandate Rust, but CISA guidance creates regulatory risk for teams shipping C++ where memory-safety vulnerabilities could affect patient safety. See compliance requirements for regulated environments for sector-specific detail.
Should we use a decision tree to decide whether to start a migration?
Yes. Five questions: (1) Is the product lifetime 10+ years? If no, ROI is hard to justify. (2) Is the codebase primarily C++? If no, FFI cost is higher and benefit smaller. (3) Does the product handle sensitive data or operate in a regulated environment? If yes, the regulatory argument strengthens significantly. (4) Is there at least one internal engineer enthusiastic about Rust? If no, fix the culture problem first. (5) Is there an isolated new component for a pilot? If no, wait until one exists rather than starting with a rewrite.
