Migrating from one operating system to another can be a nightmare, even if you’re switching from a proprietary Unix OS (like HP-UX or Solaris) to a Unix-like OS like Linux. Why would you even want to migrate to Linux? For one thing – it’s flexible. It can run on pretty much anything, so you aren’t locked into any specific hardware, which leaves you free to try any hardware you’re interested in, and to move on whenever you want.
Moving between these two operating systems is hardly prohibitive: both Unix and Linux have POSIX compliant APIs, similar tools, similar directory structures, and most major Unix applications are supported on Linux. The biggest issues you’ll likely have are recompiling your software applications to run on Linux, and specifying the precise Linux variant you want to run on. Not all Linux distributions are the same: they have different levels of support for recent (or legacy) libraries, different file system layouts, and even different windowing systems. If you’re working with dynamic languages like Perl, Python, and Tcl, you will have a much easier time migrating because you won’t have to recompile them and the language installs take care of a lot of the system variations. At ActiveState we offer ActivePerl, ActivePython, and ActiveTcl editions for the major Unix proprietary operating systems, as well as for Linux, which will make migrating that much easier.
So where should you start? Start with what you have – hardware, operating system, networking, databases, applications and data. Take time to do an inventory, get the version numbers down, and find out if those versions are supported on Linux.
Steps to Migration
Examination (Determine Equivalents)
Recompiling your applications to work on Linux is going to take up most of your time, since you’ll be going through testing and development phases with each of them, so it’s important to examine what you’re working with. Check to see if the development tools you’ll need on Linux are available on your current platform, so you can start learning how to use those tools before you migrate. Make sure you have all the tools you need for recompilation, but also note anything you’ve built or customized internally and what you’ll need in order to port them. Perhaps most importantly – make sure whatever you’re using to back up your systems works on Linux, or that you’ve taken note of a Linux alternative.
It’s also worth spending some quality time getting to know the package manager on your preferred Linux distribution. The most common are yum (CentOS and variants), dpkg (Debian, Ubuntu), APT (Debian, Ubuntu), and RPM (RedHat). Most package managers will work on most Linux systems, but using a consistent set of binaries is critical to getting things working reliably, so sticking with one is best. Package managers pull down binaries from online repositories, and to get everything you need you may have to add additional or private repositories to the list your package manager uses.
Examination (Third Party Equivalents)
Check to see if your applications use third-party software components like database tools, application servers, or other middleware. Plenty of vendors have moved applications to Linux, but it’s really important to check and see if your off-the-shelf (OTS) applications have support, because you don’t want to have to port OTS apps yourself. We’ve ensured that ActivePerl, ActivePython, and ActiveTcl work not just on Linux, but also on HP-UX, Solaris, and AIX (as well as Windows and Mac), so if you’re using either of those dynamic languages your migration can be that much easier. But remember, not all databases, libraries, and applications are available on Linux, so take a look for Linux-based alternatives, and determine the severity of the changes they’ll have to undergo.
This step involves widening the area of involvement in your company. Get IT managers involved by having them look at the migration from its technical side (hiring and training new team members with relevant skills), business side (identifying the hardware resources to support applications on a new platform), and project management side (identifying the risks of the migration and creating a flexible schedule for development and testing). Get developers involved early on in this process so you can ensure you fully understand what you’re trying to do. The key to all this is preparation and communication. There will be hiccups along the way, but you can minimize them by hitting the problem early and from different angles.
Development and Testing
This is the most important part of your migration process, and you want to be both careful and thorough. Don’t make too many changes in each step when you modify your applications. For example: before you alter the source code, modify the build environment, then build your application on your current platform using new build tools, and run a full test cycle. You might also want to run Linux on a virtual machine and experiment with virtual networking. Basically, what you’re trying to do is break your systems, but isolate where it breaks. Establish a test environment sandbox where your team can learn without the fear of a production environment with major repercussions. And be sure to create a source archive for the code you’re rewriting so you can restore to an old image whenever you need to.
At this stage you want to broaden that area of involvement even further, and get the applications and systems owners, and business stakeholders, into the mix. You want to make sure everybody in the project is working toward the same goal. If you haven’t put together something to show why the migration makes business sense, do it. There will be operational changes and this is a way to help members of your team understand why the changes are necessary. And when you’re planning your migration schedule, it’s a good idea to be conservative about it because of the unknowns inherent in the process. If members of your team are concerned about the security and licensing involved in open source software, you might be able to assuage those concerns by working with a company that takes care of licensing and offers indemnity, like ActiveState.
Execution and Support
While you’ll never find the perfect time to migrate, there are some periods that are more viable than others. Hardware or software refreshes, uptime and compliance issues, mergers or other rapid transformations – these are all better times to migrate because you’re already disturbing the flow of business. And be ready for a different support system. You won’t have the 24/7 commercial support of HP-UX or Solaris; instead you’ll have the support of the community, which sometimes means you’ll have to do it on your own. There’s lots of free tech support online, but keep in mind that ActiveState offers enterprise-grade support on ActivePerl, ActivePython, and ActiveTcl products for Linux.
Migrations are often hard. It’s a disruption in workflow and technology, but you can do many things to smooth the process. Remember – even though Linux has a lot of similarities to Unix, it isn’t Unix, so dig in and learn! You’ll have plenty to keep you busy and it’ll be worth the effort to improve dev/test cycles, reduce your reliance on traditional clustering technologies, and sidestep maintenance costs.