A diagnostic for teams running PHP, Node, Java, C++ or Python in production: the conditions under which we would recommend a Rust migration, and the ones under which we would tell you to keep what you have.
Most migration conversations start from the wrong end. Someone has read about a language, and the question becomes how fast the estate can move to it. We start from the other end: what is hurting, where, and whether the language is the cause.
This is how we sort that out in a first conversation. Five signs that a Rust core is worth planning. Then three signs that it is not, written with the same care, because the second list saves more money than the first.
Five signs a Rust core is worth planning
1. A Java or C# service has a cost that has become structural. Licensing, memory or latency: any of the three. The word that matters is structural. If the cost came back after the last round of tuning, and the round before that, the service has told you something about its ceiling. This is one of the source-to-target pairs we list as migrating well.
2. A Node.js service has throughput or memory problems that persist. A service that needs more instances each quarter to carry the same work is a candidate. We would still look at the design first. But when the design is sound and the numbers keep climbing, we start mapping.
3. A C or C++ component has a history of memory-safety incidents. The history is the sign, not the language. If a component has produced incidents and everyone on the team knows which file to dread, it belongs on the list. We rank such components by risk, value and coupling.
4. A Python pipeline is slow because of Python itself. Data and inference pipelines are on our list of what migrates well, with one condition: Python must be the bottleneck. If the time goes into a database call or a model, rewriting the wrapper changes nothing.
5. A PHP monolith has become a place where change is frightening. Laravel, Symfony or something older. The route we recommend is not a rewrite. We place new Rust services behind an API gateway, beside the old code, and move one capability at a time. If nobody on your team can say with confidence what the monolith contains or who consumes it, that is a reason to begin with a map, whatever you decide next.
A migration advances only when old and new agree on real production traffic.
That sentence is our rule, not a slogan. It is also the reason these five signs are worth acting on: cut-over happens one service at a time, behind a switch that can be reversed in seconds.
What the method looks like once a sign is confirmed
We map every service, dependency, data flow and consumer. Most organizations find systems they had forgotten. We sequence by risk, value and coupling. The first migration is chosen to prove the method, not to be heroic.
The new Rust service runs beside the old one and receives mirrored traffic. Results are compared automatically, and the migration moves forward only when the two agree on production traffic, for as long as that takes. Cut-over happens behind a switch that can be reversed in seconds. Then we decommission the old service, complete the documentation and train your team.
Three signs you do not need it
1. The system is small and the stakes are low. A reporting tool used by four people in finance stays in PHP. We say this on our own service page and we mean it. The migration would cost more attention than the tool will ever return, and your team would inherit a second language to maintain for a screen four people open. If a system fails quietly, is fixed in an afternoon and has a handful of users, leave it alone.
Note the contrast we draw on that page: a payment path handling your revenue does not stay put by default. Size of the user group is not the test. Cost of failure is.
2. You cannot name the limit that is hurting you. If the complaint is that the system feels old, or that the team would enjoy a newer stack, that is not a reason we will take money for. We would want to see a number: a memory ceiling, a latency figure, a licensing line, an incident log. If those numbers do not exist, the first piece of work is measurement, and it may end with a finding that the cause is a query, a design decision or a missing cache. In that case the right answer is a fix inside the current language, and we will say so.
3. You want a rewrite with a date, not a migration with a proof. Our practice is service by service, with old and new running side by side until the numbers match. That takes the time it takes. If the real requirement is that everything must be off the old system by a fixed day regardless of whether the new one agrees with the old, we are the wrong firm, and we would rather tell you in the first call than in month four. The same applies if you cannot give us production traffic to compare against. Parity verification needs real traffic, and without it we have nothing honest to measure.
How to use this list
Count honestly. If you recognize two or more of the first five and none of the last three, a migration plan is a reasonable next step. If you recognize one of the first five and one of the last three, you have a single service to examine, not an estate to move. If you recognize only the last three, close this page and spend the money elsewhere.
The first conversation is thirty minutes with our founder, not a sales team, and an engineer joins if the question is technical. If we are not the right fit we say so and, where we can, point you to people we trust. If you proceed, discovery runs two to four weeks and ends in an architecture document and a costed plan, both yours to keep whether or not you go on. The system map we produce in week two is where the conversation about what should not move takes place. We consider it the most valuable document of the engagement.
If you recognize two or more of the first five signs, go to Start a Project and answer the six questions, including what a bad deploy costs you. We reply within two working days, and if the answer is that nothing should move, we will say that.
This article was drafted by SKYLOGIQ's editorial pipeline from the firm's own pages and checked by an AI fact-checking editor, with a human review queue for anything the editor refuses. How the Briefing is made