Defining the Migration Strategy | Unix Application Migration Guide (Patterns & Practices)

Migrating a UNIX application to Windows 2000 may be as simple as recompiling, or it may require significant redesign and recoding. The amount of work required depends on how portable the application source code is to begin with, whether compatibility tools (such as Interix) are being used, and the intended use of the application on the target platform.

Now that you have set your objectives and evaluated the application, it is time to define a strategy for the migration. Chapter 3, The Migration Process, gave an overview of possible migration methods , including:

Quick port to Interix
Full port
Rewrite
Coexistence
Some combination of the preceding methods

You must now decide the most appropriate course of action for your own application. This is documented in the migration strategy, along with:

Testing/certification requirements.
An infrastructure conceptual design that covers the target platform, including all of the migrated application s infrastructure requirements, such as:
- UNIX and Windows resource sharing (for example, file sharing).
- Security and user account synchronization (for example, integration and interoperability of the Active Directory directory service and Network Information System [NIS]).
System and application management and support (for example, software updates and remote support).

Application Classification

A starting point in defining a migration strategy is to classify your application into one of the following four categories:

ANSI-based
ANSI with cross-platform libraries
Portable UNIX
Native UNIX

Table 4.4 provides a template to help determine an application s category. Based on the issues raised during the data gathering and analysis activities, it may be very clear how an application fits into one of the defined categories. In other cases, it may not be so clear which category the application fits into. In these cases, it is worth examining the application on a subsystem-by-subsystem basis, determining the best strategy for a given element of the application. The result should be a migration strategy defined for the application as a whole, which you can then verify against the issues raised during data gathering and analysis.

Table 4.4: Application Category
Category	ANSI C, C++, Fortran	ANSI with cross-platform libraries	Portable UNIX	Native UNIX
Level of use/dependency on UNIX API libraries	Low (insignificant)	Low (insignificant)	High (significant)	High (significant)
Use of cross-platform libraries	No	Yes	Yes or No	Yes or No
Use of third-party libraries	Yes or No	Yes or No	Yes or No	Yes or No
Use of third-party compilers	Yes or No	Yes or No	Yes (if supported on Interix) or No	Yes or No
High level of compatibility with existing code required	Yes	Yes	Yes	No
Standards the application supports	ANSI C, C++, Fortran	ANSI	Some Combination of: BSD, POSIX, System V, UNIX95, UNIX98, XPG	Some Combination of: BSD, POSIX, System V, UNIX95, UNIX98, XPG
Migration approach	Recompile to Windows	Recompile to Windows	Port to Interix	Rewrite to Windows
Possible issues/concerns	Performance of recompiled code	Third-party library vendor support on Windows	Cross-platform library vendor support on Windows (for example, Rogue Wave)	Performance of recompiled code
Windows Services for UNIX features are missing, or the customer is concerned about Microsoft support	Third-party library vendor support on Interix	Performance of ported code	Customer doesn t have time or resources for redesign and rewrite of the application	Third-party library vendor support on Windows

The following sections discuss the four application categories (ANSI-based, ANSI with cross-platform libraries, portable UNIX, and native UNIX) in greater detail. After you summarize the characteristics of the application and identify the application s category, you can further analyze potential migration approaches and strategies.

ANSI-Based

A pure ANSI-based code base should be portable to any platform that supports the ANSI standard, including Win32. However, use of third-party libraries may make a direct port more difficult or may make it unsuitable.

Case 1. No use of third-party libraries, or third-party libraries supported on Win32: Port to Win32 and Visual Studio.
Case 2. Third-party libraries supported on Interix:

Port to Interix with third-party library.
Case 3. Third-party libraries not supported on Win32 or Interix:

Contact library provider for support on Win32 or Interix.

If a Fortran code migration is required during an application migration from UNIX to Windows, Fortran needs to be an integral part of the design. Considerations such as performance, library interoperability, and feature set play key roles in the overall success of the project.

ANSI with Cross-Platform Libraries

Migrating a UNIX application that is dependent on a cross-platform library to Windows can be as simple as acquiring, installing, and configuring the Windows version of the library (for example, Rogue Wave SourcePro C++ or Trolltech s Qt product for Windows), recompiling; and then testing.

For example, Rogue Wave SourcePro C++ provides object-oriented C++ components designed for portability. Rogue Wave C++ interfaces are stable and, most important in the context of portability, are consistent across platforms. What this means in almost all cases is that a simple recompilation of code is all that you need to do to port from UNIX to Windows platforms. This assumes that the application is based entirely on Rogue Wave SourcePro C++, platform-independent language features, and any other libraries that satisfy the same platform portability features as provided by Rogue Wave.

However, this kind of a migration can require significant redesign and recoding.

Case 1. Cross-platform libraries supported on Win32:

Port to Win32, Visual Studio, with cross-platform library.
Case 2. Cross-platform libraries supported on Interix:

Port to Interix with cross-platform library.
Case 3. Cross-platform libraries not supported on Win32 or Interix:

Contact library provider for support on Win32 or Interix.

Portable UNIX

Portable UNIX is required when the customer needs or wants a high level of compatibility with existing UNIX software.

Case 1. Static applications (late in life cycle and stable code, little or no change planned): If no third-party/cross-platform libraries are required, port to Interix.
Case 2. Evolving applications (early in life cycle and still changing and being enhanced): Partition the application into static and dynamic components, and then port static portions to Interix and rewrite dynamic portions to Win32 and Visual Studio.

Native UNIX

Native UNIX is required when the customer needs or wants to take advantage of Windows or Microsoft .NET.

Case 1. Static applications (late in life cycle and stable code, little or no change planned): If no third-party/cross-platform libraries are required, rewrite the application to Win32 ( assuming resources, time, and desire ).
Case 2. Evolving applications (early in life cycle and still changing and being enhanced): Rewrite the application in Win32 and Visual Studio.

Migration Approaches by Application Type

During the analysis activities, you identified the type of your application; that is, whether it is designed to run on a workstation, a compute server, a database server, or a Web server. Each application type has certain attributes that make it more appropriate to either rewrite or port the application, as described in the following sections.

Workstation Applications

You must consider several factors when deciding whether to rewrite or port workstation applications. The number of processes involved, the interactions of those processes, and the type of user interface (for example, character-based or GUI-based) are critical to the decision to rewrite or port.

A small, single-process application with a character-based user interface will likely contain few systems calls, and therefore should be considered for a port to Win32. Multiple-process applications will contain many system calls for process management and interprocess communication. These APIs are quite different on Win32 from those on UNIX and will present challenges to the rewrite team. A port (to Interix) is recommended in this case.

OpenGL code, if stand-alone or not mixed with system calls or X Windows/Motif code, can be ported to the OpenGL environment on Windows, with minor changes. If there is a mixture, the migration strategy will depend on the mix.

Mid-Tier Applications

Message-based server application architectures allow for the choice of a strategy for each of multiple components, and you can employ a different strategy for each component. This chapter assumes that the application is based on a TCP/IP-based RPC mechanism (for example, ONC, distributed computing environment [DCE], or proprietary), sockets, or third-party messaging APIs. Sockets, ONC RPC, DCE RPC, and some third-party messaging layers are available in the Win32 subsystem, whereas proprietary APIs would need to be ported.

Different (and incompatible) versions of RPC exist for both UNIX and Windows 2000. On UNIX, it is common to have both ONC RPC and DCE RPC. Although these RPCs perform similar functions, their implementations and network marshaling specifications are different. ONC RPC uses External Data Representation (XDR) for network marshaling, whereas DCE RPC uses Network Data Representation (NDR) for marshaling. On Windows 2000, RPC is natively implemented using Microsoft RPC, which also uses NDR.

Sockets, ONC RPC, DCE RPC, and some third-party messaging layers are available in the Win32 subsystem (proprietary RPC environments would need to be ported). The availability of these messaging layer APIs enables the migration of UNIX applications by means of messaging mechanisms for interprocess communication to Windows.

Many of the native UNIX utilities, such as NFS and NIS, are implemented through Sun Microsystems s ONC RPC. Applications written for UNIX often either use these utilities or implement their own ONC RPC calls. If this type of application is migrated to Windows 2000, a development and client runtime will be needed to support ONC RPC. Tools such as Interix and NuTCRACKER provide support for ONC RPC. Additionally, shareware tools are available to support ONC RPC on Windows 2000.

A client/server architecture allows the choice of a migration strategy for each component. Provided that the networking APIs are available, you can evaluate each component individually as a separate program to decide whether to rewrite or port. Note that in some cases, the client component might already exist on the Windows platform.

Database Applications

The initial migration decision is about the database. In other words, you must determine whether to run the application s current database (for example, Oracle) on Windows (that is, migrate the existing database from UNIX to Windows) or migrate the database to Microsoft SQL Server .

In some cases, the best migration decision is a conversion to SQL Server. However, the investment in development and tools in the current UNIX database sometimes makes a conversion to SQL Server cost-prohibitive. This can be particularly true in an environment with significant UNIX/Oracle resources. Oracle offers a range of features available to both Windows 2000 and UNIX. You may choose to use these features with the current Oracle database, even if your overall goal is a migration to SQL Server. By separating the platform migration from the database migration, you have greater flexibility with the migration of their database applications.

Web Applications

Web applications from a UNIX Web server are normally one of two types: Common Gateway Interface (CGI) or Java Server Page (JSP).

The Common Gateway Interface is a standard for connecting external applications with information servers, such as Hypertext Transfer Protocol (HTTP) or Web servers. An HTML document that the Web server retrieves is static, meaning that it exists in a constant state. A CGI program is executed in real time so that it can generate dynamic information. For example, a CGI program on the Web service executes to transmit information to a database engine, retrieves result sets, and displays the result sets to the client browser.

The migration strategy for CGI programs or scripts depends on what language the program was written in. A CGI program can be written in any language that can access both types of environment variable and the standard input and output streams, and that allows the program to be executed on the system. Appropriate languages include C/C++, Fortran, Perl, Tcl, UNIX shells , and Visual Basic. Because of the powerful text-handling capability of the Visual Basic programming language, many Web developers write CGI programs in Visual Basic.

For example, CGI2ASP is a framework for porting programs written in Visual Basic, using Windows CGI (an O Reilly & Associates product), to a component-based ASP application with virtually no change to the existing Visual Basic-based code.

Java Server Page technology also allows for the development of dynamic Web pages. JSP technology uses Extensible Markup Language (XML) “like tags and scriptlets written in the Java programming language to encapsulate the logic that generates the content for the page. The application logic can reside in server-based resources (for example, the JavaBean component architecture) that the page accesses by using these tags and scriptlets. Any and all formatting (HTML or XML) tags are passed directly back to the response page. JSP scriptlets written in the Java programming language and residing in JavaBean components would be rewritten in Microsoft Visual Basic Scripting Edition or Microsoft JScript and contained in ASP Component Object Model (COM) components.

Migration Considerations

There are some additional considerations that you should apply to your migration approach. These considerations apply to the migration as a whole, and also to the specific type of migration that is planned.

General Considerations

Several key issues and considerations that you must take into account when migrating a UNIX application to Windows 2000 include:

Will a common code base that is deployable across UNIX and Windows platforms be built, maintained , and evolved?
To what degree will Windows 2000 features be added to improve the installation, performance, and/or usability of the migrated application?
To what extent will the UNIX and Windows versions of the software need to interoperate across platforms?
Does the application or certain components of the application require temporary or long- term ongoing deployment across both UNIX and Windows platforms? Is the plan to deploy Windows 2000 workstations while retaining existing UNIX platforms, or are the UNIX platforms being replaced with Windows 2000?
As new features and/or fixes to defects are applied, can they be applied only once to one common code base that can be deployed everywhere, or are there separate code bases that must be maintained and evolved independently for each target platform?

Quick Code Port to Interix

Table 4.5 provides some information about the standards that Windows Services for UNIX/Interix supports:

Table 4.5: Standards Supported in Windows Services for UNIX and Interix
POSIX Standard	Description	Windows Services for UNIX/Interix Support
POSIX.1-1990	System interfaces and headers	Yes
POSIX.2-1992	Shell and utilities	Yes
POSIX.1b-1993	Real-time extensions	No
POSIX.1c-1996	Threads extensions	Future release
POSIX.2a-1992	Interactive shell and utilities	Utilities, not all options supported
XPG4	XPG Base Branding	No
XPG4v2	Superset of XPG4 (UNIX95 Branding )	No
XPG5	Single UNIX Std v2 (UNIX98 Branding )	No

Windows Services for UNIX/Interix often support a superset of behaviors. For example, there are two ways to determine the pseudo-terminal name to use, one BSD-based and the other SVID; Interix supports both ways. Therefore, Interix supports POSIX.1, POSIX.2, ISO C, and XPG4. For example, if an application to be migrated claims to support POSIX.1b-1993, POSIX.1c-1996, UNIX98, and/or XPG4.2, porting to Interix might be difficult or impossible , depending on the degree of support required for any or all of those standards.

Note	UNIX daemons can be implemented as services in Windows for either an Interix port, a Win32 port, or a Win32 rewrite.

Windows does not support POSIX-conformant thread APIs natively (Win32 or Windows Services for UNIX/Interix). Purchasing or obtaining a third-party POSIX thread wrapper (gradient for Win32, Florida State for Windows Services for UNIX/Interix) to the native Windows threads implementation is required.

Windows with Win32 does not support UNIX System V IPC, including message queues, shared memory, and semaphores. However, Windows with Windows Services for UNIX/Interix does.

Rewriting the Application

The reasons for undertaking a rewrite of an application usually hinge on whether the benefits of the rewrite are more valuable than the effort required to perform the rewrite. To accurately make this judgment, the task must be properly scoped.

Some of the reasons for choosing to rewrite an application to the Win32 API include the following:

New versions of the application are planned that require the use of Win32 features.
Dependencies with third-party applications are now available in native Windows (Win32) implementations.
Migration to a full Visual Studio development environment is wanted and/or required.
Scripting solutions (for example, Windows Services for UNIX or Interix) are available on Windows.

If the application migration assessment determines that a rewrite of the UNIX application to Win32 and Visual Studio is the preferred approach, also consider the following:

Is the application defined in layers where the business code is separate from operating system dependent features such as GUIs and I/O?
Will operating system differences be confined to separate modules, or will techniques such as compiler directives (#ifdefs) be used to isolate differences?
Will both a UNIX version and Windows version of the application be maintained over a period of time? If so, on which platform will most of the development occur?
Have proper versions of any third-party tools (for example, ONC RPC) been identified?
Have you addressed exception handling (Win32 as compared to UNIX C/C++ signals)?
Have you addressed event handling in the GUI?

The X Windows (Xlib) GUI can be converted to Windows GUI. Most of the functions of Xlib (a message handling library for UNIX) can be mapped to the Win32 message-handling functions. Some of these equivalencies are shown in Table 4.6.

Table 4.6: Xlib and Win32 Event Handling Equivalencies
Xlib Event Handling Functions	Win32 Event Handling Functions
XNextEvent()	GetMessage(hwnd=NULL)
XPeekEvent()	PeekMessage(PM_NOREMOVE)
XIfEvent( )	No equivalent
XWindowEvent( )	GetEvent(w)
XSendEvent()	SendMessage(), PostMessage()

Note	The X Windows event filtering mechanism is more comprehensive than that in Win32.

You can create a Windows look and feel by rewriting the GUI with Visual C++, Microsoft Foundation Classes (MFC), or Visual Basic, but this effort may not be cost-effective . A migration strategy can provide a Windows look to existing X Windows and Motif applications if you use Interix, NuTCRACKER, or Cygwin.

In addition, you should address the following:

Process orientation (UNIX) conversion to thread orientation (Windows). A threaded architecture allows an application to make optimal use of Windows 2000 and the underlying hardware, but will be an extensive undertaking if the application was not threaded on UNIX.

Note
Interix does not support threads (for example, POSIX pthreads), so this is also potentially an issue in a migration situation.
I/O implementation and performance. For example, consider selecting the appropriate Win32 API functions instead of the C/C++ run-time library.
Memory management. For example, consider selecting the appropriate Win32 API functions instead of the C/C++ run-time library.
Libraries. Consider using dynamic-link libraries (DLLs) instead of UNIX (dynamic and static) shared libraries.
Template library. Consider the C++ Standard Template Library (STL) and the role of the Active Template Library (ATL).
UNIX daemon conversion to Windows service. Typically, a UNIX daemon is best implemented as a Windows service.
Application administration. Determine whether you want to take advantage of Windows administration and add new functionality.
Installation. Consider implementing Windows-style installation.
Configuration information. Determine how you will address use of the Windows registry.
Icons and localization. Consider adding Windows resources for icons and localization.
Event logging. Decide whether you want to use the Windows 2000 Event Log.
Integration with other Windows-based applications. For example, consider using Microsoft ActiveX and COM+ services.

In addition, you should have a backup plan for the rewrite in case the rewrite effort becomes a roadblock in the migration.

Note

Because Microsoft provides only the GNU Fortran 77 compiler for Interix, most Fortran applications need to use a Fortran compiler available for Win32. The migration to Win32 will either be a code port to Win32 or a rewrite for Win32, depending on how much platform-specific code exists in the Fortran source.

Full Port

Some of the reasons for choosing to directly port an application to Windows 2000 include the following:

The total cost of rewriting the application is greater than the projected return on investment (ROI) savings.
The time to deliver a rewrite of application is schedule prohibitive, but a port can be accomplished within time constraints of overall migration project.
The risks of an application rewrite are greater than the expected business value (for example, the rewrite cannot guarantee the preservation of business logic; the interface will change substantially, which will result in end-user retraining costs; there is inadequate documentation to facilitate the rewrite; and/or the business logic and user interface are comingled).
There is a large amount of source code.
Support (and development) for both Windows and UNIX platform versions of the application must continue for the foreseeable future, and support for a single source base is wanted.
The application frequently uses UNIX APIs (as compared with frequently using C Library calls).
Dependencies (for example, communications) with third-party applications that now are available in native Win32 implementations can be achieved with a simple Win32 application that communicates between the Win32 subsystem applications and the Interix subsystem ported applications.
The same look and feel of the application on both the Windows and UNIX platforms is required or wanted.

Coexistence

You may require that both the Windows and UNIX versions of the application coexist for a number of reasons; for example, to mitigate risks, or to support independent user bases. In situations where you expect development for both Windows and UNIX versions of the application to continue in the future, consider the following:

The application should be defined in layers where the business code is separate from operating-system-dependent features such as hardware dependencies, GUIs, and operating system services.
Any features dependent on POSIX compliance should be located in separate modules, or techniques such as compiler directives (#ifdefs) should be used, to isolate differences between the Interix/Windows and UNIX versions of the application.
The correct versions of third-party tools, such as ONC RPC or X Windows emulators, must be available and supported in both the Interix/Windows and UNIX platforms.
A common source control system must be defined, designed, and implemented. The requirements for this system normally include multiple-user source check-out , server-based source merge facility (to resolve change conflicts), group -level source synchronization, and function-level linking.
If integration is required with other Windows-based applications, either Win32 APIs will be necessary within the application, or possibly a COM component can be implemented to provide a binary interface between the ported application and the Windows-based applications. When Win32 API integration is a requirement, NuTCRACKER may be the solution, because it provides the capability to have a mixture of both UNIX and Win32 APIs within the same application on Windows 2000.
Tools like Windows Services for UNIX/Interix and NuTCRACKER provide mappings from UNIX-style security to Windows 2000 “style security (for example, User Name Mapping Server from Windows Services for UNIX). However, if Windows 2000 “style security is wanted, the application must be built on the Win32 subsystem regardless of migration strategy.

Strategy Combinations

The final migration strategy is unlikely to specify a single approach to migrating the whole application. More likely, you must give each element of the application a migration strategy of its own, or you must group and associate several elements with a migration strategy. For each element of the application, you must apply the migration process described in this chapter.

In addition, the migration strategy does not need to take place in a single step, but can include short-term and longer-term considerations. For example, you might decide to port and then rewrite the application in its entirety, or you might decide to port the application and then rewrite specific elements after additional resources become available.

Scripts Migration Approach

After you summarize the characteristics of the application s scripting environment, you can analyze potential migration approaches. The potential migration approaches are discussed in the sections that follow.

Rewriting Scripts

If the application will be rewritten for Windows, rewriting the scripts to a Windows-style script (for example, Windows Scripting Host [WSH]) is the most appropriate solution. WSH scripts provide logical constructs and operating system integration similar to those provided by UNIX shell scripts. The following list provides additional reasons for considering a rewrite of UNIX scripts to WSH:

A limited number of UNIX scripts exist.
The application takes advantage of other Windows-based applications (such as Microsoft Exchange and SQL Server) that offer WSH interfaces.

Using ActiveState Perl (Win32) or Perl v5.6 (Interix)

If the UNIX scripts are predominately written in Perl, consider using ActiveState Perl on Windows. Also, Windows Services for UNIX provides both ActiveState Perl and Perl v5.6 as some of its features.

Perl scripts will require some conversion ” mainly , the workarounds required by the differences between the Win32 environment and the open systems environment (for example, file path syntax). This option is usually more applicable when the UNIX style shell script must interact with other Win32 programs.

Porting Scripts Using Windows Services for UNIX/Interix

UNIX shell scripts can be run natively by means of the Windows Services for UNIX/Interix subsystem. This option is particularly useful for implementing remote maintenance scripts, or in conjunction with applications migrated to Windows 2000 through Interix.

Interix is the best choice when you require a scripting environment and utilities that behave exactly as defined in key open systems standards and specifications ”such as POSIX and the Single UNIX Specification. For example, you should choose Interix if you have a very detailed and complex Korn or C shell script that makes use of a large number of standard UNIX utilities (for example, POSIX 2 utilities).

Cost-Benefit Analysis

A cost-benefit analysis is an assessment of the benefits of a given option, balanced against the costs of implementing the option. There is little point in conducting an expensive migration when there is little benefit to be gained ; also, many migration options are prohibitively expensive, even if the benefits are tangible . The costs of the migration can be considered in terms of the size of the application to be migrated, and therefore the effort required for the migration.

Cost-benefit analysis is discussed in more detail in Chapter 5, Planning the Migration.

Choosing the Migration Strategy

This guide provides three decision matrices that can help you use the data that you have collected and analyzed to determine which migration strategy is most appropriate for your application.

The decision matrices are as follows :

Business objective data analysis

Use this matrix to determine the best migration strategy based solely on your business objectives. Technical realities in the next matrix may require you to modify this matrix.
Technical requirements data analysis

Using the result from the business objective data analysis matrix, you should now further refine your decision by using the technical data that you have collected. This matrix allows you to take into consideration the major technical issues that impinge on your migration.

It is possible for there to be a conflict between the business requirements and the technical requirements. If this is the case, you will need to do further analysis to determine the best course of action. Typically, there will be a cost associated in overcoming the conflict, and a cost-benefit analysis will be necessary.
Final analysis

The previous two matrices may have been unable to give you a definitive strategy. If this is the case, the final analysis matrix will help you further clarify your strategy.

After you have worked through these matrices, you should know which strategy will be most effective for your application and business environment. Now that you have a migration strategy, the next step is to plan your migration.

Migration planning is covered in Chapter 5, Planning the Migration.