Problem solve Get help with specific problems with your technologies, process and projects.

Porting applications from Unix to Linux

To port applications to Linux start with an in-depth discovery process, examining Unix application compatibility and determining whether they're compatible with Linux. The hardware platform and operating system distribution also need to be investigated and chosen, and then you can decide whether to upgrade or change applications based on specific compatibility and interoperability.

Editor's note: This is the third part in a series of articles on Unix-to-Linux migrations on

After making the business case for Linux and getting approval, you are ready for the actual porting process. Like any migration, there will likely be pain points that go with the process. Proper planning will go a long way to ensure success and ease those pain points.

The most important piece of migration is the initial assessment and discovery. Everything from hardware to software to operating system versions to patch levels to application versions must be carefully researched and documented. When porting your applications to Linux you will require all this information for developing your project plan. 

If an application you are looking to migrate to Linux is commercially available, check to see if the vendor supports Linux. Do the same with your database. All popular databases today run on Linux, but make sure you are not running some obscure system whose vendor is no longer in business.

It's also possible that you're running an old version of a modern database like Sybase, which may not be supported. In that case, you can still move to Linux, but your migration will be more difficult. Better to find out the bad news now rather than three months into your project.

You'll also need to decide which distribution you will use. With Linux, there is a range of choices. Generally speaking, in an enterprise environment you can't go wrong with either Red Hat RHEL or SUSE SLES enterprise versions. If your application is homegrown, work with your in-house development team to ensure that they will be able to migrate to Linux without doing an entire rewrite of the code.

Furthermore, you'll need to determine your hardware platform. Will you be running this environment on a clustered group of x86 computers or an HP Itanium? Work with your architectural team to determine the right platform for your code. It's likely it will be similar to the Unix system you had been using. For example, if your version of Unix was Solaris running on an x86 machine, you won't be moving it to an IBM mainframe. On the other hand, if you're looking to do a major server consolidation around IBM's System z mainframe architecture, you could be moving away from all your clustered x86 boxes and midrange Unix servers to that one platform. Linux is all about choices, and they are choices that you have with no other OS.

Sometimes the decision is more complicated. If you're a mixed shop and have a fair amount of AIX–which runs on IBM Power Systems–and you want to port a specific application to Linux, it might make the most sense to run Linux on those IBM Power Systems. In this case, you're keeping the same hardware platform, and you might not even have to purchase additional hardware because you can just create another logical partition on that same physical server.

What else needs to be done? You have to identify the project team–developers, architects, coders and administrators. After you receive funding and the project has been formally approved, you'll officially start with a kick-off meeting.

The application assessment is really important, and it is a little different than the infrastructure/server assessment. Find out everything you can about each application– dependencies, hard-coded IP addresses and service-level agreements, among other things. Find out whether each application functions on product-specific frameworks, such as IBM WebSphere. Understand all of the components of each application, and try to break down the components into smaller modular components.

If possible, find out how many lines of code are in the software and if it uses Unix pipes, message queues, shared memory signals or semaphores. Although these can be ported to Linux, make sure the Linux environment replicates the existing environment as much as possible.

Is any application multithreaded? Depending on your source platform, the complexity of keeping it multithreaded may be high. Make the application interview an important part of your process. The more information you find out early on, the easier things will go for you down the road.

The next part of the series on implementing the migration from Unix to Linux includes information on considerations for code and compilers, application upgrades and peformance testing.

ABOUT THE AUTHOR: Ken Milberg is the President and Managing consultant of PowerTCO (formerly known as Unix-Linux Solutions), a NY-based IBM Business Partner. He is a technology writer and site expert for and provides Linux technical information and support at

This was last published in February 2010

Dig Deeper on Unix-to-Linux migration

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.