Migration to different CPU architecture – how to decide?

Most of the large IT shops are running their applications on computer systems with different CPU architecture. These different systems include not just RISC or IA, but also 32bit and 64bit processors. These are not exactly different CPU architecture all the times, but in most of the cases making a decision to move from one to the other present similar challenges. So why do we decide to move from one architecture to the other, and most importantly what do we need to take in to consideration when making such decision? For start I will just outline some of these challenges as we had to face them in high volume manufacturing area. No organisation that requires large scale computing environment will have same issues and challenges so there is no one solution for everyone. I do believe however that we all have to answer same set of questions before we start planning for migration, executing the plan and subsequently supporting our new environment.

When starting to think about migration to a different architecture make up a list of all these questions and start recording your answers. This will give you sufficient information to figure out if you really have to go through all this work, is it really worth it. And trust me, it is a huge amount of work you will have to go through…

  1. Why are we doing this? Try to answer what are your main drivers in simple statements. Nothing technical is required here, really trying to pinpoint your problem statement. It could be as simple as application is EOL on your current architecture, or on the other side it could be “it is a political” decision. Later one is usually easiest to justify and most of below is irrelevant for this type of reasoning.
  2. Is the application going to work on other architecture? Important piece here is to try and outline what is required for your application to be ported to new architecture, how much work is required. It may prove at the end that it is just too much work/cost and it is not worth doing it.
  3. Cost of ownership of new equipment? It is often forgotten by IT professionals that cost of buying new equipment is not the only cost you need to worry about. On-going service maintenance of the equipment can quickly add up to a sum that one never budgeted for, and the worst thing about it is that you have to pay it regularly for the lifetime of the equipment (I plan to write a separate blog on service contracts and maintenance, interesting subject in itself).
  4. Operational requirements post migration? This is where you need to answer series of questions on your on-going support. These are some of the questions you may want to ask yourself: is your operational support model going to have to change once you migrate to new equipment; Is support organisation sufficiently skilled to support new environment; Is the headcount adequate?
  5. How will the migration impact my day-to-day business? This is one of the most important implementation questions, once you already decided that the move to new architecture is going to happen. If your organisation runs an application (or more than one of them) that are not time sensitive and your business can survive happily with few hours of downtime then this is easy. On the other hand if you are running an operation that is highly time sensitive, you cannot afford prolonged downtime because your business will incur huge losses, this is where it is getting interesting and migration strategy is something you have to spend considerable amount of time preparing.

My experience here is in high volume manufacturing area, environment with multiple different CPU architectures running different operating systems supporting highly time sensitive applications. I will try and answer some of the above questions as we addressed them in our environment in the next few blogs, so stay tuned and I hope you will find it useful.