Most infrastructure programs start with a mandate from leadership or a burning production problem. This one started with a conversation at a conference and a question I couldn't stop thinking about: what would a 20–35% cost reduction across our entire database fleet actually look like?
This post walks through how that question became a formal program — the business case, the evaluation methodology, and the architecture decisions that shaped it.
Spotting the opportunity
At AWS re:Invent in late 2025, I attended sessions on Graviton (ARM64) adoption. The data was compelling — customers reporting 20–35% cost reductions on compute-heavy workloads by switching from x86 to ARM64 instances. AWS had case studies across multiple industries.
I looked at our environment: a large database fleet running entirely on x86 — MongoDB, Cassandra, MySQL — across multiple regions. Graviton hadn't been evaluated for our workloads yet, and I saw an opportunity worth investigating.
Starting with a business case
Before spinning up any infrastructure, the first step was building a formal proposal:
- Quantified the potential savings based on a full database fleet inventory and current vs Graviton instance pricing
- Compiled AWS customer case studies (six organizations in similar domains reporting 20–35% cost reductions)
- Defined the evaluation methodology — controlled POC with production-equivalent benchmarking
- Identified the risk model — an out-of-place approach meant zero production impact during evaluation
- Outlined the timeline and resource requirements
The proposal went through approval in early Q1 2026. The program was officially greenlit and kicked off the same quarter.
The lesson: a migration program needs a business case before it needs infrastructure. Numbers and risk models get approvals — enthusiasm doesn't.
Setting up the evaluation environment
With approval in hand, the evaluation infrastructure was provisioned using Terraform — a full dual-architecture environment with x86 and ARM64 side by side, identical configurations, ready for controlled benchmarking.
The key design choice: both environments had to be identical in every way except the instance family. Same cluster topology, same storage configuration, same network setup. Any performance difference had to come from the architecture change alone — no other variables.
The evaluation: production-equivalent benchmarks
The first platform we evaluated was MongoDB. The methodology:
- Two-phase approach: Phase 1 established a clean baseline comparison. Phase 2 expanded to multiple workload patterns and thread-scaling analysis.
- Controlled benchmarking across both architectures with identical configurations
- Multiple workload profiles representing production access patterns (YCSB benchmark suite)
- Thread-scaling analysis to understand how each architecture performs under increasing concurrency
Phase 1 identified an 18% read latency gap on one workload pattern — Zipfian distribution (hot-key access, common in production). Rather than accept it as a limitation, we identified the root cause in Phase 2 and resolved it through configuration tuning.
Final result: +39.5% cost/performance improvement on ARM64 vs x86. Not theoretical savings from a pricing calculator — measured improvement on production-equivalent benchmarks in a controlled environment.
Takeaway: a single-phase benchmark would have missed the latency gap entirely. The two-phase approach — baseline first, then expand — catches issues that matter in production before you get there.
External validation
We engaged an AWS Solutions Architect to review the methodology and results independently. After their review, they provided a formal GO recommendation for production migration. The six customer case studies shared during the business-case phase were validated by our results falling within the same range.
External validation de-risks the decision for leadership — a vendor SA's endorsement alongside your own data makes the approval conversation shorter.
What the program produced
Beyond the benchmark results, the program produced a reusable foundation:
- Evaluation methodology applicable to any database platform
- Full documentation: architecture diagrams, decision records, gap analysis
- Version gap analysis for the target platform (identified and categorized by risk level)
- Out-of-place migration blueprint — new infrastructure, not in-place upgrades
- Risk model and rollback strategy baked into the approach from day one
The same methodology is now being applied to the next platform (Cassandra) — same framework, same rigor, different database.
Why out-of-place wins
One architecture decision shaped everything: out-of-place migration over in-place upgrades.
In-place means modifying your production infrastructure while it serves traffic. Every change is a risk event on a live system. Rollback is often "restore from backup" — which isn't really rollback, it's recovery.
Out-of-place means building new infrastructure alongside the existing, validating it completely, and cutting over only when proven. The source environment is never modified. Rollback is instant — just don't cut over.
For a database fleet migration that bundles version upgrade + architecture change + OS modernization, out-of-place is the only approach where the blast radius is controllable.
If you're planning a similar migration: start with out-of-place as the default. Only consider in-place if the fleet is small enough that rollback risk is acceptable — and even then, question whether "acceptable" means "we've actually tested rollback" or just "we hope it works."
Lessons learned
- Build the business case first. Data and risk models get approvals. Conference excitement doesn't survive the first leadership review without numbers behind it.
- Two-phase benchmarking catches what single-phase misses. The 18% latency gap on Zipfian workloads would have shown up in production if we'd only run a basic comparison.
- Out-of-place is the default for any multi-variable migration. Version upgrade + architecture change + OS change = too many variables for in-place.
- External validation de-risks leadership decisions. A vendor SA endorsement alongside your own data makes the approval path shorter.
- The methodology matters more than the single result. +39.5% is great, but a reusable framework that applies to the next platform — that's the lasting value.