Did you do your homework? If you've read the first two installments of this migration tips series and completed the suggested tasks and readings, you're ready to roll with your Unix-to-Linux project. In this episode, I'll help you tie up the loose ends and get going!
Let's start with a review. You should now have your Linux server up and running, and moved both your software and data to the new box. You've even re-compiled your software.
Now, how are you going to do source-code management on the box? Are you currently using SCCS, the old proprietary Unix source code control suite? Why don't you look at GNU CSSC? GNU CSSC is to SCCS what GCC is to CC. You may also want to look at CVS.
When you have the source-code management process in place, you need to move on to your back-end infrastructure. Ask yourself these questions: How will the new Linux server fit in with the existing infrastructure? Are there dependencies between servers on other platforms that may need to be tweaked or looked at more in depth? What about your middleware? Are you using IBM WebSphere or another product? How will that tie into things?
Once you've answered these questions, get going and examine your hardware and network. Now, you've got a new checklist: Do you have GigE cards in that fancy new Intel Server? If so, how will that tie into your existing switches? Are their firmware issues to be addressed?
Look at everything now, while you have the opportunity to do it in a non-production environment. Don't forget that you'll have to set up networking on the Linux box to integrate this box into your other network. Your migration plan will really have to drill down on things such as hostnames and/or IP addresses. After all, there might be an unnecessary outage when the application is migrated if there are dependencies somewhere in the application that you did not foresee, such as hardcoded hostnames.
Even if you're a one-person migration team, communicate regularly with others in your organization about your project. Why? Well, for one thing, DNS changes may also need to be made by another group, so make sure you involve all interested (and even disinterested) parties in what you are doing at all times. Sure, you were successful technically in getting the software/data converted, but other groups may not be happy with your work. The worst thing that could happen to you is that you missed too many steps in both the planning and implementation process, and other groups suffered or think they might suffer as a result. Perception is everything! So, be diligent and careful not only with technologies but with people, too.
While we're on the subject of being careful, do you have enough environments in place to help you with the transition? You should have at least three environments to do this correctly. If you are making development changes in either your testing -- or even worse, your production environments, you are asking for big trouble. Your development environment would be used to introduce new code. Your test environment would be used to test the code, and also to stress it. Finally, production would be what it sounds like, production. That means that code should only be introduced in that environment when the performance, reliability and security of the code have already been well documented. You can combine some of these environments into the same physical boxes, though I would try to keep production on its own server, if possible.
The final areas I'd like to address are post-support and/or migration help and education. You have to be realistic. Can you really do an entire Linux-Unix migration on your own? You may have the technical know-how, but do you have the time? If you don't, raise your hand early in the process, rather than doing it when you're already overwhelmed and saturated with problems. Check out consultants and vendors' services groups. If your budget doesn't allow you to bring in, say, IBM Global Services, there are plenty of other resources. For example, the Unix Guru Universe site has listings for many Unix and Linux vendors.
You can get a lot of free tech support online. Check out your Linux variant portal for further migration assistance. Get on and submit questions to the mailing lists for the distributions and products you use. Some vendors' sites have a wealth of information on Unix-Linux migrations.
The key to success with a Linux migration is education. Cut your budget in other ways, not with education and training. To reiterate, though Linux is Unix-like, it is not Unix. Think of it like this, while some AIX know-how may be useful in working with an HP-UX variant, you'll still have to know HP-UX well to implement and manage it. There are so many differences between just the Unix variants, that a seasoned AIX admin will be lost on his or her first introduction to Solaris. So, yes, your Unix background will be helpful in using Linux, but it's not enough.
Be sure to use all the free educational resources in the Linux and open source world. I'm not just plugging, when I say that our own site is a great source of information for all kinds of Linux information. Yes, some of the best things in life really are free.
