Rust Rewrites: What You Should Actually Migrate
Every system is 'rewriting in Rust' these days. Here's a practical framework for deciding what's genuinely worth migrating, and what isn't.
On this page
Somewhere along the way, "rewrite it in Rust" became both a meme and a corporate strategy. There's real substance behind the hype, but there's also a lot of cargo-culting. This is the framework we use when the question comes up.
Related reading: From Monolith to Modules: Modernizing Legacy Codebases · ServiceNow's Stock Fell 27% as AI Fears Came for the Software Trade.
The case for Rust is narrower than the hype
Rust buys you three things that matter: memory safety without a garbage collector, predictable performance, and an excellent toolchain. Those are real, durable advantages for a specific class of software.
But every rewrite has a cost. Rust's learning curve is real. Its compile times are real. Its ecosystem, while growing fast, is not uniformly mature. A rewrite should be a business decision, not a religion.
What's worth migrating
The pattern we see working in production:
- Hot paths that burn money. If a service is consuming a meaningful share of your cloud bill, and profiling says it's CPU-bound, a Rust rewrite can return 3–10x, and pay for itself.
- Memory-heavy services. The GC pauses that are fine in your staging environment are not fine in your billion-request queue.
- Security-sensitive components. Anything that parses untrusted input is a candidate. Memory safety as a default is a genuine advantage for parsers, protocol handlers, and anything on the attack surface.
A concrete example
A payments team we talked to moved their signature-verification service to Rust. The rewrite took four weeks. The service now uses a fifth of the memory and handles three times the throughput.
What's not worth it
- CRUD apps. If your bottleneck is a database and your business logic is ordinary, you are paying for safety you don't need and slowing down feature velocity.
- Greenfield-but-unclear products. If the product is still pivoting weekly, optimize for iteration speed, not asymptotic performance.
- The "we'll rewrite everything" plan. Nobody has successfully rewitten a large system in one shot. The successful projects we've seen always start with one boundary, one service, one hot path.
A decision checklist
Is it CPU-bound or memory-bound? → likely candidate
Does it sit on the attack surface? → strong candidate
Is your team already fluent in Rust? → go
Is the current system stable & legacy? → consider leaving it alone
Is the main pain actually I/O or DB? → stop. Not a Rust problem.
The pragmatic middle
You don't need to go all-in to get most of the benefit. New services in Rust, existing hot paths migrated incrementally, and everything else staying put is a perfectly coherent strategy.
The verdict
Rust is not a silver bullet. It's a precision instrument, powerful, unforgiving, and best deployed where it matters. Treat it that way, and the rewrites that make sense will reveal themselves.
Start small
Pick one bounded service with clear performance or safety wins. Ship it. Measure it. Then decide whether the broader rewrite makes sense. Let data, not dogma, be your guide.
Tags
TPW Editorial
Editorial Team
TechPastWeek's editorial team reports and edits every story we publish. We research each piece against primary and credible secondary sources, and a human editor reviews and signs off before it goes live.
