In the first part of our three-part series on Unix-Linux migrations, we discussed how to plan for a migration. But what are the next steps? In part two of this series, we'll offer tips on building the project team, how to work with the code, and also discuss the process of configuration and administration of the new systems.
Once engaged in a project and having implemented the steps we discussed in part one , you should already be ahead of the game. You've completed the assessment and you've done a comprehensive inventory to determine exactly what resides on your servers--including details like version and release numbers. At the same time, you've also decided which applications you'd like to port to Linux.
Furthermore, you checked the business process and application and everyone has signed off on the project's scope and timing. You've also mapped out the end-date of the project and have even started to prototype your environment by installing and experimenting with a Linux distribution on a PC.
Now, onwards.
Let's start with a staffing management plan--part of an overall project plan. This involves determining who will be responsible for what tasks and who will be doing the work. How large is the team and of what will the reporting strategy consist? Are you going to tackle the project alone or will a vendor help you support the project? These are just some of the questions you'll need to answer before moving on.
At the same time, you'll also need to address some fundamental issues, such as the financial picture. What is the budget? Do you even have an approved budget for the project? It's critical that the business is engaged every step of the way in the project, particularly during the beginning phases: governance and initiation. While justifying the project, make sure you whip up those fancy slide presentations, to show how Linux will reduce IT's Total Cost of Ownership (TCO), while increasing the Return on Investment (ROI) for the project and the organization.
The bottom line is that if you don't have the business decision makers on your side, it will be irrelevant how wonderful the new technology will be. The project itself will be doomed to failure without business and senior stakeholder support. Remember that and file it away.
To illustrate, let's review a simple migration scenario.
In this example, your company is a small business and essentially you are the entire project team. Money is tight, but you may have a few dollars available for strategic purposes. As with many SMBs, you are resigned to doing most of the work itself, which is fine. What's the first thing you want to do?
It starts with the code. Understand that the complexity of what you are trying to do is directly related to the amount of system-dependent code that you have. Does the application you will be migrating use standard binaries, or do they depend on your hardware platform? What is the application written in, C++ or Java? Are there third-party tools and applications that will function as dependencies to your primary application? If so – can these tools even run on Linux? This is just some of the level of detail to which you must drill down.
Linux, being open source, will provide many advantages to you, including cost. That includes the compiler – which is free. The other side of the coin is that with a Linux migration, you could be more on your own than if you had migrated to a proprietary operating system with full vendor support. But this can be easily avoided if you work with one of the commercial Linux vendors.
Regarding the code, if you have the luxury of a development environment, you may want to do a phased-in migration for your application; continuing to develop code in your existing environment, so that you can ease Linux in gradually.
What type of compiler will you use? You probably want to use the GNU Compiler Collection (GCC). If you haven't yet compiled code with GCC and have only done so with your UNIX C compilers, you may want to consider compiling your code with GCC on your existing environment. This will help ease your transition. What's nice about GCC is that there are versions available for Solaris, AIX, and HP-UX that will let you recompile your C code very smoothly. There are going to be differences between your existing compiler and GCC – just understand that. One small example is that instead of using make, you'll start using gmake.
If you really don't want to go the route of recompiling everything on your existing server (dangerous if you have only one environment) , you can actually try rebuilding everything on the Linux server.
First, check to make sure you have all the compilers and build tools already preinstalled on your original machine. If not, bring over the source code, as well as the makefiles, and start rebuilding. To reiterate the point, look closely to make sure there is no hardware-specific code that will trip up your migration and ruin your day. If there is hardware-specific code, be prepared to rewrite that code for your new Linux server.
Odds are that you're going to have to make changes with your runtime APIs. There are many things you need to think about, which may not be included in your Linux distribution, such as system calls, file system and logical volume management, streams, and library support. Some math libraries may not even be supported and you may have issues with your desktop environment. Are you currently using the Common Desktop Environment (CDE)? If so, you'll have to choose one of the Linux environments, such as KDE and GNOME.
It's also important that you start to consider basis systems administration. As we discussed previously, while Linux is Unix-like, it is not Unix. There are many differences: from process management to filesystem management to kernel tuning. Start planning for those Linux administration classes and make sure you've budgeted for them accordingly.
There are also many free tools available to help which are on the Internet, use them. One such tool is the Rosetta Stone, a guide which actually compares Unix and Linux commands. I always found this to be one of the better guides on the Internet; it will definitely get you up to speed on using Linux commands.
The net result of all of this is, you will have a lot of homework to do before you plunge ahead with your migration, so make sure you do that homework.
In part three of this series, we'll try to bring it all together for you.
Next in the Migration Center: UNIX to Linux: Finishing Touches on Migration
