The dev/prod mismatch concern is reasonable but the actual failure surface is narrow. Pure Python is fine. The risk is native deps with C extensions (NumPy, SciPy, cryptography, lxml, Pillow). If your data science stack has those, the work is auditing your dep tree for arch-specific behavior, setting up a multi-arch CI matrix, and cutting over one service at a time on Graviton before touching prod.

Most ARM moves either go great (no native deps) or get stuck because someone finds a half-broken arch-specific wheel. The audit is usually the part nobody wants to do.

(Building Keshro for this kind of multi-step audit + cutover, but the answer stands either way.)

While i have not had the opportunity to switch my web-facing system to ARM, i would jump at the chance to, if for no other reason than the likely power savings[^1]. i host several Pi (ARM) systems in my home network and have nothing but respect for them. For about six months i rented a RISC-V system from Scaleway, mostly to see how it compared to my beloved pi4 and pi5, but it was so very slow (took 96 hours to run sqlite's core release test suite).

Re. platform portability: i primarily write C code and have had very close to 0 issues regarding software portability (once one finally internalizes that unqualified "char" may be either signed or unsigned, depending on the platform, and codes accordingly, it's smooth sailing). On my home ARM servers i've had zero issues re. availability of tools which i'd expect to have on x86 systems. They "just work".

That is, i guess, to say: don't hesitate to try it out if you have the opportunity to do so.

[^1]: my current system is on loan to me from a generous colleague, so moving to an ARM hoster would be a new cost, which currently rules it out as an option. If i were paying full price for the current x86 box i'd have most definitely already looked for an ARM substitute.

I switched to Arm and saved a lot and it caused zero issues. Especially if you’re using an interpreted language like Python you shouldn’t have any problems.

Software might not be quite as optimized for Arm as it is for x86, but in practice you probably won’t notice. In fact, Arm might be faster because it doesn’t have hyper-threading so every vCPU is a full core.