Introduction
If you are reading this, you are most likely considering a move from a proprietary platform to a UNIX-based open systems platform. You may be considering a move to open systems to achieve increased performance, to improve connectivity, or to reduce operating cost. These are among the top reasons why many companies, like yours, have already migrated to open systems.

In this text, we use the word migration to describe the procedures and methods employed to move data and programs to a new computing environment utilizing Unidata. The procedures and methods used successfully resolve the many operational differences between your platform and Unidata. Migration is not a single process but rather the execution of many methods and procedures that resolve the many possible incompatibilities. Each method or procedure targets a specific known incompatibility or issue. The first step in resolving an issue is detecting its existence in your application code or data. Often, detection can be accomplished through the use of specialized Strategy 7 migration tools that search your programs and data for a specific issue. Once detected, tools may automatically convert the offending code or data into a form that is acceptable to Unidata.

Many times, however, issues require manual examination in order to resolve properly the incompatibility.

To be clear, the migration process is not rocket science. It is a simple, structured methodology developed through experience to detect and correct incompatibilities.