Assessment and Analysis | Unix Application Migration Guide (Patterns & Practices)

The first step in your UNIX-to-Windows migration is to assess in detail all aspects of the application. This begins with the collation of information about the application, its context, and its user base that can be applied to an evaluation of your application s business and technical objectives. You can then assess the application and the environment in which it operates, including its development environment, user environment, and support environment.

You should consider both technological and cultural factors throughout the assessment, and should document any issues that you discover. These issues can be incorporated in the design of the migration plans and schedules.

You can accomplish only a high-level definition of the application porting at this point. Later in the migration process, you can develop initial prototypes of the application to help you decide whether a final port, a rewrite, the purchase of a software package, or some combination of approaches is the best way to conduct the migration.

The results of this assessment can help you determine the best approach to the application migration and define the migration strategy. You can review the migration strategy in conjunction with the issues that you documented during the analysis to ensure that they have been handled properly.

A full description of the assessment and analysis process is presented in Chapter 4, Assessment and Analysis.

Gathering Application Information

To determine the objectives of the application that you want to migrate from UNIX to Windows, you need an in-depth understanding of the application, how it is used, and its infrastructure and support environment. During this first part of the assessment, you gather all of the business, technical, operational, and other information that can help you determine the appropriate application-migration approach and make decisions during the migration process.

The following sources can provide information that will help you understand the objectives of the migration:

The application
The application s documentation
The current infrastructure
The development environment
The user base

The information you collect from these sources will allow you to develop a migration strategy, as shown in Figure 3.3.

Figure 3.3: The migration strategy

The following list contains some questions that can yield the information you need to make appropriate migration decisions (a more complete list is provided in Chapter 4, Assessment and Analysis ):

What does the application do?
How is the application built?
How does the application run?
How is the application accessed?
What does the user expect from the application?

Evaluating Business and Technical Objectives

When you evaluate the business and technical objectives, you establish a foundation for the migration. The evaluation should help you meet three goals:

Understand the business objectives for the application
Understand the technical objectives for the application
Understand the objectives of the migration

In many cases, the objective of a migration is to minimize redevelopment costs. Therefore, the evaluation does not have to be an exhaustive study, as would be required for a new application.

Business Objectives

Application requirements change over time, and it is not unusual to find that older applications no longer meet the users needs. You should verify that the application functionality is relevant to current business needs.

In addition, you should determine how the organization intends to use the application, because the use has significant bearing on the migration. For example, the plans could be to:

Significantly enhance the application.
Make minimal changes to the application.
Replace the application within a foreseeable timeframe.
Use the application as a basis for other applications.
Maintain common code across the UNIX and Windows platforms.

Technical Objectives

During the assessment, you should confirm that you understand the technical objectives of the application. In other words, how should the application be built and how should it run? Technical objectives include:

The service characteristics of the application (for example, scalability and availability).
The technical constraints on the application (for example, architectural restrictions or the need for specific protocols).
The portability requirements, as in whether the application has to run on multiple platforms.
The integration constraints, as defined by the number and types of other applications and services with which the application interfaces.

Understanding the technical objectives helps you determine how complex the application migration has to be, and what technical issues must be addressed during the migration process.

Migration Objectives

The migration process is driven by a number of key business factors. The motivation for migrating to a Windows environment must be clear. All parties involved should reach a consensus on the migration goals, because the goals have a significant effect on the decisions involved in planning a Unix-to-Windows migration.

The following examples are some reasons for migrating to Windows:

To reduce the total cost of ownership by deploying a homogeneous computing environment that is based on Windows
To improve integration with other applications running on Windows-based computers and servers
To enhance the application by implementing usability features that are based on the Microsoft Windows look and feel
To provide a greater range of hardware options that offer better choice and scalability
To integrate the application into a mobile computing environment
To accommodate dependencies on essential third-party products that are also being ported to Windows
To improve support by concentrating skills on the Windows platform
To create a UNIX-style development environment after the migration (for example, to accommodate developers who know UNIX but not Windows)

You should develop a clear idea of your own objectives because they affect the migration strategy that you choose. For example, a migration to achieve usability enhancements will have different requirements from one to provide improved integration.

Evaluating the Application

Before planning the migration, gather information about the application architecture, interface, and communication mechanisms; its internal structure; its build environment; its mode of deployment; and other supplementary information. Much of this information can be found in existing documentation.

Additional application-specific information can be useful:

The history, including the porting history (for example, whether the application has already been ported to UNIX environments such as BSD or System V)
The use of third-party development tools and libraries, including cross-platform facilities
The standards that the application supports, particularly proprietary standards
The management and support scenarios (for example, the use of monitoring tools and remote shells )

The evaluation can be supported with code-analysis tools. Code analysis is performed for many reasons, including:

Portability analysis (for example, to determine UNIX API dependencies)
Performance analysis (for example, to discover which portions of the code are accessed most often)
Conformance analysis (for example, to determine ANSI C/C++ conformance)

The results of this analysis help to determine the type and complexity of the application that is to be ported.

Note that a complete description of how to evaluate an application is provided in Chapter 4, Assessment and Analysis.

Defining the Migration Strategy

The evaluation of the application and its context is a significant factor in deciding the form of the migration. Additional strategic decisions are necessary, including these:

What is the target environment?
Do you need to maintain common code across UNIX and Windows platforms?

These decisions are summarized and documented in the migration strategy. You should deliver the migration strategy along with an overall infrastructure conceptual design that encompasses all of the migrated application s dependent infrastructure requirements, including the following aspects:

UNIX and Windows resource sharing (for example, file sharing)
Security and user-account synchronization (for example, integration and interoperability with Active Directory and Network Information System)
System and application management and support (for example, updates, packaging, and remote support)
System scalability and performance
Documentation migration

The migration strategy can consist of a quick port, a full port, a rewrite, coexistence of the old and the migrated application, or some combination of approaches. These strategies are presented in more detail in Chapter 4, Assessment and Analysis.

Quick-Port Strategy

Interix was introduced in Chapters 1 and 2 as a UNIX-conformant environment that runs on the Windows platform. When the results of the code analysis indicate that a port to Interix is the most appropriate migration strategy, a quick-port migration is the best approach. This is achieved by obtaining the source (for example, the archive) and installing it in the Interix development environment, modifying the configuration scripts and Makefiles, and building the application.

The ported application may be successful immediately, or it may require modifications to the configuration scripts or Makefiles to account for the new hardware platform, the target operating systems, and local configuration information.

You may not be able to determine whether a quick port is possible without actually conducting the port. The port may fail because:

The application proves too complex to be ported quickly.
Some parts of the application have to be rewritten for the port to be successful.
UNIX-environment dependence remains that cannot be accommodated by a quick port.
The quick port uncovers some new issues, or shows that your assumptions were incorrect.

Often, you can attempt a quick port as the first stage of the migration process. Then, if it does not work, you can use the results of the quick port as a basis for a full port or a rewrite.

Full Port Strategy

During a full port, the application is migrated with the minimum necessary changes to the source code and by using UNIX-compatible libraries and utilities that are available on the Windows platform (and that can include Interix). Unlike the quick port, however, a full port may require significant changes to enable the code to run on the new platform. This can happen when the original code is not fully standards-compliant, or when code elements (for example, device drivers) are specific to the original system.

The following are reasons for choosing to directly port an application to Windows:

Rewriting the code from scratch is seen as too costly or time consuming.
A large amount of source code exists.
The application requires cross-platform support (such that a single base of source code is maintained ).
The application makes use of a large number of UNIX APIs.
You want to retain the current look and feel of the UNIX application.
The integration with Windows-based applications can be achieved without a significant rewrite.

As long as the application functionality is tightly controlled, the full port strategy reduces the risk of negatively altering the application, because you preserve the business logic, retain the same user interface, reduce the need to for new documentation, and require virtually no retraining of end users.

Rewrite Strategy

A rewrite strategy is appropriate when the costs of porting the application may outweigh the benefits, or when specific application qualities (such as performance or scalability) require that code be written specifically for the Windows platform. Rewriting your application from scratch has a number of significant advantages:

In situations where a single platform is being used, a rewrite results in the maximum use of the advanced features of the native Windows environment.
A rewrite offers the best performance in a native Windows environment.

You may choose to rewrite an application to the Microsoft Win32 application programming interface for the following reasons:

Win32 features are required in new versions of the application.
Third-party applications are now available in the Win32 environment.
You intend to standardize your development environment on Microsoft Visual Studio .
Rewriting offers the best possible integration with other Windows “based applications.
The application s performance is critical; therefore, it should run as a native Windows “based application in the Windows environment.
Cost and time are not constraints.

A rewrite is potentially the most costly and time-consuming option. The solution based on this strategy requires a thorough analysis of the UNIX application functionality before a Win32-based redesign of the application architecture occurs, so that the rewrite of the UNIX code takes full advantage of the Windows application platform. This strategy has the greatest potential risk, but it also can produce the best results.

Coexistence

For coexistence, you port or rewrite the application, but retain the original application after deploying the new application. There are a number of reasons to choose this approach:

The two applications (source and migrated) are to be run in parallel to minimize risk.
A new set of users or customers will use the ported application, leaving the original users unaffected.
A staged migration between the original and the migrated application is planned.

If you plan to maintain coexistent applications, you should maintain parallel development and build environments to support all of the platforms on which the application will run (UNIX and Windows). Doing so may require a cross-platform source control system, such as Revision Control System (RCS), Source Code Control System (SCCS), Concurrent Version System (CVS), or Program Version Control System (PVCS). The native Windows source-control system is Microsoft Visual SourceSafe , which supports the cross-platform Source Code Control Interface (SCCI) API. Interix supports the Revision Control System.

Strategy Combinations

You may decide that it is appropriate to mix strategies. This often happens with large applications where certain portions can be rewritten, and others ported. You may choose to port and then rewrite the application to reduce the overall time requirements on the project, or to accommodate short- term time or budget constraints. For example, the migration could begin as a port and move forward as an incremental rewrite based on the integration or evolution of portions of the application. As in a port strategy, a common source-code base across UNIX and Windows can be retained. This strategy is similar to the way in which UNIX software is ported between UNIX platforms, because it allows developers to take advantage of platform-specific functionality.

To ensure that you have selected the most appropriate strategy, you should perform a cost-benefit analysis that weighs the benefits of the strategy against its costs. Part of the analysis should include the option not to migrate, but to buy an off-the-shelf Windows-based solution instead. The following are important business considerations:

Is the migration necessary?
What is the business risk of migrating?
Is the business impact acceptable?
Are the benefits worth the cost?

These questions can be used as a basis for determining the benefits, costs, and risks that may be associated with the migration. The analysis itself should be proportionate to the scale of the migration. Cost-benefit analysis techniques are presented in Chapter 4, Assessment and Analysis.