2.3 Assessing the Application Porting Effort

2.3.1 Limiting the Scope
2.3.2 Classifying Code
2.3.3 Scripts and Other Portable Components
2.3.4 Build Environment Dependencies
2.3.5 Assess Food Chain Dependencies

The most important part of migration process is the assessment of existing applications and the associated environment. This will allow you to create a risk list that can be used to identify any areas of the project that might require proof of concept to ensure that the project can be completed. The outcome of the assessment will be a risk list and a work breakdown structure that details the amount of effort required to migrate the application modules and the associated environment. The work breakdown structure can then used to create a plan and to schedule various activities.

During project execution, remember to allow sufficient time to follow Oracle recommended best practices as well as to time to re-architect some of the modules or to change the deployment strategy to get most from Oracle Linux. For custom, quickly evolving applications, it is important to freeze a snapshot of the application source code and associated infrastructure that can serve as a baseline for the migration activity.

The following sections discuss best practices that can greatly help in identifying the overall migration effort and potential areas of risk.

2.3.1 Limiting the Scope

Understanding the composition of the code used by an application is a critical part of the planning process. Since many legacy applications are large (millions of lines of code), simply trying to understand the layout of the source tree and the types of files can become a complex task. Developers seldom remove old, unused code from the source code directory, and seldom are there different build instructions for each targeted deployment scenario.

As an application evolves, new functionality gets added, some business functionality becomes redundant or irrelevant, and some modules are no longer required for a given deployment scenario. Hence, for a large application, understanding which files within the source distribution are actually getting used to build the application for the given deployment scenario can help limit the scope of the porting activity.

2.3.2 Classifying Code

Before starting the actual porting process, segregate the code based on the amount of migration effort required for each unit. This will allow you to estimate the overall effort required for the migration.

For example, if 80 percent of the code is portable (for example, Java) and if 10 percent is scripts, only the remaining 10 percent of the code might have bigger porting challenges and need more attention. The easiest way to arrive at this estimate is to segregate code based on the programming languages used for coding, and then evaluate each one of them separately for porting complexities.

As a rule of thumb, code written in Java, Perl scripts, and shell scripts should present fewer challenges compared to native modules written in the C, C++, or Visual C programming languages. However, you might come across projects with exceptions. The porting of scripts is one such area which needs careful planning and assessment. The following section discusses in more detail the potential issues during script migration.

2.3.3 Scripts and Other Portable Components

The Perl, PHP, and Python utilities are popular as scripting tools because of their power and flexibility as well as their availability on most platforms. However, the shell is still the scripting tool of choice for most developers, primarily because of its availability across a variety of platforms and environments. When assessing scripts, check the program that executes the script for the following conditions:

  • Whether the program is available on Oracle Linux.

  • Whether the program is in a different location and the location is not in the user's path.

  • Whether multiple implementations of the program are available on the system and PATH is picking up the right one.

  • Whether the program uses an option that does not exist on Oracle Linux.

  • Whether the program uses an option that has different functionality on Oracle Linux.

  • Whether the output of the program is different and is redirected.

2.3.4 Build Environment Dependencies

It is very important to choose the right set of tools and build environment in order to reduce the migration effort to the barest minimum. It should be noted that all popular open-source build tools (GNU/GPL) and utilities are available on Oracle Linux. It is much easier to transition to Oracle Linux if you can maintain the same build tools and build environment on the two systems.

The following points need to be taken into consideration while finalizing the target build environment:

  • Build tools and other build dependencies (gmake, dmake, make, ANT, and so on).

  • Tools used by the applications.

  • Command-line options provided by the tools.

2.3.5 Assess Food Chain Dependencies

Another very important factor that needs special attention is dependency on third-party components. For example, check whether the applications use or depend on the following:

  • Any third-party proprietary libraries available in the public domain as a ready-made binary (no source code).

  • Open source code or open source library.

  • The order in which symbols are resolved; that is, which symbols get resolved from which library if symbols with the same name are defined (implemented) in multiple libraries.

The most important part of the migration process is to check for the availability of these dependencies on the Oracle Linux platform, because sometimes the availability of a third-party dependency can become a limiting factor. Below are some guidelines that should not only help to reduce migration effort but also help the applications work better on Oracle Linux:

  • Choosing the right tools and libraries and, at times, changing the environment to a native implementation can be beneficial. In almost all cases, you will find that the return on investment (ROI) and operational improvements you gain by transitioning to an Oracle Linux implementation are compelling and significant.

  • Check whether you can upgrade to the latest libraries and scalable infrastructure without affecting the supported functionality of the existing applications.

  • Explore the availability of Oracle Linux features, infrastructure, and tools that can provide similar functionality.

  • Look for alternatives from different venders providing similar functionality.