The most expensive way to run a porting assessment is to staff the port before the profiling report comes back. Once engineers are allocated, the assessment stops being a decision document and becomes a retroactive justification for a decision that was already made in a planning meeting. That inversion is the failure mode this piece is about, and it has a precise cost: engineer-months spent rewriting code that was never the constraint.
An assessment is decision-grade. A migration design spec is delivery-grade. They are different artefacts with different obligations, and conflating them is what turns a few weeks of measurement into a lost quarter.
What does “a porting assessment is not a rewrite commitment” mean in practice?
It means the assessment has three legitimate outcomes, not one: commit, defer, or do not port at all. If only one of those outcomes is survivable inside your organisation — if a “defer” would embarrass the sponsor who commissioned the work — then the assessment is not measuring anything. It is documenting a foregone conclusion.
In practice the boundary shows up in how the engagement is scoped. A decision-grade assessment profiles the workload on representative inputs, attributes wall-clock time across compute, memory bandwidth, data movement and I/O, and expresses target gains as ranges with the confidence stated. It does not choose a runtime before the numbers exist, and it does not sign off rewrite scope. We treat the moment someone asks for “the migration plan” mid-assessment as a signal that the frame has already slipped.
The divergence point is what happens when profiling says the bottleneck is elsewhere. A team that scoped the work as decision-grade changes course cheaply — the assessment cost weeks, and it just redirected a quarter. A team that scoped it as phase zero of a rewrite keeps porting, because the plan has more momentum than the evidence.
What the deliverable commits to — and what it does not
The clearest way to keep an assessment trustworthy is to write down, in the deliverable itself, what it does not promise. Teams should be able to point at the recommendation afterwards and name the commitments they did not make.
| The assessment commits to | The assessment explicitly does not promise |
|---|---|
| A profiled baseline measured on representative inputs, with the measurement method stated | That the baseline generalises to workloads it did not measure |
| Bottleneck attribution across compute, memory, transfer and I/O | That the attribution stays valid after a model or traffic-shape change |
| Per-target gain estimates as ranges, bounded by the share of runtime the port can touch | A fixed speedup factor, a guaranteed multiple, or a headline number |
| A migration cost model built from your actual code structure | A fixed-price delivery quote or a staffing plan |
| A defer-or-commit recommendation with a payback window | A chosen target runtime selected before the profiling data existed |
| Traceability from recommendation back to measurement | Rewrite scope sign-off, interface design, or a port schedule |
That right-hand column is not a disclaimer. It is the thing that makes the left-hand column worth reading — an artefact that promises a speedup number before measuring one has told you it is not measuring.
Why an assessment cannot quote a speedup before profiling
Because the ceiling on any port is set by the share of runtime the port can actually reach, and nobody knows that share until it is measured. This is Amdahl arithmetic applied to a migration budget: if the interpreter and framework overhead you plan to rewrite in C++ accounts for 20% of wall-clock time, a perfect rewrite of that 20% buys you at most a 1.25× end-to-end improvement, no matter how good the C++ is. If the same path is dominated by host-to-device transfer or a synchronous upstream call, the language was never in the running.
Quoted speedup factors that arrive before the profiler does are almost always ported from someone else’s workload — a CUDA kernel benchmark, a Rust-versus-Python microbenchmark, a vendor’s TensorRT throughput chart. Those numbers are real; they are just measured on a different program. In our experience the gap between a microbenchmark ratio and an end-to-end ratio on a production serving path is routinely an order of magnitude, and it always points the same direction: the end-to-end number is smaller. (Observed across TechnoLynx engagements; not a published benchmark.)
There is a second reason, less discussed. Baselines are themselves a measurement choice. A C++ workload profiled at -O0 will make any GPU port look attractive; the same code at a tuned -O2 -march=native build sometimes closes most of the gap on its own. An assessment that does not state how the baseline was built has not given you a comparison, and a speedup range quoted against an unstated baseline is not a range — it is a hope with error bars drawn on.
The mirror failure: treating “defer” as a wasted spend
The first failure mode is committing before the evidence. The second is the inverse — reading a defer recommendation as money burned.
An assessment priced in weeks that prevents a migration priced in quarters has returned its cost several times over, and the return is real even though it appears as an absence on the roadmap. The avoided migration is the outcome. This is uncomfortable for sponsors, because a “do not port” recommendation produces no shipped artefact and no demo, and the counterfactual it saved you from is invisible by construction.
A legitimate defer recommendation is not a shrug. It looks like this:
- A named constraint — “68% of p99 latency is spent in image decode and serialisation on the CPU side; the model forward pass is 19%.”
- A ceiling calculation — the best case for the proposed port, computed from that attribution, and where it lands relative to the target.
- A cheaper alternative that was tested, not assumed — batching policy, a decode library swap, an ONNX Runtime execution-provider change, pinned-memory transfers.
- A re-trigger condition — the traffic shape, model size or latency target at which the port becomes worth re-examining.
- What would change the answer — the specific measurement that, if it moved, flips defer to commit.
A defer without a re-trigger condition is an opinion. A defer with one is a decision you can revisit without paying for the analysis again. The criteria for that flip — what thresholds the business actually cares about — are worth setting before the profiling run, which we cover in when porting earns its engineering cost and when it doesn’t.
Keeping the assessment independent of the work that may follow
The structural risk is obvious once named: if the same party that recommends the port is the party that books the port, the recommendation carries an incentive. That does not make it wrong, but it does mean the scoping has to carry the independence rather than the goodwill.
A few things make the boundary hold. Contract the assessment as its own engagement with its own deliverable and its own acceptance criteria — not as a discounted first phase of a migration statement of work. Write the three permissible outcomes into the scope document before the work starts, so “defer” is a delivered result rather than a failed one. Require that every gain estimate names its measurement basis. And keep the runtime choice downstream of the profiling data, not upstream of it; the CUDA-versus-OpenCL, C++-versus-Rust, native-versus-WASM questions are outputs of the assessment, never its premise.
This is also the honest reason we scope our GPU performance audit the way we do — as a document a buyer can defend a roadmap decision with, including the decision not to spend. The broader engagement design that sits behind this, including how the assessment hands off to whatever comes next, is set out in our R&D consulting practice.
Decision-grade versus delivery-grade, side by side
| Decision-grade assessment | Delivery-grade migration spec | |
|---|---|---|
| Question answered | Should we port, and what would we get? | How exactly do we build the ported system? |
| Duration | Weeks | Quarters (the port itself) |
| Output on gains | Ranges with confidence stated | Targets the team is accountable for hitting |
| Runtime choice | An output, ranked with rationale | An input, already fixed |
| Legitimate result | Commit, defer, or do not port | Working ported code |
| Failure signal | A recommendation with no traceable measurement | A spec that revisits the port/no-port question |
Read the rows top to bottom and the confusion becomes hard to sustain. The two artefacts answer different questions, and asking the first one to do the second one’s job is how the profiling report ends up being read after the staffing decision instead of before it.
Frequently Asked Questions
What does “a porting assessment is not a rewrite commitment” mean in practice? Porting assessments measure migration risk and effort without obligating teams to green-light full rewrites. For Porting Assessment, it helps to be precise. It means the engagement has three permissible outcomes — commit, defer, or do not port — and all three are delivered results rather than failures. In practice it shows up in scoping: the assessment is contracted separately from any migration work, and no runtime, scope or schedule is fixed before the profiling data exists.
What does the assessment deliverable actually commit to — and what does it explicitly not promise? It commits to a profiled baseline on representative inputs, bottleneck attribution across compute, memory, transfer and I/O, per-target gain ranges bounded by the share of runtime a port can reach, a migration cost model, and a defer-or-commit recommendation with a payback window. It does not promise a fixed speedup factor, a chosen runtime, a delivery price, or rewrite scope sign-off.
Why can’t an assessment quote a speedup factor before the workload is profiled? Because the ceiling on any port is bounded by the fraction of wall-clock time the port can touch, and that fraction is unknown until measured. A perfect rewrite of a component holding 20% of runtime yields at most about 1.25× end-to-end — so any number quoted earlier is borrowed from a different program’s measurements.
What does a legitimate “defer” recommendation look like, and how is that a return rather than a wasted spend? It names the measured constraint, calculates the best-case ceiling for the proposed port against the target, tests a cheaper alternative rather than assuming one, and states the re-trigger condition that would flip the answer. The return is the avoided migration: an assessment priced in weeks against a rewrite priced in quarters.
How does a decision-grade assessment differ from a delivery-grade migration design spec? The assessment answers whether to port and what the gain would plausibly be, expressing estimates as ranges; the design spec answers how to build the ported system, expressing targets the delivery team is accountable for. Runtime choice is an output of the first and an input to the second.
What happens when profiling shows the bottleneck is not the language or the runtime at all? That is a successful assessment, not a failed one. The recommendation redirects effort to the stage that actually dominates — decode, serialisation, host-to-device transfer, batching policy, an upstream synchronous call — and the port either narrows to something worth doing or comes off the roadmap.
How should we scope the engagement so the assessment stays independent of the porting work that may follow? Contract it as its own engagement with its own acceptance criteria rather than as phase zero of a migration statement of work, write the three permissible outcomes into the scope document up front, and require every gain estimate to name its measurement basis so the recommendation can be re-checked by someone who was not in the room.
If your assessment cannot come back and say “not this quarter, and here is the number that would change our mind” — what exactly is it measuring?
Three Paths Forward Once You Have Data
With effort boundaries and hotspot profiles in hand, you can confidently port, optimize existing infrastructure, or procure different hardware—each choice now backed by measured trade-offs instead of guesswork. If Porting Assessment is on your roadmap, the next step is to map it onto your own constraints rather than copy a reference architecture.
