Chapter 2 - Envisioning Phase

  • Article
On This Page

Introduction and Goals Introduction and Goals
Understand the Goals of the Migration Project Understand the Goals of the Migration Project
Create the Problem Statement Create the Problem Statement
Create the Vision Statement Create the Vision Statement
Define the User Profiles Define the User Profiles
Assess the Current Situation (High Level) Assess the Current Situation (High Level)
Capture High Level Requirements Capture High Level Requirements
Define the Project Scope Define the Project Scope
Define the Solution Concept Define the Solution Concept
Set Up a Team Set Up a Team
Define the Project Structure Define the Project Structure
Assess Risk Assess Risk
Manage Risks Manage Risks

Introduction and Goals

This chapter provides the process and technical information required to complete the Envisioning Phase of an Oracle on UNIX to SQL Server on Windows® migration project.

The Envisioning Phase is an early stage of planning. This is the period during which the team, the customer, and the sponsors define the high-level requirements and overall goals of the project. The main purpose of the work performed during the phase is to ensure a common vision and reach consensus among the team members that the project is both valuable to the organization and likely to succeed. During the Envisioning Phase, the focus is on creating clear definitions of the problem and understanding the high level approach to solving the problem. This sets a solid foundation from which specific plans can be developed during the Planning Phase and executed during all subsequent phases to achieve the migration objectives. The Envisioning Phase culminates in the Vision/Scope Approved Milestone.

The key deliverables for the project team during the Envisioning Phase are:

  • Vision/scope document. The vision/scope document describes the project goals and constraints. It outlines the solution being developed, the requirements the solution will meet, and the approach that the team will take to complete the project. The vision/scope document is an early form of the functional specification that is developed during the Planning Phase. For more information on creating your vision/scope document, refer to the vision/scope template.

  • Project structure document. The project structure document defines the approach the team will take to manage the project. It defines the team’s administrative structure, standards, processes (such as version control and change control), project resources, and constraints. The document identifies the team lead responsible for each MSF role.

  • Risk assessment document. The risk assessment document provides an initial identification and analysis of risks associated with a project. This analysis includes mitigation and contingency plans to help the team manage specific risks. Refer to the Risk Assessment template for more information.

Templates for each of these key deliverables are available in the Tools and Templates folder in the zip file download of this guidance at https://go.microsoft.com/fwlink/?LinkId=45289.

Table 2.1 lists the key activities that the team undertakes in the Envisioning Phase. The results of these activities are documented in this phase's deliverables.

Table 2.1: Major Tasks, Deliverables, and Primary Owners

Tasks

Project Deliverable

Primary Owner

Understand the goals of the migration project (business and design)

Vision/scope document

Product Management

Create the problem statement

Vision/scope document

Product Management

Create the vision statement

Vision/scope document

Product Management

Define end user profiles

Vision/scope document

Product Management

Assess the current situation (high level)

Vision/scope document

Program Management

Identify high level requirements

Vision/scope document

Product Management

Define the project scope

Vision/scope document

Program Management

Define the solution concept

Vision/scope document

Program Management

Set up a team

Project structure document

Program Management Product Management

Define the project structure

Project structure document

Program Management

Assess risk

Risk assessment document

Program Management

Note This chapter provides information about the essential tasks of the Envisioning Phase for an Oracle on UNIX to SQL Server on Windows migration project. The chapter is not exhaustive. For a detailed description of all the activities and deliverables for the MSF Envisioning Phase, refer to the UNIX Migration Project Guide (UMPG) available at https://go.microsoft.com/fwlink/?LinkId=19832.

Understand the Goals of the Migration Project

An early, clear understanding of the goals of the migration project by the project team is imperative for its success. These high level goals are not defined by the project team; they are defined by the business managers and major stakeholders. The reasoning for reaching an early consensus on the goals includes:

  • The migration goals, once identified, are used to create a vision statement for the migration project. This vision statement is the key driver for all actions and decisions made by the team during the course of the migration project.

  • The goals determine the aggregate skill set required by the project team to successfully execute the migration project.

  • The project team uses these goals to scope specific requirements that, in turn, serve as the basis for detailed solution designs and plans.

  • The goals serve as the basis for reconciling conflicts and establishing priorities that guide any trade-off decisions (schedule, features, resources, budgetary restrictions) that need to be made later in the project.

The project goals can be classified as business goals and design goals. Both types of goals are described in detail in the following sections.

Define the Business Goals

Business goals are established either to take advantage of an opportunity or to solve a problem in the current business. Each organization has business goals specific to them. For example, a business goal for one organization could be to “consolidate the ERP applications across all worldwide units on one software platform after a merger with another company,” while a different organization may have compliance with new federal regulations as its primary business goal. Because business goals can vary widely, this guide does not provide a specific, comprehensive list of business goals. Your organization will have to determine the business goals specific to it. However, the two most common business goals for IT projects are:

  • Reduce total cost of ownership (TCO) of the IT platform

  • Maximize return on investment (ROI)

Because these two business goals are so common, they are discussed in more detail under the following headings.

Reduce TCO of IT Platform

TCO of a system includes not only the price of purchasing software and hardware, but also the cost of training users and supporting and maintaining the system. Therefore, while evaluating the TCO of any system, there are several factors to consider.

  • Cost of hardware. Evaluate the cost of server hardware, networking equipment such as hubs and routers, and other equipment. Also include facilities cost for hosting the hardware.

  • Cost of software. Evaluate the cost of all software including the operating system and applications, such as database systems, developer tools, and management software.

  • Reliability of the system. If the system fails or crashes often, the support cost for such a system would increase.

  • Cost of system maintenance. System administration is single highest cost factor for any IT organization. Evaluate the staff strength needed and associated costs for maintaining the system.

  • Cost of supporting the users. Users may need extensive training and frequent support, significantly adding to the TCO.

  • Projected cost of the migration project itself. Factors such as availability of skills in-house versus hiring external consultants will influence the project cost. You will be able to estimate these costs better after completing the Planning Phase.

Microsoft offers several solutions to help reduce TCO.

For example, Microsoft Visual Studio .NET provides an Integrated Development Environment (IDE) for rapid development of applications that reduces the cost of developing and upgrading applications. The Windows graphical user interface (GUI) environment provides an easy-to-use interface for Windows users. The Windows standard GUI and GUI-based management applications simplify server administration and thus contribute to reducing support costs.

For more information, refer to https://www.microsoft.com/business/reducecosts/efficiency/consolidate/default.mspx.

Maximize ROI

TCO is concerned with an organization’s bottom-line (cutting costs), and ROI is related to the top line (increasing revenue). A lowered TCO and increased ROI scenario is the ultimate goal of any migration project. To estimate the ROI due to the migration effort, you should take into account the following considerations:

  • Creation of new business opportunities. The migration may provide new technological capabilities and drive new business innovations that lead to increased revenue.

  • Opportunities created by improved performance. For example, a faster response time to online users on a Web site can drive more satisfied customers to the site and increase profitability.

  • Total downtime required to complete the migration. System downtime can affect revenue and should be minimized.

  • Reliability of the system. Unplanned system downtime can negatively affect productivity and revenue.

  • Time to recover investment costs. The business needs to understand how long it expects to realize a return on the investment in the project.

  • Impact on user productivity due to the migration. If users are going to take a long time to ramp up on the new technology, it can impact the near term productivity and profitability of the organization. Productivity can also be affected positively by easing the integration between the database application and other office software.

  • Managing risk. The organization needs to evaluate the risk of doing the project as well as not doing the project. Not taking the risk may be the path of least resistance, but it may deprive you of significant revenue opportunities. Proven best practices and processes can minimize risk and make the migration more predictable. Several system integrators (SIs) offer service offerings that can greatly mitigate the risk. The SIs who are known to offer Oracle to SQL migration offerings, as of publishing this solution, are listed in the "Set Up a Team" section later in this chapter.

Some of the questions that result from these considerations can be answered by analysis. However, a proof-of-concept or a limited pilot exercise can help provide quantifiable answers to these questions, including estimating application migration costs and determining the reliability of software. More information is available in the "Technical Proof of Concept" section of Chapter 3, "Planning Phase."

Identify the Design Goals

Design goals are similar to business goals in many ways. The difference is that design goals focus more on the attributes of the solution and less on what the solution will accomplish for the business. As with business goals, an organization's design goals are unique and specific to that organization. For example, one organization may determine that “corporate data should be accessible from the mobile devices issued to company employees.” A different organization's primary design goal may be to “reduce the time and level of effort required for a user to connect to the server and complete a task.” This guide does not provide a specific list of design goals. Your organization will have to determine the design goals specific to it. However, the following list provides the six most common and generic design goals for UNIX to Windows migration projects.

Create the Problem Statement

A problem statement is usually a short narrative describing the specific issues that the business hopes to address with the project. It relates primarily to the current state of business activities and is a direct result of the business goals or design goals not being met adequately. The more precisely the problem statement is recorded, the easier it will be to measure the success of the project.

Because the aim of the project is to solve a problem, the understanding of the problem determines the design of the solution. A good problem statement provides sufficient information about the business problem for a new team member to use the problem statement and the rest of the documentation to put the project into context.

The following are some examples of problem statements that may be relevant in an Oracle on UNIX to SQL Server on Windows migration project:

  • Customer support cannot effectively process the high number of customer calls because of the time it takes for them to retrieve customer data from the existing customer database.

  • Product managers cannot make informed decisions about sales promotions because they do not have recent sales trends.

Create the Vision Statement

The vision statement addresses the problem statement and establishes a common vision of the end state that can be shared among team members. While brief, this statement provides a common starting point for future decisions throughout the rest of the project.

A good vision statement has the following characteristics:

  • Specific. A vision statement should be specific and include the ideal state of the business problem solution so that the end result is meaningful.

  • Measurable. By creating a vision statement that is measurable, the project team can determine the degree of success at the completion of the project.

  • Achievable. Given the resources, the time frame, and the skills of the team members, the vision statement should be achievable. An achievable and challenging vision statement can motivate team members.

  • Relevant. The vision statement should relate to the business problem being addressed. If not, the project team might realize that they are solving the wrong problem, or one that does not exist, and — in the process — lose sponsorship.

  • Time-based. The vision statement should clearly indicate the estimated time frame for the delivery of the solution.

The following two examples are vision statements for an Oracle on UNIX to SQL Server on Windows migration project:

  • Before the end of the year, our customer support staff will be able to retrieve all customer data and account history within three seconds of the customer identifying himself or herself.

  • Before the start of the next fiscal year, our product managers will have access to daily sales reports from all the showrooms in the country.

Define the User Profiles

Understanding the users for whom the solution is being developed is critical to the project's success. To capture a clear description of each user, the team creates profiles of each user class. The process of profiling develops a set of user requirements. The combination of these user requirements with the business and design requirements will help to define the project scope later in the Envisioning Phase.

In an Oracle on UNIX to SQL Server on Windows migration project, the most important profiles are that of the system managers and users of the migrated application. Consider the following while profiling the user types:

  • Proficiency of the users in using Microsoft applications and the Windows environment. Administrators largely use command line tools in the Oracle/UNIX world. While Windows also provides some command line interfaces, Windows tools tend to be graphical user interfaces (GUIs). Users new to the Windows environment may need training.

  • The type of tasks that the users will perform on the new system.

  • Essential expectations of the end user from the current application interface that will have to be met in the new environment.

  • The language localization needs for the end users, if necessary. Consider the GUI as well as user documentation.

  • The physical location of the end users. Factors such as locations, number of users at each location, and the bandwidth and usage of network links between the sites should be understood and documented.

Assess the Current Situation (High Level)

Organizations planning an Oracle on UNIX to SQL Server on Windows migration need to consider the following five entities for a successful migration. While these entities are assessed in detail in the Planning Phase of the project, a high level preliminary assessment is essential in the Envisioning Phase to evaluate the feasibility of the project.

  • Application

    This entity includes the target applications that are migration candidates. While assessing applications, the following questions should be asked:

    • Which are the specific applications that are to be migrated?

    • What languages are these applications written in?

    • If there are custom applications to be migrated, is the source code available?

    • Are the developers of the application still a part of the team?

    • Do the applications to be migrated interoperate with other applications or systems?

  • Database

    This entity includes the Oracle databases that need to be migrated to SQL Server. The following are some of the high level questions you need to ask:

    • Do your existing databases implement specialized features of Oracle or any other third-party customizations to provide additional database features?

    • Are the databases that need to be migrated shared by multiple applications?

    • What are the sizes of the databases being migrated?

    • What is the user population of the databases?

  • Application infrastructure

    This entity includes server and network-related resources, such as compute nodes, storage, file systems, routers, firewalls, hubs, and so on. The following are some of the questions you need to ask to assess the current state:

    • Do you already have an existing infrastructure based on Windows that can be readily used or expanded, or do you have to set up the infrastructure from scratch?

    • What are the other external systems, such as those of your partners or clients, that would be impacted by the migration?

    Microsoft provides a standardized infrastructure architecture named Windows Server System Reference Architecture (WSSRA). WSSRA provides lab and real world tested, architectural blueprints and proven best practices to design and implement enterprise infrastructure solutions with minimal risk and cost. The guidance addresses infrastructure issues including availability, security, scalability, and manageability of the platform in a fully integrated fashion. For detailed information on WSSRA, refer to https://www.microsoft.com/technet/itsolutions/wssra/raguide/default.mspx.

  • Development environment

    This entity includes software construction environments such as the UNIX make environment, developer tools, and so on. Migration of the database and data can be achieved by using tools bundled with Oracle and SQL Server, such as SQL*Plus, Enterprise Manager, and Query Analyzer. Microsoft offers a set of tools called SQL Server Migration Assistant for migrating Oracle databases to SQL Server.

    Questions to ask while assessing the development environment include:

    • What is the software construction environment that you have to build the UNIX applications? A commonly used software construction mechanism is the use of makefiles. For detailed process and technical guidance on using a make-based build environment to build Windows executables, refer to https://go.microsoft.com/fwlink/?LinkId=22225

    • Are the required licenses for the appropriate SQL Server edition available?

    • What are the server, storage, and network resources to support the development and testing activities?

  • Existing documentation

    This entity includes end user documentation, requirements analysis, functional specifications, design documents, and so on. The existing documentation should be scrutinized as part of the task of assessing your current environment. This is something that is often overlooked. Existing design documentation is a valuable resource for building project documents and plans, especially when a large portion of the existing functionality is carried over to the new solution. Developing test plans and test cases for the new application based upon existing documentation is especially useful. Modifications to existing documentation are almost certainly needed to support the migrated solution. One problem often encountered is that the existing documentation is incorrect or insufficient, which may force the migration project to absorb the effort of bringing it up to date.

    These are some of the questions that you need to ask:

    • Are the original requirements for each of the applications to be migrated available?

    • Are database and application design (high level as well as detailed) documents available?

    • Are the logical and physical data models available for all databases to be migrated?

    • Is documentation for the application code maintained?

    • Are user manuals available for client applications?

    • Are training documents available for support, end users, and operations personnel?

  • Application users

    User accounts that exist in the UNIX domain need to be migrated or recreated in the Windows-based domain along with the necessary permissions for users to start using the application on the Windows domain. Ask the following questions:

    • What security services are in use (examples include local, Kerberos, NIS, NIS+, and LDAP)?

    • What is the authentication method in use (examples include password, digital certificate, and so on)?

    • What authority does the user have on the system?

    • How is authorization implemented?

    • What activities of the users are audited?

    • Are users required to use secure communication methods such as SSH?

    • Are application users authenticated by the operating system as well as by the database?

    For prescriptive guidance on how to enable Windows Server 2003 to be used for authentication and as an identity store within Windows and UNIX environments, refer to https://go.microsoft.com/fwlink/?LinkId=23120.

Note The primary purpose of this solution is to provide guidance on migrating the applications and databases from an Oracle on UNIX environment to a SQL Server on Windows environment. The discussions about migrating the infrastructure, development environment, user accounts, and documentation are, therefore, limited in this solution. The discussions have been included to provide readers a holistic perspective of the migration. Pointers to other resources that provide more information, including prescriptive guidance, are provided when relevant.

Figure 2.1 represents the primary entities involved in an Oracle on UNIX to SQL Server on Windows migration. To reiterate: this guide provides prescriptive guidance for migrating the application, database, and application infrastructure entities only. Information about the other entities is available from the sources cited earlier.

Figure 2.1 Primary Migration Entities

Figure 2.1 Primary Migration Entities

Capture High Level Requirements

An important task in the Envisioning Phase is to document the high-level business, user, and design requirements. These requirements are refined further in the conceptual design stage of the Planning Phase (discussed in Chapter 3, "Planning Phase").

A common way of gathering and analyzing information is through developing use-cases and building usage scenarios to document the business processes and user requirements. While use cases describe the high level interactions between an individual and the system, usage scenarios provide additional information about the activities and task sequences that constitute a process.

A detailed discussion of use-case analysis is out of scope of this solution. Please refer to the following resource for additional guidance: Advanced Use Case Modeling (Armour and Miller, 2000).

Define the Project Scope

One of the critical factors in the success of a project is clearly defining the scope of the project. Scope defines what will be and what will not be included in the project. The scope uses the high level requirements gathered earlier in the Envisioning Phase and incorporates the constraints imposed on the project by resources, schedule, budget, and other limiting factors. A good way of scoping is to address use cases and usage scenarios that impact the business the most.

As with the business and design goals, the scope for projects is organization-specific, and you will need to determine the scope for your project and document it in the vision/scope document. However, when producing the scope for your Oracle on UNIX to SQL Server on Windows migration project, some general guidelines should be followed:

  • Consider a multiphase approach to the migration. In the first phase, consider migrating only the database and reconnect the UNIX applications to connect to SQL Server. Limiting the scope for each phase of the migration increases your ability to monitor and measure the migration project's success.

  • Consider migrating the portable applications first. These include applications written using Java, Perl, PHP, and Python. Portable applications can usually be ported or configured to interoperate with relative ease, and this helps build user and management confidence.

  • Oracle Forms and Pro*C applications are the hardest to migrate because they have to be rewritten; perform them in a later phase, if possible.

  • The migration of code present in the database in the form of triggers, functions, stored procedures, and packages impacts the migration of applications that are dependent on them. As a result, these have to be migrated first.

  • Databases using advanced Oracle functionality, such as advanced queuing, Java packages, objects, and so on are more difficult to migrate, and a proof-of-concept should be created to verify the solution.

  • Smaller databases with less stringent requirements on performance and availability should be migrated before attempting larger ones.

  • To reduce the complexity, migration at the schema level should be considered where feasible instead of entire databases.

Define the Solution Concept

The solution concept outlines the high level approach the team will take to meet the goals of the project and provides the basis for proceeding to the Planning Phase. This approach includes the assessment of technologies, development, test, quality assurance, training, deployment, release, operations and so on. These approaches can be developed into full-fledged plans in the Planning Phase. Because the solution concept focuses on the concepts and not the details, it is not very technical.

The solution concept also includes a high-level solution design strategy for all the software and hardware components of the system. Because the primary focus of this solution is migrating the Oracle databases and associated applications to SQL Server on Windows, the rest of this section discusses only solution design strategies for the database and applications.

Application and Database Migration Solution Design Strategy

For the purposes of explanation, the application and database ecosystem can be viewed in terms of three components:

  • Application. This component includes applications written in a variety of programming languages, including Oracle Forms, Perl, Python, and so on.

  • Connectivity interface. This is the intermediate tier between the application and the database. The connectivity tier is also referred to as the application programming interface (API). This layer facilitates the communication between the application and the database. Oracle and SQL Server support different connectivity interfaces, some proprietary and some standard. Oracle Call Interface (OCI) is an example of a proprietary interface for an application to communicate with Oracle. Object Database Connectivity (ODBC) is an example of a standards-based interface. The available API also differs from UNIX to Windows.

  • Database. The database tier consists of the database management system and the objects that store and facilitate access to the data in the database.

The relationship between these three components is shown in Figure 2.2. The connectivity interface binds the application to the database and allows information to pass between them.

Figure 2.2 Application, database, and connectivity tiers

Figure 2.2 Application, database, and connectivity tiers

Once the database is migrated from Oracle to SQL Server, there are four different approaches to connect the application to the SQL Server database using an appropriate connectivity layer.

  1. Interoperation

    The application components remain on the UNIX platform.

  2. Port or rewrite application to the .NET platform

    The.NET framework is the next generation platform from Microsoft for building, deploying, and running Windows applications. It provides a standards-based, multi-language environment for integrating existing investments with next-generation applications and services.

  3. Port or rewrite application to Win32 platform

    The Win32 API is one of the primary programming interfaces to the Windows operating system family, including Windows 2003. The Win32 API provides functions for processes, memory management, security, windowing, and graphics.

  4. Quick port: port application to the Windows Services for UNIX 3.5 platform

    Port applications to an environment on Windows named Interix, which is similar to UNIX. Interix is a complete, POSIX-compliant development environment that is tightly integrated with the Windows kernel. It is a part of the Microsoft Windows Services for UNIX 3.5 product suite from Microsoft.

Each of these four options constitutes a separate design strategy for your migration project, and each of the four is discussed in more detail under the following headings. One, some, or all of these solution design strategies will form the basis of the solution concept you will produce as a part of completing the Envisioning Phase. Even when the goal is to standardize on the Windows platform, some of these strategies may be employed as intermediary steps in a multi-phased migration. This solution concept — documented in the vision/scope document — will be used to develop detailed plans during the Planning Phase and code during the Developing Phase.

Note Due to the complexities inherent in a migration project, it may not be possible to immediately select a migration strategy. Proof-of-concept testing may need to occur before the design strategy is decided upon.

Solution Design Strategy A: Interoperability

In this strategy, the applications remain on the UNIX platform while the database alone is migrated from Oracle to SQL Server.

Interoperation is preferred in the following situations:

  • The migration effort and risks need to be minimized at the expense of not being able to fully realize the benefits of migrating the application to Windows.

  • A multiphased approach for migration is more appropriate. The first phase of migration could involve migrating the database only, and later phases could focus on migrating the applications.

  • The needs served by the application are static; the evolution of the application is not a business or design goal of the project.

  • Maintaining a tight or complex integration of UNIX applications with other services is required.

Interoperation is not recommended in the following situations:

  • The cost of maintaining two environments is prohibitive.

  • The goals of the project include changing the application to take advantage of the greater business value of Windows technologies.

  • Components being on two different platforms do not produce acceptable performance or service levels.

  • The required measure of security cannot be achieved because of disparate technologies.

  • When the interoperation is complex and requires huge effort in development and implementation as compared to employing one of the other methods.

Solution Design Strategy B: Port or Rewrite to .NET Framework

When migrating an application to the .NET framework, there are two different options. One is to perform a full port of the application, and the other is to rewrite the application using the .NET application programming interfaces (APIs).

A full port is defined as the capability to execute the application in the Windows environment in its native form. Applications written using languages such as Java, Perl, PHP, and Python, which are available on both the UNIX and Windows platforms, can take advantage of a full port. In most cases, SQL Server database drivers are available for the specific application languages. A full port requires minimum changes to be done to the source code, and a full port uses standard libraries and utilities that exist on the Windows platform. New documentation and user training is not required in the case of a full port because the business logic and the user interface remain the same.

A full port to the .NET framework is preferred in the following situations:

  • The programming environment in which the application was written is fully supported in the .NET framework.

  • Appropriate .NET database drivers are available and support all the function calls made in the application code.

  • Rewriting an application consumes too much time and increases cost prohibitively.

  • When ported into the .NET framework, the application successfully interacts with other applications.

A rewrite of the application would be required when there are no equivalents on the .NET platform for the language in use. An example of this would be applications based on Oracle Forms. The best option in this case would be to rewrite the application on Windows using Visual Basic .NET.

A rewrite of the application is preferred in the following situations:

  • The cost and complexity of porting is prohibitively high. It may be easier to recreate the application rapidly using Visual Basic.NET, rather than porting the application.

  • The business logic is likely to change significantly in the new environment, which would limit the amount of code reused from the source platform.

  • The application requires new features and code that is specific to the Windows environment.

  • Tight integration with Windows features is required in the new application.

  • The best possible integration with other Windows-based applications is required.

  • A port is not possible either because the language is not supported or API libraries for SQL Server do not exist.

Potentially, rewriting an application can be challenging. It can be a time-consuming, risky, and costly option. The risk inherent in a rewrite is that the business logic or an important functionality is changed while rewriting the code. Careful testing and stabilizing of the rewritten application needs to be conducted to ensure proper business logic and functionality.

When porting or rewriting to Windows, migration to the .NET platform is preferred. .NET technology provides the ability to build, deploy, manage, and use connected, security-enhanced solutions with Web services. For more information about the .NET platform and its key capabilities, refer to the following two resources:

https://www.microsoft.com/net/basics/

https://msdn.microsoft.com/netframework/programming/fundamentals/default.aspx

There are situations when moving to .NET may not be feasible. For instance, at the time that this guide was published no production-ready implementations of Python on the .NET framework existed. However, this technology is currently available in a beta format, and investigation of current technologies is recommended.

Solution Design Strategy C: Port or Rewrite to Win32

The.NET Framework offers the next generation of applications and services. Migration to the Win32 platform should be considered when migration to .NET is not technically feasible for your organization. As with strategy B, two migration options are available when moving to a Win32-based platform. The first is to perform a full port of the application, and the other is to rewrite the application using the Win32 APIs. The rationale for deciding whether to port or rewrite the application to function with Win32 is the same as the rationale for using .NET. Please refer to the description in the "Solution Design Strategy B: Port or Rewrite to .NET Framework" section for more details.

Solution Design Strategy D: Quick Port by Migrating to Windows Services for UNIX

One of the quickest migration paths possible is to port the code directly to Windows Services for UNIX. Windows Services for UNIX includes Microsoft Interix, which provides a UNIX environment that runs on top of the Windows kernel. Interix allows native UNIX applications and scripts to work alongside Windows applications. The best way to view Interix is to understand it as a POSIX-compliant version of UNIX built on top of the Windows kernel. It is not an emulation of a UNIX environment on the Windows APIs. Migration using Windows Services for UNIX involves obtaining the source code, installing it in the Interix development environment, modifying the configuration scripts and makefiles, and recompiling the application. This strategy is referred to as a quick port.

The ported application may be successful immediately, or it may require modifications to the configuration scripts or makefiles to account for the new hardware platform, the target operating systems, and local configuration information. A detailed assessment of the application has to be conducted to inventory the various APIs and utilities in use. The support for these in the Windows Services for UNIX environment has to be verified. Extensive testing of the application is essential after the port to ensure that all features have been migrated successfully.

A quick port is preferred in the following situations:

  • A port for the language the application was written in does not exist in .NET or Win32. An example application is X Windows.

  • Application investments on the UNIX platform need to be reused. Interix can optimize your investments in UNIX applications by reusing code. New functionality and value can be added to your existing UNIX applications by integrating the UNIX code with .NET or Win32 functionality.

  • It is too expensive and time-consuming to do a full port or complete rewrite of the application.

  • A large set of UNIX scripts need to be ported. Interix allows you to get the most out of existing UNIX network administrator tools and skill sets. It provides more than 300 UNIX utilities, and it provides shells and scripting languages (including Perl) that enable you to run existing shell scripts with little or no change on Windows.

A quick port is not recommended in the following situations:

  • A port of the application is available in Win32 or .NET.

  • You can afford the rewrite or port to Win32 or .NET and wants to tightly integrate the application with other Windows technologies.

  • You want to significantly evolve the application by using the capabilities of the Windows environment.

  • A quick port requires huge effort in development and implementation as compared to employing one of the other methods. For example, when the required libraries available on the original UNIX platform are not available on Interix.

Most UNIX database environments use scripts to support databases and client applications. You should evaluate the importance of the services that these scripts perform. Migrating the scripts to Windows Services for UNIX is an option; however, scripts that make use of Oracle utility programs must be modified to use suitable replacements for SQL Server.

Using Windows Services for UNIX, organizations can rapidly consolidate diverse platforms, maximizing their previous investments in UNIX infrastructure, applications, and knowledge while capitalizing on Windows innovation. Moreover, Windows Services for UNIX provides a full range of supported and fully integrated, cross-platform network services for blending Windows and UNIX networks.

For a detailed discussion of Windows Services for UNIX in migration projects, refer to the UNIX Application Migration Guide available at https://go.microsoft.com/fwlink/?LinkId=30832

Windows Services for UNIX 3.5 is available as a complimentary download from Microsoft for Windows Server 2003, Windows® XP  Professional, and Windows® 2000.

Some Windows Services for UNIX 3.5 features include:

  • It is designed to work well with other major UNIX platforms and versions. It has been tested specifically with Sun Solaris 7 and 8, HP-UX 11i, AIX 5L 5.2, and Red Hat Linux 8.0.

  • It includes version 5.6 of the ActiveState Perl distribution for native Windows scripting and Perl 5.6.1 for scripting in the Interix environment.

  • It includes more than 300 UNIX utilities and tools that perform on UNIX and Windows systems in a similar manner. In addition, Windows Services for UNIX 3.5 also contains a Software Development Kit (SDK) that supports more than 1,900 UNIX APIs and migration tools, such as make, rcs, yacc, lex, cc, c89, nm, strip, and gbd, as well as the gcc, g++, and g77 compilers.

More information about Windows Services for UNIX is available from the following two resources:

https://www.microsoft.com/windows/sfu/productinfo/overview/default.mspx

https://www.microsoft.com/windows/sfu/

Migration Strategy Scenarios

Tables 2.2 through 2.5 show the migration opportunities for several scenarios of the source UNIX environment. Each scenario is a combination of the three components of database, application, and connectivity (API). The first column of the tables represents the current state in the UNIX environment, and the third column shows the migration possibilities for each of the migration strategies: interoperate, port or rewrite to the .NET Framework, port or rewrite to Win32, and port to Windows Services for UNIX.

Table 2.2: Application Interoperation Strategy

Oracle/UNIX language

API

Interoperate SQL Server/UNIX language

API

PHP

Oracle or OCI8 or ODBC

PHP

MS SQL Server or ODBC

Pro*C

OCI

Solution not available or feasible

 

Oracle Forms

Forms C or JDAPI

Solution not available or feasible

 

Perl

Oracle or ODBC

Perl

ODBC or Sybase

Python

Oracle or ODBC

Python

ODBC

Java

JDBC

Java

JDBC

Table 2.3: Application Port to Windows Services for UNIX Strategy

Oracle/UNIX language

API

Port SQL Server/Windows Services for UNIX language

API

PHP

Oracle or OCI8 or ODBC

PHP

MS SQL Server or ODBC

Pro*C

OCI

Solution not available or feasible

 

Oracle Forms

Forms C or JDAPI

Solution not available or feasible

 

Perl

Oracle or ODBC

Perl

ODBC or Sybase

Python

Oracle or ODBC

Python

ODBC

Java

JDBC

Java

JDBC

Table 2.4: Application Port or Rewrite to Win32 Strategy

Oracle/UNIX language

API

Port/rewrite SQL Server/WIN32 language

API

PHP

Oracle or OCI8 or ODBC

PHP

MS SQL Server or ODBC

Pro*C

OCI

VB

ODBC or ADO

Oracle Forms

Forms C or JDAPI

VB

ODBC or ADO

Perl

Oracle or ODBC

Perl

ODBC or ADO

Python

Oracle or ODBC

Python

ODBC

Java

JDBC

Java

JDBC

Table 2.5: Application Port or Rewrite to .NET Strategy

Oracle/UNIX language

API

Port/rewrite SQL Server/.NET language

API

PHP

Oracle or OCI8 or ODBC

Solution not available or feasible

 

Pro*C

OCI

VB.NET

ODBC or ADO.NET

Oracle Forms

Forms C or JDAPI

VB.NET

ODBC or ADO.NET

Perl

Oracle or ODBC

Perl

PerlNET

Python

Oracle or ODBC

Solution not available or feasible

 

Java

JDBC

Solution not available or feasible

 

Optimal Strategy

The factors that need to be considered while deciding a migration strategy are:

  • Business needs. The migration strategy should meet the present and future needs of the organization.

    For example, an organization may need to open its existing application to external users. Security needs to be implemented for the external users. The organization may select the rewrite strategy.

  • Technical feasibility. Migrating Oracle Forms to the Windows platform may not be technically feasible. If the new features warrant a lot of change to the current application, the organization may opt to select rewriting as a strategy.

  • Time. The time frame within which the migration has to be planned, developed, tested, and deployed needs to be decided. In addition, the actual time taken in the migration needs to be minimized to reduce the business risk.

    For example, an organization may plan to provide access to its application to the external users within three months. A quick port to the Windows Services for UNIX platform may be the best option.

  • Budget. The budget available needs to be planned. According to the money available, the infrastructure, human resources, and cost need to be planned.

    For example, the direct cost of porting may be lower than the cost of a rewrite. Also, porting an application minimizes the cost of training, as the same application is used in the new environment. The indirect cost; such as cost of maintenance, testing, and retraining, will also be lower.

Set Up a Team

To transform overall business and design goals into a clear vision for the project, an organization needs to assemble a multidisciplinary team, based on MSF roles, and with defined skill sets appropriate to the project. These roles are Product Management, Program Management, Development, Test, User Experience, and Release Management. Once assembled, this team defines the vision and scope that together provide a clear direction for the project and set expectations within the organization. During the Envisioning Phase, it is likely that only the lead person or persons for each team role will be determined. During the Planning Phase, the entire team should be assembled if it is necessary for your organization to staff each role with more than one person. More information about the MSF Team Model is available in the UMPG.

Table 2.6 lists each role with its goal and identifies its key functional areas and project responsibilities for an Oracle on UNIX to SQL Server on Windows migration project.

Table 2.6: Project Requirements and Responsibilities by Task

Role

Project responsibilities and tasks

Knowledge and skill requirements

Product Management Role    

* Ensure that the team addresses business goals and customer requirements

* Manage communications, launch planning, and feedback with customers (both internal and external)

Understanding of the organization's business priorities and goals

Program Management Role

* Drive solution design

* Manage projects to meet budget and schedule

* Manage scope and track progress

* Provide process leadership

* Project management skills

* Communication skills

* Adequate knowledge of UNIX and Windows environments and of Oracle and SQL Server databases to drive solution design

Development Role

It is recommended that two teams be created for the Development Role. One development team should focus on migrating the database, providing database administration and support. The second development team should focus on migrating the application.

 

Development Functional Team #1 (Database)

* Ensure that requirements of the Windows environment are met for the migrated database (for example, OS support for amount of memory required).

* Identify and provide access to shell and other scripts that are used to support the database being migrated.

* Migrate user accounts and verifiy that they have been migrated correctly.

* Install DBMS software and database applications on servers.

* Create database in SQL Server and migrate data from Oracle.

* Identify the time and order in which the shell scripts are invoked.

* Design and implement the appropriate security model for migrated databases, based on analysis of application and database.

* Identify and resolve issues associated with Windows security and connectivity.

* Validate that the chosen security configuration provides at least the same security levels as the existing configuration.

* Apply appropriate permissions at the database object level.

* Work with test groups to build test environment.

* Work with client development functional team on issues related to connectivity between database and application

* Knowledge of security configuration for current Oracle database and applications running on UNIX.

* Knowledge of shell and other scripts used to support the Oracle database.

* Knowledge of cron jobs, including times and the order in which scripts are run.

* Understanding of security, connectivity, software, and database installation issues in the Windows environment.

* Understanding of both the Windows and UNIX environment.

* Understanding of Network Library Oracle SQL*Net, Net8, and TCP/IP.

* Understanding of the Oracle schema, tables, views, stored procedures and triggers.

*Knowledge of SQL Server and ability to perform all these tasks in a Windows environment

Development Functional Team #2 (Application)

* Participate in assessment activities for client applications.

* Identify and articulate security requirements for client applications.

* Retarget or migrate existing client applications.

* Work with test team to ensure requirements are met and defects are reduced.

* Work with database team on issues related to connectivity or other database-related problems.

* Knowledge of Oracle client applications and their security requirements.

* Proficiency in either Perl, Python, PHP, Java, Visual Basic.NET, Windows Services for UNIX, or Windows.

* Experience with technologies for application interoperation with SQL Server such as FreeTDS.

* Understanding of stored procedures, database logic, and application logic.

* Understanding of connectivity issues with database.

User Experience Role

* Manage process of gathering, analyzing, and prioritizing user requirements.

* Help develop usage scenarios and use cases.

* Provide feedback on the solution design.

* Drive the creation of user training materials.

* Understanding of the applications being migrated.

* Experience in developing usage scenarios and use cases.

* Understanding of training principles.

Test Role

* Participate in data gathering relevant to Test during all phases of the project.

* Design and develop the test environment in conjunction with the Development functional teams for database and client migrations.

* Maintain ownership of the test environment.

* Design, create the specification for, and refine the test plan and the user acceptance test plan.

* Implement and validate the migration test plan.

Implement test cases.

* Understanding of the UNIX and Windows operating systems (including Windows Services for UNIX, if appropriate).

* Expertise with Oracle databases, application and client development.

* Experience with interoperation between UNIX and Windows.

* Understanding of tiered database systems in homogeneous and heterogeneous environments.

Release Management

* Act as primary advocate between project development and operations groups.

* Manage tool selection for release activities and drive optimizing automation.

* Set operations criteria for release to production.

* Participate in design, focusing on manageability, supportability, and in deployment.

* Drive training for operations.

* Drive and set up for pilot deployments.

* Plan and manage solution deployment into production.

* Ensure that stabilization measurements meet acceptance criteria.

* Understanding of standard operational procedures in the Windows environment.

* Understanding of applications being migrated.

* Management and communication skills.

Special Considerations for Setting Up Your Migration Team

An Oracle on UNIX to SQL Server on Windows migration project can present some unique issues for staffing your project team. Keep the following considerations in mind when staffing your project team:

  • It is relatively easy to find technical staff with a deep knowledge of Oracle and UNIX or SQL and Windows, but it is not easy to find technical staff that has a deep understanding of all of these areas. Migration involves creating a metaphorical bridge between the two environments. Make sure you have a senior architect on the team who understands both worlds deeply enough to engineer the bridge's creation. If the skill is not available in-house, consider finding a consultant or a consulting organization with experience in this form of migration. The consulting organizations often offer services to complete these migration projects end-to-end. It may be possible for you to successfully implement the migration with lowered risk and reduced cost by engaging a consulting organization. For more information about Microsoft partners that offer Oracle to SQL Server migration services, refer to https://www.microsoft.com/sql/partners/migration.asp

  • Ensure that the hardware and infrastructure experts from the Development Role and Test Role are actively engaged during the Envisioning Phase. The hardware on which databases and applications are run is commonly overlooked until later in the project life cycle than it should be. Involving the experts early in the project will help inform more accurate estimates regarding budget, time, and resources.

  • The Test Role should include, if possible, team members who have worked with the application being migrated. Their experience will help them write better test cases.

  • The User Experience Role should include, if possible, team members who have worked with the application in the UNIX environment. They should have a good understanding of the application's user interface so that they will be able to define and provide the training required for end users after the application migration.

  • Consider including in the Test Role team members who have the expertise to test the security of the migrated environment. The security of the migrated application is often overlooked in migration projects.

  • Migration projects are often undertaken using existing technical staff who have day-to-day responsibilities which impact their availability. Resources should be properly planned and allocated to the project to avoid such impact.

  • Technical staff that has experience with the current application and database should be involved in the project from design to deployment. Any required training should be provided to improve their utility in the migration.

  • Security, hardware, and infrastructure experts from Operations should also be involved in the Envisioning Phase because they can provide valuable advice about the technical availability, costs, and the capabilities of the organization.

  • Because moving from Oracle on UNIX to SQL Server on Windows is a major paradigm shift, it could impact the employment and careers of existing personnel. This issue should be considered when forming the team and carrying out the migration. Change is often inevitable and should be perceived as a way to expand and develop skills.

Define 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 the team will use during the project. These include communication standards, documentation standards, and change control procedure standards. Program Management takes the lead in defining the project structure.

Refer to the UNIX Migration Project Guide for detailed information about project structure. Use the Project Structure document template to assist you in defining and recording the project structure and protocols for the project team. This template is available in theTools and Templates folder in the zip file download of this guidance at https://go.microsoft.com/fwlink/?LinkId=45289.

Define Project Communications

Program Management should use the project structure to define standards for team members to communicate with one another. Among these standards can be a definition of the reporting structure under which team members operate, procedures to elevate project issues, regular mandated status meetings, and any other project-specific communication standards that need to be defined during the Envisioning Phase.

The document may also include e-mail names, aliases, telephone lists, mail addresses, server share names, directory structures, and other information critical to team organization. Consider establishing a team collaboration environment where communication can occur and progress be monitored and updated as necessary. The following list of factors needs to be considered for most Oracle on UNIX to SQL Server on Windows migration projects.

  • The project team will likely include members from the UNIX domain of the IT department as well as the Windows domain. There are often work-based cultural differences between members of these two domains. The Program Management role should ensure that this potential difference is identified and extra attention is paid to ensure clear communication between the members of the two domains. Similarly, the communication tools used by the UNIX and Windows users are often very different. For example, Windows users use the calendaring features of Outlook extensively for team communication. The UNIX users may be accustomed to a different set of tools or clients.

  • Different geographical locations and different cultural backgrounds of team members involved in the migration effort can cause communication issues. Extra attention is required to make sure that there is clear communication between all team members.

  • Determine secure methods to share information about the project among the team members. If your team comprises consultants and in-house employees, there may be corporate policies about what information can be shared with outside consultants.

Define Change Control

Change control standards and tools help to manage both project documents and components of the solution that are subject to revision or iteration. The requirements should be clearly defined in the project structure. General information about change control is available in the UMPG.

Migration projects have an additional source of change that is not obvious but must be managed: the initial state of the technology being migrated. This could be source code for applications, hardware and software configuration, and versions of application software. Although the initial state can be baselined when the migration project is started, operational needs may require changes to that configuration while the migration is under way. These operational changes are typically subject to Configuration Management standards imposed by an operations team.

The Program Manager Role and Release Manager Role should work with operations personnel responsible for the existing technology to minimize and accommodate these changes. Long-lived migration projects may require a formal process to connect operational Configuration Management to project change control. Here are some additional points to remember:

  • The major difference between a migration project and a new development project is that the initial work has already been performed to create the existing solution. The existing solution provides a working example of the goals which the solution must meet.

  • Depending on the long term objectives of the project, an existing change control tool and repository on the UNIX platform may be migrated to tools in the Windows platform.

  • As migration involves making modifications to objects currently in production, care has to be taken in how these objects are shared with the new development effort. As changes are discovered, there is the danger of modifying an object in the production thread. Creation of a separate project is recommended. In this situation, any changes made to the production thread should also be applied to the development (migration) thread. Appropriate controls have to put in place to handle this.

Configuration Management

A major task in any database migration is the transformation of database objects, such as sequences and code within the database, including stored procedures. These transformations inherently change the source code. To maintain a known state as work progresses towards migration, two aspects of Configuration Management have to be addressed:

  • As discussed earlier, any change to the original environment after the baseline is created needs to be communicated to the project team and accounted for. Change management in the area of configuration becomes critical if problems are encountered during the migration and you are forced to return production to the pre-migration environment.

  • Any changes to the solution that occur during the Developing Phase and Stabilizing Phase need to be documented and communicated to the entire project team.

During the Stabilizing Phase, knowledge of and control over the test environment configuration is critical to understanding the results that are received. If documentation exists identifying the aspects that have changed, the results of a given test can be validated against both current and future results.

Some points to remember include:

  • Every configuration change should have a fallback or rollback path.

  • Configuration management tools, such as bug tracking software, should be able to operate within the Windows environment.

Assess Risk

MSF stresses assessing project risk continuously throughout a project and makes this the responsibility of every team member. Risk is defined as the possibility of suffering a loss or, more specifically, the possibility of a negative outcome that can put the project in peril. The team comes up with an initial set of risks in the Envisioning Phase. This list is constantly updated in later phases of the project as new risks begin to appear and old ones start to lose relevance. It is important to understand that in a migration project issues are sometimes hidden, for example, in the design or implementation of a piece of code, which will appear only as the solution is being transformed. Here are some questions that you need to ask to understand the potential high level risks at the start of the project. These questions can help you generate the risk assessment list that can serve as the basis for your ongoing risk assessment and management for the project.

  • Are the project sponsors and stakeholders committed to support the project?

  • Does the migration team have the aggregate skill set to perform the migration?

  • Are the project team members adequately motivated to perform their role in the project?

  • What will the impact on the business be if there is a delay in the project completion?

  • Do you understand the real problems of the business and users that the project is meant to address?

  • Have you accounted any possible temporary decrease in productivity due to distractions for the project staff from their daily duties to support the migration project or while the customers learn to use the new application?

  • For the application suite to be migrated, do the vendors of any third-party applications provide technical support in the new environment?

  • Is the application dependent on third-party software that is not compatible with Windows?

  • Does the existing Oracle database contain technologies that SQL Server cannot directly implement?

  • Have you fully considered the impact of the migration on other systems or applications that currently rely on or interact with the existing solution?

  • Does documentation exist for all the applications and databases, such as requirements, models (logical, physical), and source code?

  • How will you handle possibly unproductive situations from staff members (technical and operational) who could be displaced by the migration?

  • How will you handle possible scope creep in the migration project?

  • Have you considered the impact of the migrated application failing to meet one or more functional requirements?

Manage Risks

A good way to manage risks is to identify or anticipate potential risks beforehand and come up with a good mitigation and prevention strategy to deal with them in case they occur. The list of potential risks for a project is likely to be long, and not all potential risks can be given the same amount of attention over the course of the project. It is therefore imperative to prioritize all the risks. This allows the team to focus more on the high priority risks, come up with suitable mitigation plans to prevent them from happening, and create contingency plans to deal with them effectively if they materialize.

This solution guide provides a risk assessment spreadsheet for you to monitor your project risks based on this methodology.

Download

Get the Solution Guide for Migrating Oracle on UNIX to SQL Server on Windows

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions