We do our internal development on SPARC chips, because we have a filer simulator that runs as a UNIX process under SunOS,
...and under Linux on x86, and under BSD/OS on x86, and under Digital UNIX on Alpha; running the simulator on little-endian and/or 64-bit platforms is useful, because otherwise you don't run into some byte-order or 64-bit-cleanliness issues that you will run into when you try running the code on a real filer.
I don't mean to imply that there's no overhead associated with changing chips, because there are compiler issues and test issues and boot PROM issues and performance issues.
And byte-order issues if you plan to allow your disks to move from one system to another. Fortunately for us, Alpha was little-endian, but moving to a processor run in big-endian mode would add some complications. (I don't know how easy it'd be to run an UltraSPARC-based system in little-endian mode, for example; the CPU is bi-endian, but there may be other things we'd have to worry about.)