## Migrating UNIX Technical Environments to Windows NT

### J. Scott Key

Hewlett-Packard Company
15815 SE 37th Street
Bellevue, Washington 98006-1898
Phone: (425) 644-3383
E-mail: Scott_Key@hp.com

This paper describes some of the tools and techniques for migrating and porting UNIX technical environments to Windows NT platforms. These tools and techniques attempt to provide some ideas for migrating a technical workstation environment to Windows NT on the assumption that the decision to migrate to NT has been thoughtfully made. These ideas are centered around the following two concerns;

- How to transition UNIX technical environments to Windows NT.
- How to port UNIX technical applications to Windows NT.

Windows NT systems are being integrated into the traditional technical UNIX environment. With this integration comes the challenge to ensure the engineers being provided NT workstations have the same functionality and environment that they have come to expect from their UNIX systems. This of course involves interoperability at the file/print and security levels. The transition of these systems into the technical environment includes the migration of the scripts and desktop environments for the continued access to the UNIX based technical applications and data. The quest for higher performance and seamless integration of engineering functionality onto an NT desktop platform may eventually require the migration of many parts of today's UNIX based technical applications to Windows NT. The decision to transition engineers, scientists and technical personnel to an NT platform must be balanced with the transition considerations of this platform;

- Are all required applications available?
- Is sufficient application performance available?
- Is the network infrastructure ready to support Windows NT?
- Can the current UNIX system environment be duplicated on Windows NT?
- Is the IT infrastructure ready to support Windows NT?
- Is there enough long-term cost and productivity justification in the transition?

Although, Windows NT is not UNIX, a transition to this platform for a technical workstation can be managed with the use of appropriate migration tools and techniques.

This migration to an NT platform has inherently three possible paths to pursue to implementation. These migration paths can be characterized as follows;

- Migrating all of the UNIX environment, data and code to Windows NT platforms.
- Migrating some of the UNIX environment, data or code to Windows NT workstations.
- Migrating only the minimal client piece to Windows NT while all data, production code and system environment remains centralized to UNIX.

Each of these paths has a cost associated with it. These costs can be described in terms of;

- Ease of migration.
- Risk to current systems infrastructure.
- Acceptance of current personnel.
- Impact on current system procedures and processes.

The amount of UNIX centricity or uniqueness imbedded into the tools, applications and processes will greatly effect the amount agony or pleasure in each of these cost factors.

Ease of Migration

The ease of migration cost can be described as how much effort is going to be required to move from a UNIX centric environment to the Windows NT centric environment. This would include how much information is UNIX unique. For instance, if data is to be migrated, is it uniquely UNIX binary data and thus a translation program must be written (tested, etc.) to move the data to NT. If software must be migrated, the question must be asked, does it use UNIX centric code? For example, assembly or Fortran language programs are inherently UNIX centric with little migration support for NT. In addition, is should be ascertained if the system environment scripts are using a standard like the Korn Shell or some other obscure shell scripting language or procedure. The final aspect is the availability of the source to the software, scripts, procedures and documentation for the current UNIX environment.

Risk to Current Systems Infrastructure

The risk to the current systems infrastructure needs to be assessed. This revolved around the concern of "breaking" or at least impacting to an appreciable degree, the current infrastructure. For example, NT 4.0 browsing service can increase the network traffic. The lack of consistent, interoperable file security may force a network file access method that is inconsistent with organizational goals. This can also require changes to such simple things as file backup methods and procedures. This would include such features as system monitoring and system wide resource sharing.

Acceptance of Current Personnel

There is also the cost associated with ensuring that personnel will accept and utilize the new environment. Since the UNIX application and system environment has become the standard system, it is important that all personnel be willing and able to move from this standard environment to the Windows NT systems. This entails ensuring that all personnel effected have been properly trained. This includes the software development team to provide a cost effective development base when moving to NT. It includes the system administrator training for the NT system tools and terminology. End user training must also be included so that they can be as productive in this migrated environment as they were on the legacy systems.

Impact on Current System Procedures and Processes

The UNIX system procedures and processes will undoubtedly be impacted by a migration to Windows NT. Such procedures to be assessed for migration will most likely include; software updates, operating system updates and patches, user configuration and security. The migration costs will depend on how much of even the mundane procedures such as system backups, operating system builds, workstation setup, etc. are dependent upon UNIX centric tools and applications.

The cost of migration from UNIX to Windows NT must be weighed against the functionality and seamless integration of the migrated applications with the standard UNIX systems and their associated technical environment. Along with the required functionality and integration, performance is a prime factor indicating which path the migration of the technical environment should take, as depicted in figure 1.

Figure 1: Paths for Migration of the Technical Desktop Environment to Windows NT Workstations

A total conversion and migration of the technical desktop environment from UNIX to Windows NT workstations could provide better interoperability with data, security and system infrastructure. In addition, performance of applications with high levels of GUI interaction may benefit from NT native hosting. Also, the outcome of this migration effort can be enhanced integration with Windows office applications like spreadsheets, email and the like.

There are tools for porting your UNIX applications to NT and there are tools for migrating or allowing your system scripts to run. The software porting tools like NuTCRACKER or OpenNT provide a basis for software development in a style like UNIX with make files and UNIX API's, but having direct WIN32 access for performance. UNIX Shell scripts can be moved over to with the help of such products as MKS Toolkit, Hamilton C Shell (from Hamilton Laboratories). Tools like Win-Emacs and MKS also provide UNIX style editors and some portions of a development environment.

The risks involved in this path are the ones associated with the costs involved in rewriting the applications to ensure maximum performance levels with Windows NT. Currently NT requires more network infrastructure out-of-the-box, due to such items as browsing and domain replication. All the users and IT staff will need training for the new applications and systems environment. This will require budgeting for training classes. In addition, systems procedures and process will need to be rewritten to accommodate the Window NT environment and GUI style. Since this is a total conversion to NT all the necessary legacy technical data will need to be converted and moved to the NT workstation environment. This will require developing data conversion applications but also the test suites for this conversion.

Migrating some of the UNIX environment

Porting and migrating only the necessary portions of the Technical Desktop Environment to Windows NT workstations require all of same types of tools as in migrating the entire environment. However, less code will need to be rewritten. A decision will need to be made as to which standards of communication, such as DCE/RPC, will be utilized between software in the NT and UNIX environments. Along with communication must come a standard data format so that each environment can retain and transfer the required technical data. For example, by default, HP-UX uses a byte ordering known as big endian and Windows NT uses a byte ordering known as little endian. This could be addressed by the HP-UX applications by using the "swab" routine to adjust the byte ordering of the data. This migration path allows for continued use of the UNIX Technical Desktops while phasing in the Windows NT workstation environment.

The challenge becomes one of providing a development environment that can produce applications and environments applicable to either UNIX or NT. In this area the trend is to develop code on a Windows NT workstation and "port back" if you will, that code onto UNIX. There are a few tools that can assist in this arena, such as OpenStudio and MainWin. These development environments provide a tool set to create C++ application from a single source stream for both platforms. Besides the cross platform development challenge, an opportunity exists to reduce the migration costs by ensuring that cross platform system management tools are put in place. That is, System management tools that can operate from either environment and manage either Windows NT or UNIX. This allows reduced training and higher productivity in regards to lower the impact to system procedures and processes. Omniback, JetAdmin, and Openview provide tools to span either NT or UNIX for system wide backups, printers or networks.

The risks involved in this path are similar in nature to the risks involved in migrating all of the UNIX environment to Windows NT. However the magnitude of the risk is less. That is to say that the network infrastructure will need to be expanded and application code will need to be rewritten. Training will still need to be provided to those developers, administrators and users effected. Following this migration path is less costly and risky since not all of the UNIX technical desktop systems and applications are being ported nor are all personnel being effected by the change. Some new system procedures and processes will most probably need to be created for the technical NT environment.

Migrating only the minimal client piece

The migration of the client or interface portion allow this path to provide for utilizing technical NT workstation and the Windows NT GUI as a "front end" to the technical applications and environment on UNIX. For example, this could entail providing an interface on an NT workstation to a technical database on a UNIX system. It could also be as simple as configuring an X Window from the NT platform onto the UNIX environment. This is the least amount of migration and only a moderate amount of interoperability or integration. In an environment such as this, the technical user is provided with the ability to run NT applications with minimal integration to the UNIX hosted applications.

An X Window emulator is one of the easiest methods to provide a simple window into the UNIX system. Some of the available emulators for Windows NT are;

Reflection X, WinTED and Exceed. In addition, a Telnet emulator is included with Windows NT. If a more integrated client/server environment is required, than tool kits with UNIX API's and development libraries may be required. These tool kits would be similar in nature as those discussed in the migration path of porting the entire UNIX environment to NT. These would include NuTCRACKER, OpenNT, MKS Toolkit and even DFS.

Although the risks are minimal with this type of migration, the performance of the applications will be constrained on the network performance. The network infrastructure will need to be expanded and some client application code will need to be rewritten. Training will still need to be provided to those developers, administrators and users effected. This migration path is less costly since few of the UNIX technical desktop systems or applications are being ported. Some new system procedures and processes will probably need to be created for the technical NT environment.

Conclusion

When each migration path is compared based upon the costs and possible performance as well as the level NT integration, a choice can then be made. This comparison is summarized in Table 1.

Migration Path | Ease of Migration | Risk to Current Systems Infrastructure | Acceptance of Current Personnel | Performance | Level of NT Integration
Migrating all of the UNIX environment | Difficult | High | High | High | High
Migrating some of the UNIX environment | Moderate | Moderate | Moderate | Moderate | Moderate
Migrating only the minimal client piece | Easy | Moderate | Low | Low | Low

Table 1: Migration path comparison summary

The migration path of moving some of the technical UNIX environment to Windows NT workstations provides a solid direction. This path could have the best opportunity in maintaining organizational integrity and high levels of business operations in this transition period. The following points should be used when considering how to migrate to Windows NT.

- Pick a networking standard. Use TCP/IP networking.
- Know that when implementing NT that the network infrastructure will need to be expanded.
- Suggest setting up your domains such that browsing can be turned off.
- Consider development environments that provide for both application construction in Windows NT and UNIX.
- Acquire system management tools that run in either environment and will manage either.
- Standardize on a file access method (SMB, NFS or DFS) that will have the interoperability, security and expandability required for the organization and business environment.
- Standardize on data formats such that interoperability, integration and data migration costs are minimized.
- Provide a security access and authentication standard like Kerberos and DCE.
- Provide adequate training to effected personnel. Particularly to development teams prior to designing the new environment.

The "how to" of migration is predicated on the thorough understanding of when and/or if a transition is cost effective and productive move for the Engineering, Scientific and technical personnel involved.