ARM Migration: The Tail Nobody Budgets For

Q: How much do ARM instances actually save?

The commonly cited figure is meaningful price-performance improvement over comparable x86 for general-purpose workloads, but the number that matters is the one you measure on your own traffic, because published figures are averages across workload mixes you may not share. Two framing points matter more than the headline. First, it is price-performance rather than price. Depending on the workload you either need fewer ARM cores to do the same work, or the same core count costs less. Which of those you get is workload-dependent, so the correct metric is cost per unit of work — requests served per dollar, jobs completed per dollar — not instance hourly rate. A cheaper instance that requires more instances is not a saving. Second, the realised saving is usually below the headline for reasons that have nothing to do with the architecture. Part of your fleet will be blocked by native dependencies, vendor agents or licence terms and will never move. If you swap like-for-like rather than right-sizing, you leave money unclaimed, because ARM instance families frequently have different core-to-memory ratios. And migration engineering time is a real cost that offsets the first year. Where results land in practice: workloads dominated by interpreted or JIT-compiled code, web serving, and general microservices tend to do well. Memory-bandwidth-bound and branch-heavy workloads vary more. Code with hand-optimised x86 SIMD can be significantly worse until a NEON path exists. The honest approach is to benchmark two or three representative services before committing to a fleet-wide number, which takes days and prevents a business case built on someone else average.

Q: What actually blocks an ARM migration?

Four categories, and only one of them is an engineering problem you control. Native dependencies are the most common. Anything compiled — Python packages with C extensions, Node modules with native bindings, JVM libraries wrapping native code — needs an ARM build. Maintained popular packages generally have one; older, niche or internal ones frequently do not, and then you are building from source in CI and owning that build indefinitely. Vendor agents are the most likely to stop a whole host class. Observability, security, backup and licence-management agents shipped as closed x86-only binaries mean those hosts cannot move until the vendor ships ARM. Your leverage is a support ticket and your timeline is theirs. This is worth discovering in week one rather than month four. Licence terms tied to architecture or core counts are a procurement conversation, not a technical one, and they can invalidate the saving on specific workloads entirely. Hand-optimised SIMD is the hard engineering case. x86 intrinsics such as SSE and AVX do not port automatically; code needs a NEON path or falls back to scalar, which can be dramatically slower. This affects media processing, compression, cryptography and numerical code disproportionately. Two more that are less blocking but consistently underestimated: container base images without ARM variants, which is usually solvable but occasionally forces a base image change with its own testing burden; and CI, since you are now building two architectures and emulated ARM builds on x86 runners are slow enough to change how the team works. The practical takeaway is to enumerate all four categories before starting, because that list determines the timeline far more than the price-performance figure does.

Q: Should I switch to ARM or build multi-architecture images?

Build multi-architecture, essentially always, and treat the ability to run either as the deliverable rather than the migration itself. Multi-arch means your build pipeline produces images for both architectures and the platform selects the right one at runtime. Docker multi-platform build support makes this a build configuration change rather than maintaining two pipelines. The advantages compound in ways a straight switch does not offer. Every step becomes reversible per service: if a workload regresses on ARM you move it back by changing where it is scheduled, not by rebuilding and redeploying a pipeline under incident pressure. You can run mixed fleets during migration rather than needing a cutover. Canarying by architecture becomes possible, so you compare real production behaviour rather than benchmark behaviour. And new services are architecture-agnostic from the first commit, which means you never run this programme again. The costs are modest and worth naming: build times roughly double unless you parallelise across native runners, image storage increases, and your test matrix grows because you should be testing both. Native ARM CI runners address the build time and are worth setting up early rather than tolerating emulation. The strategic argument is the one that matters most for a long programme. A switch is a one-way decision made under deadline pressure with an incident as the failure mode. Multi-arch turns the same work into a series of small reversible decisions, which is what keeps a six-month migration politically survivable when the third unexpected blocker appears.

Q: How do I know if a specific workload will perform well on ARM?

Benchmark it, because the workload characteristics that predict performance are not visible from the service description. That said, there are useful priors. Likely to do well: interpreted and JIT-compiled languages where the runtime abstracts the architecture and has been optimised for ARM; web serving and API workloads dominated by I/O and framework overhead; containerised microservices with modest per-request compute; and workloads that benefit from higher core counts at the same price point. Needs measurement: memory-bandwidth-bound workloads, since the memory subsystem differs and results vary by instance family; databases and caches, where behaviour depends heavily on access patterns; and anything latency-sensitive at the tail, because average throughput improving does not guarantee p99 does. Likely to be worse without work: code with hand-written x86 SIMD, which needs a NEON path; anything depending on x86-specific instructions or timing assumptions; and workloads pinned to a library that has an optimised x86 path and a generic ARM fallback. How to benchmark properly. Use your real workload rather than a synthetic benchmark, since synthetic results routinely fail to predict production. Measure cost per unit of work rather than raw throughput, because that is the business metric. Test at realistic concurrency, as behaviour under load differs from single-request timing. Compare against a right-sized x86 baseline rather than whatever you happen to run today, or you will conflate the ARM saving with a rightsizing saving. And watch p99 alongside averages. Two or three representative services benchmarked properly gives you a defensible fleet-wide estimate; extrapolating from a published average does not.

Q: What happens to CI when we run two architectures?

It becomes a workstream, and it is the most consistently unscoped part of these programmes. Once production runs both architectures, CI must build and ideally test both. The naive approach is emulation — building ARM images on x86 runners via QEMU — which works and is slow, frequently several times slower than native. On a pipeline that runs many times a day that is a material change to how quickly your team ships, and it tends to be discovered after the first tranche of services has already moved. The correct answer is native ARM runners. All major cloud providers offer ARM instances you can use as self-hosted runners, and hosted CI providers increasingly offer ARM runners directly. Native builds remove the emulation penalty entirely and let you run the real test suite on the architecture you will deploy to, which is the more important benefit. A workable pipeline shape: build both architectures in parallel on native runners for each, run the full test suite on both, then assemble a multi-arch manifest so a single image reference resolves correctly on either. Cache layers per architecture, since sharing them across architectures does not work the way people expect. Three practical notes. Budget the runner cost, because you are roughly doubling build capacity and that is a real line item. Decide deliberately whether every commit needs both architectures tested or whether ARM tests can run on merge, trading coverage against cost. And do this early — before the first tranche of services migrates — because retrofitting CI while production is already mixed is considerably more disruptive than setting it up in advance.

Q: Do we need to change our code to run on ARM?

Usually not at all, and where you do it is concentrated in a small and identifiable set of places. For most application code — Python, Node, Ruby, Java, C#, Go, Rust — the answer is no changes. The runtime or compiler handles the architecture and your code is unaware of it. Go and Rust cross-compile with a flag; interpreted and JIT languages need no build change whatsoever. This is why the easy 80% genuinely is easy. Where changes are needed. Native dependencies may need rebuilding, which is a build-configuration change rather than a code change, though you may end up owning a build you previously consumed. Hand-optimised SIMD needs a NEON path, and that is real engineering work requiring someone who understands the algorithm — this is the genuine code-change case. Inline assembly obviously does not port. Anything depending on x86-specific behaviour, such as instruction timing or specific floating-point edge cases, needs review. And code with architecture-conditional compilation needs its ARM branch verified rather than assumed correct. The category worth flagging separately, because it causes confusion and blame: ARM has a weaker memory-ordering model than x86. Concurrent code containing latent synchronisation bugs — a missing memory barrier, a data race that x86 stronger ordering happened to mask — can start failing on ARM. That is your bug, revealed rather than caused by the migration, and treating it as an ARM defect wastes time and occasionally derails the programme politically. The reasonable expectation: most services need zero changes, a minority need a dependency rebuilt, and a small number with SIMD or subtle concurrency issues need genuine engineering attention.

Q: Is ARM migration worth it before fixing utilisation and commitments?

No — sequence the cheaper, faster levers first, or you bank a percentage of a number that should have been much smaller. If your fleet averages low utilisation, migrating to ARM buys you a cheaper way to run idle capacity. The saving is real but it is applied to waste. Rightsizing, eliminating idle and forgotten resources, shutting down non-production environments outside working hours, and applying committed-use discounts to predictable baseline demand are all faster, reversible, require no code changes and no migration risk, and frequently deliver more than the ARM percentage would have. Doing them first also gives you an accurate baseline: an ARM migration measured against an unoptimised fleet produces a saving figure that conflates two different things, and you will not know which lever delivered what. A sensible order: attribute spend per service and team so you know where the money goes; remove obvious waste; apply commitments to stable baseline demand; right-size against real utilisation; then migrate architecture. The important caveat is that these are not mutually exclusive and the ordering is about sequencing rather than exclusion. If you have an existing multi-arch pipeline and a service that trivially moves, there is no reason to block it behind a rightsizing programme. The argument is against launching an ARM migration as your primary cost initiative while the cheaper levers remain unpulled — which is a common pattern, because architecture migration is more interesting engineering work than deleting unused volumes and negotiating commitments. The unglamorous work usually pays better and pays sooner.

Q: What does a realistic ARM migration timeline look like?

Weeks for the easy majority, months for completion, and the gap between those two numbers is the entire planning problem. A realistic shape for a mid-sized fleet. Weeks one and two: inventory. Enumerate native dependencies per service, vendor agents per host class, base image availability, and licence terms. This is unglamorous, takes days rather than weeks if someone owns it, and determines everything downstream. Weeks two to four: pipeline. Multi-arch builds, native ARM CI runners, test matrix. Do this before migrating anything so every subsequent step is reversible. Weeks four to eight: the easy majority. Stateless services on maintained runtimes, batch workers, internal tooling. These move quickly and bank real saving while the tail is worked. Benchmark before and after rather than assuming. Months two to six: the tail. Vendor agent timelines you do not control, dependencies needing source builds, SIMD work, licence renegotiation, and the latency-sensitive or stateful services you deliberately deferred. This is where programmes stall, and the difference between stalling and finishing is whether each remaining item has a named owner and a tracked dependency. Ongoing: right-sizing after the move, and making multi-arch the default for new services so this never becomes a programme again. Two planning notes. Do not report completion percentage by service count, because it flatters progress — the last 20% is most of the work, and a chart showing 80% complete after six weeks sets an expectation the tail will not meet. And treat vendor ARM support as an external dependency with a tracked date, not an engineering task, because it is not one.