The Arm Migration Nobody Prioritises: Graviton, Cobalt and Axion for Data Workloads

Somewhere in your account there is a fleet of general-purpose instances running the backend of a School ERP or a Hospital Management System. Steady traffic, predictable shape, mostly JSON in and JSON out with a database behind it. It has been on x86 since the day it launched, for no reason anyone can articulate beyond that being the default when someone typed the first Terraform file. Moving it to Arm would cut the compute line item by a meaningful fraction, and it will not happen this quarter, because nobody gets promoted for changing a CPU architecture.

That is the whole problem. Arm migration is boring work with real savings, and boring work with real savings loses every prioritisation fight to something with a demo.

The silicon stopped being the excuse#

The “wait and see” position on Arm expired. All three major clouds are now several generations deep into custom silicon, and the current parts are not compromise chips.

AWS shipped Graviton5 with the M9g and M9gd instance families in June 2026. The launch post claims 192 cores, five times the L3 cache of the previous generation, and up to 25 percent better compute performance than Graviton4, with higher figures called out for databases, web applications and ML inference. Those are AWS’s numbers about AWS’s chip, and should be read that way — but the direction is not ambiguous.

Microsoft previewed Cobalt 200 at Ignite in November 2025: 132 Arm Neoverse V3 cores on TSMC’s 3nm process, with a custom memory controller so that memory encryption is on by default at what Microsoft describes as negligible overhead. Microsoft’s headline claim is up to 50 percent better performance than Cobalt 100.

Google’s Axion line covers both ends: C4A for performance-sensitive work, and N4A, generally available since early 2026, built on Neoverse N3 and aimed squarely at price-performance. Google’s own positioning for C4A was better price-performance than the other clouds’ Arm instances — again, a vendor claim about a vendor chip.

The signal worth more than any of those charts arrived on 23 July 2026, when Microsoft and Databricks expanded their partnership into the 2030s. Buried under the Genie and Unity AI Gateway integration news is the operational detail: Databricks is expanding its use of Azure Cobalt for data-intensive workloads, currently runs on Cobalt 100, and plans to adopt Cobalt 200. A company whose entire economics are compute efficiency is standardising its own operations on Arm. That is a stronger endorsement than a benchmark deck.

The macro picture matches. Reporting from Computex this year put Arm at roughly half of hyperscaler CPU compute, and Tom’s Hardware covered analyst figures showing Arm servers taking over 45 percent of data centre market revenue. Whatever the exact number, x86-by-default is no longer the safe conservative choice. It is just the old one.

What actually breaks in 2026#

Almost nothing, which is exactly why the perceived risk is now higher than the real risk. Your Python, Go, Java, Node and Rust code is portable. The failures live one layer down, and the list has been shrinking every year.

• Native extensions without arm64 wheels. The mainstream scientific and data stack — NumPy, pandas, PyArrow, psycopg, cryptography — ships aarch64 wheels. The breakage is in the long tail: an unmaintained vendor SDK, a proprietary database driver, a package pinned to a version from 2021 that predates arm64 wheels entirely. Pip falls back to building from source and then fails on a missing header at deploy time.
• Base images pinned to an amd64 digest. A FROM line with a hard-coded SHA is not a manifest list. Every architecture pulls the same amd64 layer, the build succeeds, and the container dies at runtime on the Arm node. This is the single most common self-inflicted wound.
• Binaries downloaded in the Dockerfile. Every curl of a release tarball with linux-amd64 in the filename is a landmine. Grep for it.
• JIT-heavy runtimes with old baselines. The JVM is fine on aarch64 and has been for years, but an ancient JDK, a native agent, or an APM profiler compiled for x86 will not be. .NET Framework — as opposed to modern .NET — does not come along at all.
• Anything with an x86 intrinsic in it. Hand-tuned AVX paths in a codec, a compression library or a numerical kernel need an equivalent NEON or SVE path, or they fall back to something slow.

Finding out is cheap, and this is the part teams skip. Spin up a single Arm instance, or an Arm node pool with a taint, and try to build the image. One engineer, one afternoon. The output is a concrete list of blocked dependencies rather than a vague sense that “our stack probably isn’t ready.” In most estates that list fits in a Slack message, and half of it resolves by bumping a pin.

The build pipeline is the actual project#

Here is the reframe that unsticks these migrations: the hard part is not Arm. The hard part is that your CI produces exactly one architecture, and that was a design decision nobody revisited.

Fix that and the migration becomes a per-service decision instead of a program of work. Docker buildx with a manifest list means one image tag serves both architectures and the scheduler picks correctly. The prerequisites are unglamorous: replace digest-pinned base images with multi-arch manifests, parameterise architecture in your artefact download steps, and — the one that matters most — build each architecture on its own native runner in a CI matrix rather than cross-building under QEMU. Emulated builds of native modules are slow enough to turn a six-minute pipeline into a forty-minute one, and that alone has killed more Arm migrations than any dependency ever has. GitHub Actions, GitLab and CodeBuild all offer Arm runners now.

For a competent platform team this is a week, not a quarter. It also pays for itself independently of Arm: a build pipeline that treats architecture as a variable is the same pipeline that lets you move a workload between clouds without a rewrite — the sort of Operational Automation that keeps paying long after the migration ticket closes.

Where the money is, and where it isn’t#

Not every workload should move, and pretending otherwise is how you burn credibility on the third service.

Arm pays best on steady-state, CPU-bound, horizontally scaled work. The API tier of a Hospital Management System. Queue consumers. Scheduled ETL. Anything that runs 24/7 at moderate utilisation, where a per-core efficiency gain multiplies across a large fleet and across every hour of the year.

It pays well on open-source databases and analytics engines — PostgreSQL, MySQL, Redis, Kafka, and columnar engines like ClickHouse, where memory bandwidth and cache behaviour dominate and the vendors have done real aarch64 optimisation work. For a Data Platform running continuous aggregation over operational data, this is often the largest single line item in the bill and the one with the clearest payback.

It pays on CPU inference for small models — embeddings, rerankers, classifiers, the unglamorous models that carry most production AI implementation work. These rarely justify a GPU, and they are exactly where Arm’s price-performance shows up.

It does not pay on GPU-bound training or large-model serving, where the CPU is a chauffeur and its cost is a rounding error. It does not pay on bursty, near-idle services where the whole compute line is trivially small. And it does not pay on the one legacy component with a proprietary x86-only binary — leave it, run a mixed fleet, and stop treating architectural purity as a goal.

Migrate in the order that lets you retreat#

Sequence the work so that every step is reversible under load.

Stateless services first. Deploy the multi-arch image to a mixed node pool, shift a slice of traffic, watch p99 latency and error rate, and roll back with a label change if anything moves. Then batch and asynchronous work, where a failed job retries and nobody notices. Then, and only then, stateful systems — a read replica promoted to Arm and observed for a full business cycle before the primary follows.

The order is not about difficulty. It is about blast radius. A stateless rollback is a deploy; a stateful rollback is an incident.

Benchmark your own workload#

The vendor numbers above are real, published, and nearly useless for your capacity plan. “Up to 30 percent faster for databases” describes a benchmark that is not your database, on a schema that is not your schema, with a query mix nobody in your organisation would recognise.

Run the comparison yourself and make it honest. Same code, same data volume, same concurrency, replayed production traffic if you can get it. Measure p99 latency under load rather than throughput on an idle box. Hold the instance count fixed and observe headroom, or hold latency fixed and find the instance count each architecture needs — that second number is the one that converts to money. Then check the total: sometimes the right migration is not one-for-one but a different instance size entirely, and you only find that by measuring.

The compounding case#

The reason this deserves a slot on the roadmap is that the saving is not a one-off. Cloud compute is a recurring cost that scales with growth, so a per-core efficiency gain compounds with every new customer you onboard.

It also stacks with the levers you already have. Arm savings apply before reserved instances and savings plans, so the same commitment buys more capacity. That is the FinOps argument in one line: this is not an alternative to your existing cost programme, it is a multiplier on it. And it is durable in a way that rightsizing exercises are not — nobody quietly reverts a CPU architecture six months later the way they reinflate an over-provisioned cluster.

This is the kind of work that separates a Data Platform from a legacy ERP estate. The heavy vendor stacks cannot move: their runtime is certified against one architecture, their support matrix forbids it, and their customers pay the x86 premium indefinitely because the data and the compute are trapped together. A system built as a data platform with a thoughtful interface on top treats compute as a substrate you can change. Then a change of architecture is a Tuesday deploy rather than a licensing negotiation.

Pull the lever. It is a week of pipeline work and a quarter of patient migration, and it shows up on every invoice from then on.

---

Boring migrations with compounding returns are the highest-leverage work on most infrastructure roadmaps. Tell us what your compute bill looks like at /#contact.