One of the first steps for implementing the migration from Unix to Linux is getting a sandbox environment in which to play. Your entire team may not have experience with Linux, and having an environment in which to learn (without fear of breaking anything) is invaluable.
Let's talk code and compilers. Are you running Java or C? Are there any third-party tools that will need to come over? Can they be migrated to Linux?
Let's assume you're using C. Let's also assume you will need to compile some code to move over to Linux. Use the GNU (gcc) compiler because this is the industry standard, and it's the native compiler for Linux. Applications compiled on other platforms will need to be recompiled.
You can choose between two methods of going about your compiled business. One method is recompiling your data on your existing environment, in which case you'll need to make sure you have all the required tools on the boxes, which includes the source code and makefiles. If you're considering this method, do this only on your test environment and never in your production environment.
The other choice is moving all your data and code to the new box and testing it all from that prototype environment. Think about the hardware platform as well. If you plan on moving the hardware platform, there may be some hardware-specific codes that will certainly trip you up and, in a worst-case scenario, force you to rewrite all your code.
Make sure your developers are part of the process, and don't assume anything. Considerations include runtime APIs, system calls, streams and library support. Be sure you fully understand the scope of what you're looking to port. This is where your assessment comes in and where you've identified everything about the application and its libraries and dependencies. This way you can quickly ascertain whether the products are available on Linux and where to find them.
In addition to your applications, you'll need to identify the test environment, user interface requirements, platform-dependent constraints, middleware products and internal skill levels in porting.
There is no question that applications written in Java tend to port more quickly than applications in C. In addition to your applications, you'll need to identify the test environment, user interface requirements, platform-dependent constraints, middleware products and internal skill levels in porting. Each of these areas has some risk.
The application piece is the most important component of migration. In some cases, your applications may already be ported, and there is little to do there. In other cases, you will have to recompile them completely on your new platform. Porting the software may be as easy as doing the recompile and then running validation tests to confirm everything is OK.
The porting process for your apps should include development and testing. When you're migrating your box, make sure you've decided on a method for migrating your database over. Applications that require kernel extensions and device drivers are not easy candidates to support, partly because most kernel APIs do not follow any stringent standards.
Does the application use third-party software components, such as database tools, application servers or other middleware? These will add to the complexity of the migration. Is the application 32-bit or 64-bit? If you're moving from 32-bit to 64-bit, you will need additional time to port. How does your application communicate with the database? Does it use database interfaces such as ODBC or programming languages like C++? These are all aspects you will need to consider. From a staffing standpoint, try to bring in personnel who have experience with these kinds of migration projects.
Gauging stability and performance
Application issues are usually discovered within the first several weeks, and engineers get the first inkling about what they are up against. This is when you may want to revisit your project plan to adjust any delivery dates.
Testing is critical for stability, functionality and performance. Don't spend $2 million on developing new systems and only $2,000 on testing. The sequence of testing usually works this way:
- Porting engineers do unit testing for applications they are porting.
- Application engineers perform functional testing.
- User acceptance testing, or UAT, takes place. This is where the actual business people do the testing.
- Performance engineers conduct performance testing.
Take advantage of testing, and don't let your systems people be the only ones to verify that everything is working.
During testing, it's essential that the ported application is running against stress tests to ensure that the system can handle the load. You should have already done baseline testing, which takes a snapshot of performance on the source environment–your current production environment.
Your goal is to run similar tests from a stability and performance standpoint. Try to break your systems. Use tools such as Hewlett-Packard's LoadRunner to simulate five times the amount of normal actively.
Now is the time to uncover bugs – not when you are in production. It's your opportunity to debug problems before they get into production. Take advantage of testing, and don't let your systems people be the only ones to verify that everything is working. The business side of the house must not only be involved, but it should also write the UAT plans. If your system had high availability on the old environment, make certain that is also tested.
This was first published in June 2010