Chapter 2: Envisioning Phase: Beginning Your Migration Project

Article
12/05/2007

This chapter provides the background and technical information required to complete the first phase of a migration project, the Envisioning Phase.

Introduction to the Envisioning Phase

The Envisioning Phase represents an early form of planning. The purpose of this phase is to get the project started by achieving a basic agreement between the business and IT on the goals of the project, as well as its constraints. This chapter provides guidance on ways to break down the various decisions and analyses that must be made into manageable steps. It also offers guidance on practical tasks such as organizing the team. The decision-making activities are designed to minimize project risk by helping to ensure that decisions are aligned with broader organizational goals and are based on a careful assessment of the current environment and input from all key stakeholders.

This guide makes the following basic assumptions about the state of the organization at the beginning of the Envisioning Phase:

The IT manager has decided to investigate the project and has sufficient budgetary authority to fund the investigation (Envisioning and Planning Phases). However, the IT manager may or may not have sufficient budgetary authority to approve the entire project.
Rough estimates indicate that the project’s benefits will exceed its costs, but detailed return on investment (ROI) calculations cannot be made until the project scope is defined.

Envisioning Phase Tasks

The major migration tasks conducted during the Envisioning Phase are summarized in the following list. They will be described in more detail in the following sections.

Set up the team. The Program Manager assembles a core project team, representing all six MSF Team Model roles.
Define the project structure. The Program Manager creates the project structure, which describes the administrative structure for the project team going into the Planning Phase. It also establishes the standards the team will use to manage and support the project.
Define the business goals. The team identifies the business problems or opportunities in order to determine the objectives for the solution.
Assess the current situation. The team assesses the current state of the business and performs a gap analysis to help identify a path toward the desired state of the business.
Create the vision and define the scope for the project. This includes creating a vision statement to guide the team toward its business goals and identifying a project scope to define what will and will not be included in the project.
Define high-level requirements. This includes determining the needs of each key stakeholder, sponsor, and end user in order to provide input regarding the formation of the solution concept, to provide criteria for evaluating the vision/scope document, and to provide a basis for detailed requirements in the Planning Phase.
Develop the solution concept. This includes creating an initial concept of the migration approach that will best meet business goals and technical requirements. This serves as a baseline and sets the stage for the more formal design of the solution.
Assess risk. The team identifies and qualifies any high-level risks that might affect the project.
Close the Envisioning Phase. The team agrees that they have achieved the Vision/Scope Approved Milestone by formally signing off on the documentation that records the results of the Envisioning Phase tasks.

Note Although listed sequentially, many of these activities can be performed concurrently.

Envisioning Phase Deliverables

The Envisioning Phase activities culminate in a major milestone, the Vision/Scope Approved Milestone. By the end of the Envisioning Phase, the project team and all major stakeholders (other members of the organization who will be affected by the project) should have agreed upon the following conceptual areas and documented their understanding in the appropriate documents. This includes:

A project structure document that:
- Describes and maps all MSF team roles.
- Defines a project structure and hierarchy for the team to follow.
- Defines the process standards for the team to follow.
A vision statement that:
- Defines the business opportunities or problems that the solution is expected to address, including major business and user requirements.
- Describes the current state of the customer's environment at a high level, with respect to the technology under consideration.
- Describes the desired future state of the organization's environment from an unbounded viewpoint.
A scope definition that:
- Defines the projects to be executed as part of the solution, based on business implications and technologies involved.
- Lists the new features and functions that the project provides: the in-scope and the out-of-scope items.
- Distinguishes between the scope of the solution and the scope of the project in cases where the solution will be implemented in stages or will require discrete projects to be run in parallel.
- Provides a rough estimate of the project time frame and duration.
A solution concept definition that:
- Identifies the appropriate migration method and technology for the business problem like Microsoft Windows® Services for UNIX, Win32®/Win64, or .NET.
- Describes at a high level how the solution will solve the business problem in terms of the approaches that will be followed to build and deliver the solution.
- Documents business goals, design goals, and the required functionality of the solution.
- Calls out assumptions and constraints that apply to the solution.
- Defines the success criteria for the project.
A risk assessment document that:
- Assesses and identifies project risks.
- Attempts to qualify and prioritize these risks.

Together, these deliverables (documents) comprise a high-level description of the project that forms the basis for further planning. They represent a baseline and may need to be revised as the planning progresses and new information dictates. The vision/scope document, especially, must be viewed as a living document that keep changing, subject to change control.

Note For more detailed discussions on how these tasks and deliverables can be approached and the responsibilities assigned for them, refer to the Unix Migration Project Guide (UMPG) at https://www.microsoft.com/technet/itsolutions/cits/interopmigration/unix/umpg/default.mspx.

Envisioning Phase Activities In-Depth

The following sections describe in depth the various activities involved in the Envisioning Phase of the MSF Process Model and how these activities specifically relate to a migration project.

Setting Up a Team

You need to assemble a core team first, based on the six roles defined in the MSF Process Model and with defined skill sets appropriate to the project. Once assembled, the team will be involved in defining the vision and scope that together provide a clear direction for the project and set the expectations for the project within the organization. Although the team as a whole is responsible for the project’s success, each of the roles focuses on a distinct quality goal to ensure that responsibility is taken for implementing different aspects of the project.

Each role may be filled by one or several persons, depending on the size of the project. Some roles, such as Development and Test, are likely to be filled by entire subteams. In this case, the core team member acts as the lead for the subteam, and the guide frequently refers to the role as a team (for example, the Development team).

See the “Project Team Skills” job aid”, a Word template that helps with assembling the project team by identifying the particular skills that are needed in each role (or subteam) for a UNIX application migration project.

The six roles are:

Product Management Role. The Product Management Role acts as the interface between the customer and the project team by ensuring that the team addresses the customer’s requirements and concerns.
Program Management Role. The Program Management Role is responsible for leading the team in making decisions and driving the project schedule and project plan. Program Management owns responsibility for all internal team communication and ensuring adherence to corporate and project standards.
Development Role. The Development Role is responsible for designing, building, and unit testing the baseline code. Development drives the architecture and physical design of the solution, estimates the effort required, and then builds the solution.
Test Role. The Test Role is responsible for testing the components, architecture, and associated documentation against the functional specifications and ensuring that they meet requirements.
User Experience Role. The User Experience Role advocates for the end user and defines the requirements for functionality from the end-user perspective. They are also involved in other critical activities such as development of help and support documentation and training.
Release Management Role. The Release Management Role participates in the design process to ensure that the completed solution is deployable, manageable, and supportable. This role interacts with the product support, help desk, and other delivery channels with a focus on smooth deployment and ongoing management.

Note Depending on your business goals, some of these roles may not be necessary in the context of your organization. To understand these roles and their responsibilities, refer to the Project Team Skills Job Aid which is provided along with this guide.

Defining the Project Structure

The project structure defines how the team manages and supports the project and describes the administrative structure for the project team going into the subsequent project phases. The main function of the project structure is to define standards that the team will use during the project. Program Management takes the lead in defining the project structure. The major standards that are defined as part of this process are:

Defining project communications. A communication standard should be defined as part of the project structure for the team members to follow. Among these standards can be a definition of the hierarchy under which team members operate, procedures to escalate project issues, regularly mandated status meetings, and any other project-specific communication standard that needs to be defined at the beginning of the project.
Defining documentation standards. The project structure also defines standards on how to create training materials and documentation related to the project, including standards that prescribe the templates and applications the team should use to create documents.
Defining change control. The project structure should include change control standards. These standards may apply to two distinct areas: the solution content and the documents that describe the content, such as the functional specification. For solution content, change control standards can include prescribed daily builds and the use of source control and versioning software.

Interim Milestone: Core Team Organized

This milestone marks the point at which the key team members have been assigned to specific roles in the team and the team has been organized.

Defining Business Goals

Business goals are established either to take advantage of an opportunity or to solve a problem in the current business. The problem/opportunities statement for the project leads to the creation of a team vision for the project. It also clearly articulates the objectives for the project and ensures that the solution supports the business requirements.

For migration projects, it would be helpful to consider the goals satisfied by the existing application or infrastructure as a way of identifying new or extended goals. However, justification for the migration project should exceed the justification for the initial work. Common business goals for migrating existing UNIX applications include:

Reducing the total cost of ownership (TCO).
Creating an environment that integrates all organizational processes.
Increasing the scalability, manageability, performance, and flexibility of all organizational applications.
Reducing the development time for the applications.
Expanding the existing application capabilities.
Replacing the existing UNIX applications.
Internationalizing or localizing the agility of products.
Extending the availability of the application to special devices (for example, Tablet PCs).

Assessing the Current Situation

After setting up a team to migrate your applications and defining the business goals, the next step is to assess your current situation. At this stage, you must measure the gap between where you are today and where your application will be after your vision is realized. This step is very critical because it reveals the effort that each migration approach will require, which can ultimately determine the direction your migration project will take.

This guide provides two tools that help you decide upon a migration approach by using information about your current situation and goals. The primary tool, the Migration Approach Assessment Tool, is a Microsoft Excel®-based tool that lists certain assessment questions, which are divided into three levels based on the business, architecture, and technology requirements of the current situation. Answer the relevant questions that are applicable to your environment with appropriate answers. At the end of the assessment, the tool will evaluate the requirements and their weights and will provide the suggested migration approach that is most suitable for your migration.

A supporting tool, the UNIX Application Source Code API Analysis Tool, also written in Excel, allows you to identify various UNIX APIs used in the source code of a UNIX application. The tool reports the level of use of each API as a percentage of the source code. For example, you might discover that SNMP APIs are used in 20 percent of your code. This is important because it will help you identify the effort that the migration process might require based on the APIs used in your application.

These two tools are both available in the Tools and Templates folder in the download version of this guide.

The following sources in your organization can help you answer these questions:

Source code of the application
Application documentation
Stakeholders and business partners
Current infrastructure
Development team
User base

Creating the Vision and Defining the Scope

Delineating the project vision and identifying the scope are distinct activities: Vision is an unbounded view of what a solution may be, whereas solution scope identifies the part or parts of the vision to be provided in a version of the solution. These are critical for migration projects because migration projects involve replacing an existing system, and the fastest path to success is achieved by tightly restricting the scope of change to minimize the addition of features beyond those delivered solely through the migration itself.

Creating the Project Vision

Before you proceed, it is important to define a vision for the solution that addresses your business goals. The vision describes the desired future state of your application environment. It may be crafted by a project team or be handed down by the business and negotiated as needed, and it is documented in the vision/scope document. The vision that guided the development of the existing implementation of an application or infrastructure component should serve as a major source in developing the vision statement for a migration project. A vision statement is always from an unbounded viewpoint, that is, an ideal world, what one strives to achieve given all necessary resources. Examples of vision statements are:

We will increase the market share of our product by making it available on Windows.
All the applications in the organization should run on both UNIX and Windows platforms.

Defining the Solution Scope

The solution scope places a boundary around the migration process by defining the range of features and functions mapping to your business goals that can be achieved. You can do this by defining what is out of scope and cannot be achieved, and by discussing the criteria by which the end users will accept the migration. Define the solution scope as part of your migration; it will be the basis for defining the project scope and for performing many types of project and operations planning.

Defining the solution scope may involve some of the following activities:

Determining whether the entire application will be migrated or only some specific modules of the application.
Identifying the third-party libraries or tools to be used during migration.
Identifying the modules that will need to be recompiled during migration.
Identifying the modules that need to be rewritten or redesigned during migration.
Defining the acceptance criteria for performance of the migrated application on Windows.
Determining the business goals that can be achieved, along with those that cannot be achieved.

Defining the Project Scope

As part of defining the solution scope for migration, you must define the different projects that need to be undertaken. The project scope defines what work the team will perform on the project—and what work it will not perform. The project scope applies the constraints imposed on the project (by resources, time, and other limiting factors) to the overall solution vision expressed in the vision statement. The solution scope and project scope are interdependent activities.

When defining your project scope you need to:

Explain and clarify the planned intentions and deliverables of the project so that you can manage the expectations of the project stakeholders.
Ensure that the resources and schedules for the projects are well defined and bounded.
Confirm objectives and timescales for the migration so that you can manage expectations, recruit appropriate resources, and allocate tasks as necessary.

It is quite possible that multiple projects are identified—for example, one for back-end databases and one for specific user-facing applications. In this case, the project scope enables each project to be defined and any dependencies to be identified so that the migrations can take place as independently as possible.

The end of the Envisioning Phase is marked by the completion of the first milestone where the migration team agrees on the overall vision and scope of the project. The vision is the complete view of what the solution can be, based on refining the original idea. On the other hand, the scope establishes restrictions on the vision to establish what can be accomplished within the constraints of the project.

Note The project scope is the definition of success. It tells you when you are done. If you do not reach a true "meeting of the minds" between the stakeholders and project staff, significant time or cost overruns, or even project failure, will occur. For more information, see the UMPG.

Interim Milestone: Vision/Scope Document Baselined

At this stage of your migration, you ought to have outlined your vision/scope document, which also includes business goals, your high-level requirements, and the Windows technology to which you will be migrating. You should have analyzed and decided whether your application will be migrated in parts or in entirety. This decision needs to be made after repeated discussions with your team and feedback from the application customers and stakeholders has been considered.

The vision/scope document represents the result of the team's work in defining the vision for the soluton and project scope. The process of working on this document as a team ensures that everyone on the team shares and understands the goals of the project. This helps each team member to work effectively toward the successful completion of the project. You are now ready to start defining the high-level requirements for your migration project.

Defining High–Level Requirements

After creating the vision statement, your core team must define a set of high-level requirements and features that map to achieving the business goals driving your vision. It is recommended that you adopt the use of versioned releases while defining the high-level requirements. Versioned releases help the project team respond to ongoing changes in scope, schedule, and project risk. In a migration project, the first release might be to migrate core functionality. Subsequent releases would migrate additional functionality or extend the migrated component to meet new customer needs.

The high-level requirements can fall into any of the following categories:

Business or functional requirements
Operating environment requirements
Performance requirements
Standards requirements

For example, if your vision is to improve the performance efficiency of the existing UNIX applications on Windows, then some of the high-level requirements that need to be defined are:

What is the performance efficiency (in percent) you want to achieve?
Should this performance efficiency be constant at all times?
What is the maximum deviation from this efficiency that you can tolerate?

You need to perform the following activities as part of your requirements definition:

Documenting requirements for the migrated application.
Preparing the acceptance criteria.
Reviewing the requirements and acceptance criteria.
Obtaining a sign-off on the requirements from application users, such as customers and stake holders.

Another critical factor to be considered when defining high-level requirements is the environmental profile. Environment includes everything that is outside the application but affects the application in one way or another. It is important to consider these external factors too, which either impose restrictions on or anticipate certain behavior from the application.

Environmental Profile

These external factors should be captured as high-level requirements to be tested in the migrated application. Examples include:

Software systems that interact with the migrated application and impose such constraints as:
- Time limitations (for example, batch jobs or data transfer time).
- Communication requirements (for example, protocol support).
- Performance metrics (processing per time unit).
Privacy policies (for example, affects use of the software clipboard).
Security requirements.
IT operations, including:
- Backup.
- Maintenance windows.
- Management and deployment.
Legal guidelines for data retention. Legal requirements must be clearly understood and stated, including what needs to be done to adhere to these requirements. According to Sarbanes-Oxley records and data retention mandates, digital information should be available and protected from loss, compromise, or corruption. Corporate records managers are responsible for ensuring that electronic business records are properly retained to be available for audits, litigation, or compliance investigations.
Robustness criteria of availability.

Developing the Solution Concept

The solution concept outlines the path for achieving your business goals and provides the basis for moving into the Planning Phase. After your team has identified the business problem and defined the vision and scope, it creates the solution concept. It is important to understand the target environment for the application migration while coming up with the solution concept. Examples include:

Migration to a Portable Operating System Interface for UNIX (POSIX) environment on Windows, such as Windows Services for UNIX 3.5.
Migration to Microsoft Windows Server™ 2003 using Microsoft Win32/Win64.
Migration of UNIX application to .NET Framework.
Continued development on UNIX with Windows as a cross-platform migration.

When developing the solution concept, it can be helpful to concentrate less on specific technologies and more on the ways the technology can deliver the business value requirements. When determining whether a solution concept meets a team’s needs, some important criteria to consider are:

Project success factors.
Operational concept.
Acceptance criteria.

The purpose of the solution concept is to:

Provide teams with limited but sufficient detail to prove the solution to be complete and correct.
Perform several types of analysis including feasibility study, risk analysis, usability study, and performance analysis.
Communicate the proposed solution to the customer and other key stakeholders.
Identify the most suitable migration method.

Comparing Migration Methods

Depending on your goals and how you envision your application to evolve, it may be necessary for you to retain a large code base of installed UNIX applications. There are migration methods that will allow you to preserve your investment in UNIX applications while developing under, or moving to, Windows over a longer period. These methods are:

Using a quick port. A quick port involves migrating your applications to Windows with only the changes that are necessary to allow the applications to run smoothly. One of the simplest possible migration paths is to port the code directly to Windows Services for UNIX 3.5. Windows Services for UNIX 3.5 includes Microsoft Interix, which provides a UNIX environment that runs on top of the Windows kernel, allowing your native UNIX applications and scripts to work alongside the Windows-based applications.
Completing a full port. Unlike the quick port, a full port entails significant alterations to the source code, although the number of modifications depends on the level of standards compliance within the original application.
Redesigning and rewriting the application. Redesigning and rewriting the application is the ideal approach if you want to make full use of all the benefits of migrating to the Windows platform. While initially requiring the greatest amount of work, this course provides benefits in the long run.
Allowing two versions to coexist. With coexistence, you retain the original application alongside the new version while porting or rewriting the application. This method involves significantly reduced risk because it allows you to use the original system if you face unexpected issues with the new application. However, you will need to employ a cross-platform source-code control system to allow concurrent development on both UNIX and Windows.

Comparing Windows Technologies

There are three Windows technologies that can be used to migrate UNIX applications. These technologies are:

Windows Services for UNIX 3.5.
Win32/Win64.
.NET.

Windows Services for UNIX 3.5

Windows Services for UNIX 3.5 provides a full range of cross-platform services for blending Windows and UNIX-based environments. With Windows Services for UNIX 3.5, you can transfer and recompile UNIX-based tools to the Windows platform and extend the value of your UNIX applications. The benefits of moving to Windows Services for UNIX 3.5 include:

Maximum return on application investments. Windows Services for UNIX 3.5 can optimize your investments in UNIX applications by providing the capability to reuse code to run on Windows. It also provides enhanced value to your existing UNIX applications by updating the UNIX code with .NET technology.
Reduced development time. Windows Services for UNIX 3.5 removes the overhead cost of rewriting applications from scratch. Interix subsystem technology saves development time by making it easy to transfer existing UNIX applications to Windows.
Reusability of UNIX scripts. Windows Services for UNIX 3.5 allows you to get the most out of existing UNIX network administrator tools and skill sets. Windows Services for UNIX 3.5 provides more than 300 UNIX tools and shells that enable you to run existing shell scripts on Windows with little or no change.
Streamlined network management. Windows Services for UNIX 3.5 reduces system administration time with tools, such as two-way password synchronization and the Server for NIS components, which centralize network management across the UNIX and Windows platforms.
Powerful software development kit (SDK). Windows Services for UNIX 3.5 comes with an SDK that supports more than 1,900 UNIX APIs and migration tools (conforming to the IEEE 1003.1-1990 standard), such as make, rcs, yacc, lex, cc, c89, nm, strip, gbd, as well as the gcc, g++, and g77 compilers.

Win32/Win64

Win32 is the 32-bit API for the Windows operating system. Win64 is the 64-bit version of Win32, which includes extension functions for use on 64-bit computers. The Win64 API is found only on 64-bit versions of Windows XP and Windows Server 2003. The benefits of moving to Win32/Win64 include:

Expanding application capabilities. Win32/Win64 provides a tremendous scope to expand the existing capabilities of your applications. Windows APIs provide building blocks that can be used by applications to provide various critical functionalities such as GUI for your application, display graphics and formatted text, and manage system objects such as memory, files, and processes.
Powerful application frameworks. Windows provides powerful frameworks, such as Microsoft Foundation Class (MFC), Active Template Library (ATL), and Graphics Device Interface (GDI+), for application development. These frameworks provide a set of wizards and APIs that reduce the time and effort needed to redevelop existing applications on Windows platforms. Internally, these frameworks communicate with the Win32 subsystem to exploit the capability of low-level Win32/Win64 APIs.
Support for 64-bit computing. For the migration of UNIX 64-bit applications, Windows provides a 64-bit Windows Server 2003 operating system that supports far more physical memory than a 32-bit operating system. Increased physical memory allows more applications to run simultaneously and remain completely resident in the main memory of the system. This reduces or eliminates the performance penalty of swapping pages to and from the disk. A 64-bit operating system also provides a larger virtual memory space for applications, especially database applications that require a larger addressing space.

.NET Framework

The .NET Framework is an integral Windows component that supports building and running the next generation of applications with a consistent, object-oriented programming environment. It supports safe execution of code, eliminates performance problems, and builds such widely varying applications as Windows applications, Web applications, Web services, and deployment applications. It consists of two main parts: the Common Language Runtime and the .NET Framework class library. The benefits of moving to the .NET Framework include:

New value from existing assets. .NET-connected services can help extract new value from existing assets. Organizations can build new and flexible solutions by building on existing technology and exposing existing functionality through Web services.
Increased efficiency of business processes and business users. .NET-connected services can streamline existing business processes and improve efficiency. One way to streamline processes is to link systems so that they can interoperate without manual intervention. This enables the streamlining of processes that once involved multiple systems and eliminates the manual reentry of data and duplication of efforts, thus saving time and money.
Language interoperability. The .NET language allows interoperability that enables developers to make good use of specific features of a language and integrate it easily into your application. For example, to obtain a very good performance, developers may choose to work with C++ with managed extensions.
Common development environment and easier debugging. The IDE Visual Studio® .NET (VS.NET) will be the same for the languages supported by .NET. Application debugging is much easier, and one of the goals of VS.NET is to provide end-to-end debugging from the ASP.NET page to the business components to the database stored procedure.
Unified programming class. Prior to the development of .NET, Microsoft Visual C++® developers had their own library MFC, which was not much help to them in the event of a shift to Microsoft Visual Basic® at a later point. In .NET, the base library will remain the same, irrespective of the language used. Therefore, knowledge once gained can be reused across languages.

Choosing the Appropriate Windows Technology

Migration of a UNIX application to Windows may be as simple as recompiling, or it may require significant redesign and redevelopment. The amount of effort required depends on how portable the application source code is to begin with, whether compatibility tools (such as Windows Services for UNIX) are being used, and the intended use of the application on the Windows platform. The Microsoft recommended order of priority for migrating UNIX applications is .NET, Win32/Win64, and Windows Services for UNIX 3.5.

During the assessment conducted earlier in the current situation assessment process, you answered questions in the assessment tool about your application. You need to now use the results provided by the assessment tool to select the appropriate migration approach. The suggested migration approach (the one with the highest score) is generally the best fit for the migration scenario under consideration and involves the least amount of effort, risks, and deployment issues. The other migration approaches (with lower scores) might present more challenges and issues in the migration process but can act as backup choices in case the best approach becomes difficult to adopt.

Some of the assessment questions, especially the business-level and technology-level questions, may be common to all layers and modules. You will observe at the end of this decision-making exercise that these common questions are the critical driving factors for deciding the appropriate Windows technology to which to migrate.

Note Before you proceed further, you need to have calculated the percentage of recommendations for each migration approach and analyzed the suggested migration options.

Analyzing the various migration options may lead to one of the following situations:

High recommendations for a single Windows technology.
High recommendations shared between two Windows technologies.
High recommendations shared equally among the three Windows technologies.

Also, in the preceding three migration approaches, the customer must evaluate if particular components of the application have an affinity toward a specific Windows technology and, if so, the customer should consider the liability of having one component on a different platform while others are migrated to a new platform.

Note For more information on Windows technologies described previously, refer to the following volumes of this guide: Volume 2: Migrate Using Windows Services for UNIX 3.5
Volume 3: Migrate Using Win32/Win64
Volume 4: Migrate Using .NET

High Recommendations for a Single Windows Technology

This is a straightforward situation where one particular Windows technology has been given the highest recommendation (highest score). It can be one of the following:

Quick or a complete port using Windows Services for UNIX 3.5.
Port or rewrite to Win32/Win64 platform.
Port or rewrite using .NET.

Several critical factors, as mentioned in the previous section, should be considered when finalizing the Windows technology for the migration process. In specific cases, there may be an equal distribution of high recommendation votes among the critical driving factors. For example, your budget may be low for a static module and, at the same time, you may need better performance than UNIX can provide and need to use a Windows feature like Plug and Play. These are your four critical factors, and all your other noncritical factors suggest moving to Win32/Win64. In this case, two of your critical factors favor the use of Windows Services for UNIX 3.5, while two other critical factors point to Win32/Win64.

The recommended way to resolve such a tie situation is to go back to your core group and identify which of these two sides, taken independently, can override all the other factors in the list put together. In the example, if you absolutely need better performance than UNIX and must use a Windows feature like Plug and Play, then Win32/Win64 is the recommended path. But if your budget is limited and you cannot afford to move to Win32/Win64, then it is recommended that you do not carry out the migration until you have sufficient funds. This is because the majority of your requirements will not be satisfied if you choose to migrate using Windows Services for UNIX 3.5.

High Recommendations Shared Between Two Windows Technologies

This is again a situation where you need to fall back on the recommendations for your critical factors. If the recommendations for these critical factors are shared between two Windows technologies, it is recommended that you use a combination of the two technologies for your migration.

For example, if you have 50 percent of your high recommendations to .NET and 50 percent to Windows Service for UNIX 3.5, then the critical factors are also equally distributed between .NET and Windows Services for UNIX 3.5. In this case, it is recommended that you choose a combination of .NET and Windows Services for UNIX 3.5 to carry out your migration.

High Recommendations Shared Equally Among Three Windows Technologies

When the high recommendations are equally shared between the three Windows technologies (for example, .NET–30 percent, Windows Services for UNIX 3.5–35 percent, and Win32/Win64–30 percent), check for the two technologies that cumulatively have the maximum high recommendations for your critical factors.

For example, if .NET and Windows Services for UNIX 3.5 together satisfy all or most of your critical factors, it is recommended that you choose a combination of Windows Services for UNIX 3.5 and .NET to carry out your migration.

After you have completed the evaluation of all the modules, you need to superimpose all your individual assessments and check for the most highly recommended Windows technology across all modules. If there is a clear indicator, then that is the technology to which you need to migrate. In the absence of a clear indication, it is recommended that you use a combination of the two most recommended Windows technologies (for example, .NET and Windows Services for UNIX 3.5 in this case). Microsoft recommends that all customers move their applications to the .NET Framework. If that’s not feasible, then Win32 should be the next choice. If neither .NET nor Win32 is appropriate, then Windows Services for UNIX or Services for UNIX Administration is recommended. If none of these three is possible, then MKS Toolkit or Cygwin are suggested. The following sections describe MKS and Cygwin.

MKS Toolkit

MKS Toolkit for Enterprise Developers (formerly NutCracker) is a UNIX and Windows interoperability suite. This suite allows remote access, interconnectivity, remote system administration, file sharing, and full automation and scripting capabilities.

MKS Toolkit helps in UNIX-to-Windows interoperability by providing:

A set of UNIX-named tools that work under Windows. Complete shells help in doing shell scripting.
Interoperability tools, which allow switching from UNIX to Windows environments easily.
Numerous APIs for porting to the Windows development platform from a number of UNIX versions.
A set of conversion tools that help update UNIX applications to take advantage of current operating system features.

MKS Toolkit supports synchronous and asynchronous UNIX signals. Job-control signals are not supported but thread priorities are properly supported. MKS Toolkit provides the capability of working with portable code. Therefore, nonportable applications, such as device drivers, do not benefit from the MKS Toolkit.

Note More information on the MKS Toolkit is available at https://www.mkssoftware.com/products/tk.

Cygwin

Cygwin is a Linux-like environment for Windows. The Cygwin tools are part of the popular GNU development tools that have been ported to Windows. They run using the Cygwin library, which provides the UNIX system calls and environment.

With the Cygwin environment, it is possible to write Win32 applications that make use of the standard Win32 API and the Cygwin API. Therefore, it is possible to port many UNIX programs without the need for extensive changes to the source code.

Note The Cygwin system is available at https://cygwin.com/.

Sample Scenarios for Developing a Solution Concept

The following sections describe six example scenarios that illustrate some possible combinations of existing situations and requirements along with the recommended path of migration for the situation/requirements. A sample solution concept is also provided for each example.

Example 1

You have a monolithic, stand-alone application running on a single-processor Sun Solaris platform. The application is written using native UNIX APIs and is not GUI-oriented. Your application is static with no change requests or scalability requirements. The budget for this migration is low, and you want to complete the migration as quickly as possible. Your driver, such as performance requirements, on the Windows platform is the same as UNIX. You do not have anyone in your organization with adequate knowledge of programming in Windows and you are not willing to invest too much money in training your development team on Windows programming.

Solution Concept for Example 1

In this situation, it is recommended that you perform a quick port using Windows Services for UNIX 3.5 if all of your code is compatible with Interix, or perform a complete port using Services for UNIX 3.5 if the code requires minor changes to make it compatible with Interix. Even a quick port using Windows Services for UNIX 3.5 typically requires some code changes, but it's substantially less than for a full port, which usually means moving to Win32. Because a quick port is defined as "do just enough to get it running under Windows Services for UNIX 3.5," then by those definitions example 1 requires a quick port regardless of how much effort is involved. It is only if you decide to move the application to Win32 without doing a redesign that you really need a full port.

Example 2

You have a decoupled distributed application built using MQ Series running on the IBM AIX platform. Your application is dynamic and needs to be scalable over a period of time. The budget for this migration is high, and you are willing to use your existing application on UNIX for a long duration before migrating it to Windows. The developers on your project have Windows programming knowledge, or you are willing to train them in Windows programming. The application uses UNIX APIs that have equivalents in Windows—for example, file handling commands like open() and close().Your performance requirements on the Windows platform are such that they need to be better than UNIX. You also have an additional requirement of adding Web services to your application.

Solution Concept for Example 2

In this situation, it is recommended that you migrate to .NET by rearchitecting your application and rewriting it in C# primarily because of the Web services technology that .NET offers. If, on the other hand, your requirement for adding Web services is a long-term plan and you want to retain your existing application architecture, then it is recommended that you move your application to Win32/Win64 because the time required to rewrite your application is faster. The task of rewriting will consist of replacing the existing UNIX commands with Windows equivalents—for example, OpenFile() and CloseHandle(). You have the option of running MQ Series on Windows or rewriting the application to use the Windows Message Queuing API.

Example 3

The application code has less than 5000 lines written using native UNIX APIs.

Solution Concept for Example 3

In this situation, it is recommended that you rewrite the entire application using C or C++ on Windows. If you do not have very stringent performance requirements, but you need extensibility for your code because your code requirements are constantly changing, then it is recommended that you use C# as the programming language.

You may have observed that in this particular situation, we have not gone into the details of the other requirements because of the size of your application code. It is recommended that you rewrite the application on Windows, based on the time and effort required to rewrite such a small-scale application. In addition, if your application does evolve over a long period, it helps that the code is available on Windows.

Example 4

You have a client/server application running on the SGI IRIX platform. Your server side is static while the client is dynamic and needs to evolve over a period of time. The budget for this migration is low, and you are doing a pilot project to see how the application runs on Windows. You have developers with Windows programming knowledge within your organization, or you are willing to train them in Windows programming. The third-party tools that you have used to develop your GUI code in UNIX are not X Windows and do not have a Windows equivalent, or you want to develop a GUI for your application based on Windows forms to get the Windows look and feel.

Solution Concept for Example 4

In this scenario, it is recommended that you perform a complete port of your server side using Windows Services for UNIX 3.5 by rewriting the UNIX code so that it is compatible with POSIX or by creating Interix wrappers on the UNIX code that is not compatible with POSIX. The client part of your code can be written using GDI+ on Windows. Depending on whether the GUI is a thick client or thin client, you will also need to write wrappers in Interix around your server code to talk to the Windows-based GUI. In case your existing GUI code on UNIX is written using X Windows, it is recommended that you rewrite the X Windows code to be compatible with Windows because some of your existing code may be reusable.

Example 5

You have a highly dynamic Web application that is bound to evolve over a period of time. You want to move away from your existing environment, so there is no requirement to maintain your code on several platforms concurrently. Your budget for migration is high, and you expect a better performance on Windows platforms. You have a high requirement for a Windows look and feel in the Web pages and such features as transaction handling, messaging, and security. There is a lot of messaging and data exchange between the modules in your application. The application is written using C++ and Perl. You have developers with Windows programming knowledge within your organization, or you are willing to train them in Windows programming.

Solution Concept for Example 5

In this scenario, it is recommended that you migrate to .NET by rearchitecting your application and rewriting it in C# primarily because of the extensibility and scalability that .NET offers to you in the long run.

Example 6

You have a 64-bit application.

Solution Concept for Example 6

In this scenario, it is recommended that you rewrite the application on Win32/Win64 because .NET and Windows Services for UNIX 3.5 do not currently support 64-bit applications. If your application is written using native UNIX calls, it is recommended that you rewrite them with Windows calls. If your application is using third-party tools, it is recommended that you use their Windows equivalent, if they have one, or redesign and redevelop the application on Windows.

Assessing Risk

A risk is an event that can jeopardize the successful completion of a project or the ongoing success of the deployed application. Any condition that may create an unfavorable outcome and whose occurrence is uncertain is a risk. The objective of risk management is to identify these conditions; prioritize them based on their impact on project goals and the probability of the occurrence of these conditions; identify, plan, and execute mitigation steps; and track the risks during the entire project life. During project execution, additional risks may appear and these must be addressed similarly.

Risk is also the possibility of suffering loss. This loss may be in the form of diminished quality of the migrated application, increased development and support costs, missed deadlines, or complete failure to achieve the mission and purpose of the project. In other words, a risk is a problem waiting to happen. It is recommended that the Microsoft Solutions Framework (MSF) approach to risk management be adopted, as illustrated in Figure 2.1. This approach allows you to retire risks through a process of identification, analysis, mitigation planning, tracking, and control.

Figure 2.1. The MSF approach to risk management

Identifying Risks

Throughout the Envisioning Phase, you will identify and document issues surrounding the migration. These issues may be business-, technical-, application-, or infrastructure-specific. Before you can create a realistic project plan, you must determine whether any of these issues pose a serious risk to the project and what should be done to minimize the probability of things going wrong.

In general, the more potential stumbling blocks— attitudinal, structural, or otherwise— you identify ahead of time, the easier it will be for you to minimize the amount of time spent trying to resolve them during migration.

Risk Analysis and Mitigation

To help you with risk analysis and mitigation as well as risk identification, a Risk Assessment Tool is included in the Tools and Templates folder with the downloadable version of this guide. This job aid lists some of the critical risks that may be encountered in a UNIX-to-Windows migration project and the plans for mitigating them. The risks are categorized into generic, business, architectural, and technical risks. Any additional risks that you have identified during the course of the Envisioning Phase needs to be added to that list and a suitable risk mitigation strategy should be planned.

Closing the Envisioning Phase

The Envisioning Phase ends when the team, the customer (business sponsor), and major project stakeholders review the vision/scope document and formally signify their agreement with its terms. Securing this agreement indicates achievement of a major project milestone, Vision/Scope Approved, which is required to proceed to the next phase, the Planning Phase. At this point, the business and IT should have a clear idea of the goals for the project (and all its associated risks), and the project team can now begin to make specific plans for how to achieve them.

Key Deliverables from the Envisioning Phase

The key deliverables that should be produced by the end of the Envisioning Phase are:

Project structure document
Vision/scope document
Risk assessment document

Key Milestone: Vision/Scope Approved

Reaching the Vision/Scope Approved Milestone concludes the Envisioning Phase. At this point, the project team and the customer have agreed on the overall direction for the project, including the features to be included in the project scope within a specified time of delivery.

Project teams usually mark the completion of a milestone with a formal sign-off. The sign-off document becomes a project deliverable and is archived for future reference.