The migration from expensive legacy RISC platforms to lower cost commodity Intel Xeon based servers is not a trivial effort but it need not be so daunting that staying on the expensive RISC server is a reasonable alternative. What makes this migration process challenging is as much the alternative approaches as the actual process.
Regardless of the level of effort the migration process needs to start out with some analysis. Possibly the analysis need not go much beyond the existing documentation of the system. Other levels of analysis can be some study of alternatives from the system vendor; for instance do they have a native port for IA and can that be installed on an IA server? Other times there is no documentation and the source code is all custom with possibly vendor libraries edited for the application. Other applications have a native version for IA but your data is stored in the database in binary format. These are just a few samples of the sorts of RISC to IA migrations that are occurring.
Most companies I’ve worked with have a pretty good idea of the parameters of the application they want to migrate. They believe they have studied the problem pretty well while in the process of getting the approval to execute the migration. Maybe the staff wants to migrate not just the application but a large number of external components as well such as LDAP capability. They bring me in because they want to get on with the actual migration. They don’t want credenzaware, you know, those three ring binders of data sitting on the IT managers credenza.
But to me simplicity is the key to success. You know that when making changes to a system that only one thing, the operating system upgrade, the application upgrade, application changes, platform upgrade, etc., should be changed at a time. Otherwise it may be difficult if not impossible to isolate the cause of problems and bugs that are encountered. The migration process introduces changes in all sorts of variables, platform, operating system, application version, and more. By adding variables to the plan that are peripheral to the main system, the likelihood of the failure of the migration skyrockets. A little additional analysis can help in keeping it simple.
So after our brief analysis has limited the parameters of the migration effort, what are we going to do first, a pilot or a proof of concept? At the risk of being obvious a pilot is a test of a system that will be cloned after the pilot works the kinks out. A proof of concept is executed to ‘prove’ out the idea that this concept will work.
For example, suppose that the RISC servers are managing backup systems for the corporation. The same backup application is available in a native version for IA servers. A pilot should be run to test installing the backup application on the IA server, hooking it into the corporate network and ensuring it can handle the load and functions as well as or better than the more expensive RISC server. This process creates a script that can be replicated for all of the other RISC servers supporting the backup process.
Once the agreed upon testing period has ended and the script for replicating the process is written, the next step is to begin the conversion process for all of the other RISC servers running the backup software. And then you’re done! You’ve converted your application running on RISC servers over to IA likely saving the company tons of money.
If only it were only all so easy. Migrating application systems, whether based on a vendors application platform or built in the shop with custom source code, by a long departed author who used Russian cities as variable names (but I digress), the migration requires a careful process. That process begins with a Proof of Concept.
The proof of concept starts with some simple premises. We’re not migrating the production application, just a copy or backup of the production application. We’re going to make sure, at the end of the process that the application on the IA platform has all the functionality and better performance of the production system running on the RISC server. In other words we’ve accounted for everything that has to be moved. And we’re going to be sure we have documented all the steps to build a recipe for the actual migration of the production system.
The Proof of Concept may not even follow the process that will be used in the migration of the production system. Here we are proving to ourselves that it will be worth it, we’ve got the right sized server and the performance meets or exceeds expectations.
The Proof of Concept will differ because many of the conversion steps can be taken in this stage. For instance shell scripts can be set up and will eventually serve the production system. For custom written applications some vendors offer migration services like programs that read the source code and spit out where the libraries need to be changed and the code syntax needs to be changed for Linux and this will not need to be replicated in the production migration. (Of course you have locked down code changes once the Proof of Concept has started.)
My next blog will cover the methodology of the Proof of Concept. (POC)