We talk a lot about how great the Intel Xeon processor compares vs. competing RISC architectures when it come to price and price/performance on various workloads, but unfortunately for many existing people running on RISC hardware, simply throwing out the old and standardizing on the shiny new Intel-based servers isn't always that simple of a proposition. Why? Your existing software running on UNIX (i.e. AIX, Solaris) may be custom-coded on your flavor of UNIX, the source code may be lost, the guy who wrote retired 5 years ago, etc. So, how do you account for this when 'running the numbers' to see if it makes sense to rid yourself of the power and money-sucking old RISC server collecting dust in the back of the data center? These five steps may help:
1. Understand the business benefits of moving from your existing RISC hardware to IA (and compare vs buying new RISC hardware)
This is the simple analysis that looks at performance of your existing system, compares it to new hardware and then factor in other significant cost items like power consumption, software licensing, software/hardware maintenance costs, etc. Of course, this almost always shows that new Intel hardware will save you significant dollars over the long-term and you can figure out how quickly you pay-back your cost of the server in years or possibly months based on this simple calculation. And, many server hardware vendors (and Intel field reps) have these tools available, you just need to ask.
2. ***** your current RISC-based infrastructure
Meaning, look at all the software that actually runs on these servers, the packaged applications and the custom code. Do you use particular storage adapters and drivers for your SAN, etc? Make a list. Now, look to see which items are easy, and which ones will be hard to migrate. If it's a packaged database that available on Windows, Linux, and Solaris for IA already, then it may be fairly to migrate the data over in a short period of time by yourself and move on. However, for those custom codes and potential software packages that will need to be changed in order to move to current hardware, start looking at the real costs to migrate these pieces. Often, this step will require some help from a services company or a hardware vendor that can provide these services in addition to selling you the new hardware. Now that you have these estimates, factor it back into step #1. Sure, the ROI will not look as good, but often will be surprising still very good even after factoring in these migration costs.
3. Develop a migration plan
You may chose to do this on your own if it doesn't look too intimidating, but for more complicated migrations, likely you will need some external help. If you've factored in these services costs already during the previous step then the cost of doing this step is already justified. Many services companies will give you the estimate very inexpensively.
4. Test
You may only be able to test the 'easy stuff' initially, but verify the performance deltas between the new and old systems calculated in step 1 to correctly size how much hardware you will need in actual deployment. This is where the actual performance of the system will measure up vs. the performance estimates used in your ROI analysis in step 1. Sometimes this can be better than calculated or worse, your mileage is guaranteed to vary.
5. Deploy
If you have your migration plan in place from step 3, now you execute according your plan, ensuring your migrate data in the right order to ensure minimal downtime.
These steps can be very intimidating, many people in IT find it hard to justify the migration costs (particularly if you need to pay for some services), but taking a systematic approach to it and carefully calculating your ROI including these extra costs will often make it worth the effort.