Chapter 2: Envisioning Your Novell to Windows Migration Project

  • Article
On This Page

Introduction and Goals Introduction and Goals
Setting Up the Core Project Team for a Novell to Windows Migration Project Setting Up the Core Project Team for a Novell to Windows Migration Project
Creating the Vision Creating the Vision
Creating the Solution Concept Creating the Solution Concept
Defining the Scope of the Project Defining the Scope of the Project
Project Timeline Project Timeline
Assessing Project Risks Assessing Project Risks

Introduction and Goals

This chapter provides the background and technical information required to complete the first phase of a Novell to Windows migration project, which represents an early form of planning. The purpose of this initial work is to get the project started by achieving a basic agreement between business stakeholders and IT, as represented by the project team, on the goals for the project as well as its constraints.

This section provides the background and technical information required to complete the first phase, the Envisioning Phase, of a Novell NetWare to Windows Server 2003 project.

The guide makes the following basic assumptions about the state of the organization at the beginning of Envisioning.

  • A decision to investigate the project has been made by an IT manager who has sufficient budgetary authority to fund the investigation (Envisioning and Planning phases), and who may or may not have sufficient budgetary authority to approve the entire project.

  • Rough estimates indicate that project benefits will exceed its costs, but detailed return on investment (ROI) calculations cannot be made until the project scope is defined.

  • Whether the team that undertakes the project is made up of in-house staff or of consultants (whose involvement in IT for the organization can range from the undertaking of a single project to an ongoing advisory relationship), the work of Envisioning and Planning remains the same.

Major Tasks and Deliverables

By the end of the phase, the team and all major stakeholders for the project should have agreed upon the following conceptual areas and documented their understanding in a vision/scope document:

  • A vision for the solution

    • 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 environment (at a high level) with respect to the technology being considered.

    • Describes the desired future state of the organization's environment from an unbounded viewpoint.

  • A solution concept

    • Describes at a high level how the solution will solve the business problem in terms of the approaches it will take 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.

  • The scope of the project

    • Defines the project scope by listing which desired features and functions the project will provide, solution tradeoffs, and 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.

  • An assessment of risks

    • Identifies risks belonging to the project.

    • Attempts to qualify and prioritize these risks.

  • A rough estimate of the project time frame and duration

Together, these conceptual areas comprise a high-level description of the project that will form the basis for further planning. They represent a baseline and may need to be revised as planning progresses and new information dictates—thus the vision/scope document should be viewed as a living document that will change, subject to change control.

Additionally, during this phase, you will:

  • Identify and organize a core project team. Additional members can be added later.

  • Create a project structure document that:

    • Documents the team organization

    • Establishes communication and meeting logistics

    • Sets the ground rules for team responsibilities

Refer to the Unix Migration Project Guide for more detailed discussions of how these tasks and deliverables can be approached and responsibility assigned for them.

Envisioning Phase Major Milestone: Vision/Scope Approved

The Envisioning Phase ends when the team, the customer (business sponsor), and major project stakeholders (other members of the organization who will be affected by the project) 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. At this point, the various business and IT stakeholders should have a clear idea of the goals for the project and the project team can begin to make specific plans for how to achieve them.

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" amongst the stakeholders and project staff, significant time or cost overruns, or even project failure, will occur. See the UMPG for more details.

Setting Up the Core Project Team for a Novell to Windows Migration Project

The number of project team members for a Novell to Windows Server 2003 migration will vary based upon the size of your organization. In small organizations, a project team may only consist of a manager and a developer. In contrast, a large organization may have multiple participants from any number of departments. In fact, the entire team may not be set up until the Envisioning Phase is well under way. The UMPG defines a clear process for setting up a team.

Team members should have a clear understanding of the Microsoft file server technologies for Windows Server 2003 and Microsoft Active Directory services. Team members are also expected to have a working knowledge of your environment in the following areas:

  • Novell File Services and trustee permissions

  • E-Directory/NDS concepts

  • Centralized storage and backup concepts

  • Storage technologies, such as network-attached storage and storage area network (SAN) (if applicable in your environment)

  • Networking and connectivity

  • Service operations

Creating the Vision

Before you can migrate to a new Windows Server 2003 Active Directory environment you must first determine what that environment will look like and then develop a migration strategy for how to get there.

A Vision for the Solution

The vision starts with a business problem. This problem should be the driving factor in your investigating migration to Windows Server 2003.

Some common business drivers for migrating from Novell NetWare to Windows Server 2003 include:

  • Discontinued support for Novell NetWare. In the next version of Novell, the operating systems will no longer be NetWare; it will be Novell on top of Linux.

  • Difficulty of upgrade to new Novell NetWare version. Organizations with existing versions of Novell will have to build the Linux infrastructure and then migrate to the new version.

  • Multiple operating systems in one environment– Pure Novell environments are rare. Increasingly Windows NT or Windows 2000 has already been introduced into Novell environments to host applications and services. With the change to the base Novell operating system, maintaining Novell and Linux along with Windows increases administrative and training requirements. In addition, resource availability becomes an issue, as it is difficult to find engineers that are well versed in all three operating systems.

Defining the Goals

The following discussions cover specific business and technical issues that you should consider for a Novell NetWare to Windows migration project when you are answering the questions that need to be addressed in the vision/scope document.

Business Goals

Business goals are established either to take advantage of an opportunity or to solve a problem in your current business environment. The team begins defining its project by identifying the business goals, and then derives project goals and objectives from those business goals.

Typical business goals for a migration from Novell to Windows include but are not limited to:

  • Reducing the total cost of ownership (TCO)

    TCO of a new operating system includes not only the price of purchasing software and hardware but also the cost of training staff as well as supporting and maintaining the system. Therefore, while identifying the TCO of the migration to a new operating system, you should explore questions such as:

    • What is the cost of your hardware?

    • What is the cost of your operating system?

    • What is the reliability of the system? If the system fails or crashes often, the support cost for such a system would increase.

    • What is the cost of application downtime to your business?

    • What is the cost of system maintenance? How many people would you need to maintain the system?

    • What is the cost of support?

  • Increasing the usability of the system

    The applications on the system should be easy to develop and use. Systems that offer integrated security and development environments for applications are optimal.

  • Providing ease of manageability

    The system should provide easy, secure, reliable, and scalable ways for the administrators to install, manage, and maintain the operating system, new software, existing software, and patches.

  • Providing ease of scalability

    The system should be scalable to meet the ever-increasing performance requirements of applications. Scalability of the system includes the capability to scale up by adding more processors to the existing system or scale out by adding more computers and faster interconnects. It is important to understand the scalability of the initial system configuration and how well it can be upgraded in the future as workloads and data volumes increase over time.

  • Having a system that is fully supported.

  • Limiting the number of operating systems.

  • Minimizing the impact of any migration process on the daily business

  • Meeting regulatory requirements such as Sarbanes-Oxley, Gramm-Leach Bliley, HIPAA, and others.

Technical Goals

Business goals are often intertwined with technical goals for the new environment. Some common technical goals include:

  • Support for Internet standards

    Native LDAP implementation with integrated DNS namespace support

  • Interoperability

    Supports multiple synchronization, connector, and meta-directory technologies and publishes all services using LDAP

  • Advanced protocol and media support

  • Support for a multilanguage development environment

  • Advanced platform services

    Supports thin client access, Voice-over-IP telephony, and streaming media services

  • Broad, industry-wide application support

  • Taking advantage of the features of Windows Server 2003 Active Directory

    • Simplified administration with advanced tools, delegated administration capabilities, and integrated desktop management capabilities through the use of Group Policy Objects (GPOs).

    • Enhanced security through the use of integrated Virtual Private Network (VPN) support, Kerberos authentication, Encrypted IPSec communications, and Public Key Infrastructure (PKI) support.

    • Increased reliability with support for integrated file and storage services such as removable and hierarchical storage management, dynamic volume management, file replication and distributed file system (DFS).

    • Greater availability with support for integrated high availability services such as clustering, load balancing and file replication services for file servers

Assessing the Current Business Situation

You must identify the gaps between the current and desired states of your business to create a solution that fulfills the business goals. Performing a gap analysis helps you identify problems in the current business environment and develop a path to the desired state of the business. Different types of business issues that you need to assess may include:

  • Business policies

  • Business operations

  • Existing system performance, including downtime impact

Vision Statement Examples

Based on the business problem examples at the beginning of this section, here are some sample vision statements:

  • To have file, print, and directory services running smoothly and efficiently in a Windows environment.

  • To have file, print, and directory services running smoothly and efficiently in a combined Novell and Windows environment.

The vision statement should always address key business problems in the organization. It defines the expected end result of the project. Keep in mind that the vision statement covers what the system will look like when you complete the project, not how you get to that end state.

Creating the Solution Concept

The solution concept describes at a high level how the solution will solve the business problem in terms of approaches it will take to build and deliver solutions. This is the earliest version of the functional specification and plans that you will develop in the Planning Phase.

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 analyses, including feasibility studies, risk analysis, usability studies, and performance analysis that will help the team develop the solution in more detail during the Planning Phase.

  • Communicate the proposed solution to the customer and other key stakeholders.

The foremost question to answer at this stage is whether you should migrate over time (phased migration) or all at once (direct migration).

Phased vs. Direct Migration

You need to evaluate the different levels of impact a phased or a direct migration might have on your organization. You should consider the cost and the risk associated with the two types of migration and, correlatively, evaluate the network management structure.

In a phased migration, both directories remain in place for the duration of the entire migration effort and directory synchronization must be established. If this is not feasible or if you do not want to maintain multiple network operating system directories, the best choice is migrate quickly and completely to a Windows Server 2003 environment.

The cost of the slower, phased migration tends to be higher for two reasons: first, the work is carried out over a longer period of time; second, you must manage and support two different infrastructure systems simultaneously. However, the risk is lower because rollback can be done easily and problems can be resolved during the migration project with less impact to the production system.

In contrast, the quicker, direct migration has a lower cost but the risk is higher. The cost is lower in terms of both the amount of time needed to make the switch and the lower support impact on the system. However, the risk is higher because any technical problems that arise can create greater disruption to production processes.

Phased Migration

If you want to maintain an environment that contains both Active Directory and Bindery/NDS directory services, you can perform a phased migration and run the two systems in parallel. This allows you to perform additional migration tasks (other than synchronizing the two directory services), such as replacing applications that are dependent on Novell services with Active Directory-compatible applications.

Additionally, large migration projects are usually phased migrations. For scenarios where direct migration is appropriate, see the “Direct Migration” section.

A phased migration reduces the risk of data loss because you can migrate in managed stages and you can reverse the process if necessary. However, maintaining two separate directory services can, over time, add additional administrative costs to the migration.

If you plan to perform a phased migration, you will need to consider synchronization. For more information on synchronization, see the “Synchronization” section in the Planning chapter.

Direct Migration

A direct migration is suitable for small to medium-sized organizations that have not deployed NDS-dependent applications. Migration in these cases can normally be accomplished in a short amount of time with minimal impact to business operations. A direct migration is also feasible if you are setting up a large number of new desktops or you have an older Bindery or NDS network and need to move to a more sophisticated operating system. For example, environments that only provide limited services such as account information and file and print services are relatively simple migration projects.

Direct migration is exactly what it sounds like: a single process to migrate the existing directory and all file and print data, followed immediately by the migration of the printers and finally the workstations.

This process can only be performed if there are no requirements to maintain legacy Novell systems and your environment is small enough or you have enough resources to migrate all of the workstations in the environment. In addition, all applications must be fully tested before migration to verify that there is no longer a requirement for a Novell server.

Network Systems and Services Migration

When you reach the Planning Phase, you will be able to plan more effectively if you know which services can be easily migrated from a given NetWare environment to Windows Server 2003 and which tools you can use to perform a given migration task.

Part of your solution concept will be what version you are currently using and what your end environment will be: a Windows environment or a mixed Windows and Novell environment. This section summarizes Netware environments and the corresponding options for migration to help you make the necessary decisions.

NetWare 3.x Environments

NetWare 3.x services typically include file, print, and limited Internet services. NetWare 3.x environments use binderies to store user account and other resource information. The binderies are maintained on each server in the network, but replication of account information is not provided between servers. Individual implementations of bindery services normally include file and print services; however, older versions of messaging, applications, and databases might also be present that rely on NetWare 3.x services.

  • Migrating to Windows Server 2003

    Migration of NetWare Bindery environments is simpler than migration of other Novell environments, because only a small number of services are subject to migration. Further, migration from NetWare Bindery to Windows Server 2003 Active Directory is almost always desirable unless some specific application or service, such as Novell GroupWise, prevents the migration.

  • Maintaining NetWare and Windows Server 2003

    If migration is not an option, you can implement interoperability easily at several levels. The Windows Server 2003 operating system includes support for connecting to NetWare Bindery servers or for using Microsoft Directory Synchronization Services (MSDSS), a tool included with Services for Netware, to synchronize accounts with the Windows Server 2003 Active Directory.

NetWare 4.x, 5.x, and 6.x Environments

The later versions of NetWare include a new directory platform named NetWare Directory Services (NDS). NDS acts as a centralized directory service for NetWare users and requires more planning than a Bindery migration.

  • Migrating to Windows Server 2003

    Migration of a NetWare 4.x, 5.x, or 6.x environment to Windows Server 2003 is more complex than a 3.x migration, as the NDS directory should normally be migrated. This presents its own unique challenges, as users and groups in NDS must be created and synchronized with Active Directory users. File data on NDS servers must then be migrated and security permissions re-applied through specialized tools, such as the Services for NetWare or Quest NDS Migrator tools.

  • Maintaining NetWare and Windows Server 2003

    Active Directory and NDS provide a certain level of interoperability because of a common implementation of standards. However, namespace management and other network standards are handled differently by NDS and Active Directory.

NDS Namespace Mapping

You can map the NDS hierarchical directory namespace to the namespace used in Windows Server 2003 Active Directory. However, in most circumstances, the optimum Active Directory namespace will not be the one used by NDS. This disjointed mapping is because of differences between the basic methods of partitioning and replication.

NDS namespace mappings that are similar to an optimal Active Directory namespace might occur if a geographic namespace model is used for Active Directory. It is common for NDS implementations to follow this model to accommodate partitioning at the organizational unit (OU) level.

Similarities and Differences Between NDS and Active Directory

There is an excellent white paper, "Comparing Microsoft Active Directory to Novell NDS version 8" (https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnactdir/html/msdn_activedirvsnds.asp), which details the contrasts between the concepts and mechanics of NDS and Windows 2000 Active Directory. Although this paper was written primarily for Windows 2000 environments, it is a highly useful resource.

Keep the following similarities and differences in mind when you design your new environment and determine which services will be migrated to Windows Server 2003:

  • Replication. NDS and Active Directory both provide replication services for the directory within each partition.

  • DNS/DHCP. NDS provides support for basic DNS services while Windows Server 2003 provides enhanced DNS Services including dynamic updates. Windows Server 2003The DNS offering in Windows Server 2003 is extremely robust and provides greater unification of name services and Microsoft Windows service offerings. Despite the differences, both DNS implementations are capable of interoperating through standard zone transfers.

  • DHCP. Both NDS and Windows Server 2003 support the Dynamic Host Configuration Protocol (DHCP), which allows for the automatic and controlled distribution of client IP addresses on a network. The primary difference between NetWare and Windows Server 2003 DHCP has to do with their capability to integrate with the DNS dynamic update protocol.

  • LDAP Services. Both NDS and Active Directory are compliant with LDAP version 3. While the implementations are interoperable, it is important to test applications and services that take advantage of LDAP lookups before migrating those services from NetWare to Active Directory.

  • Internet Services. From a high level, both NetWare and Windows Server 2003 provide similar Internet services, such as Web services. However, there are significant differences in the way that Novell Web applications are written and processed. When porting Web applications from one platform to the next, it is important to perform extensive testing.

  • Authentication. The products use completely different methods and protocols for authenticating clients. Windows Server 2003 uses Kerberos authentication over IP only. NDS authenticates using NetWare Core Protocol over either IP (for NetWare 5.x and later versions) or more commonly IPX.

  • Network Security. From a high level, NetWare 5.x and later versions provide a set of network services that is similar to Active Directory. These include support for secure sockets layer (SSL), X.509 digital certificates, and security policies. If interoperability between security implementations is desired, you should focus on the use of SSL and public key infrastructure (PKI) to ensure a good level of interoperability. Both platforms support many similar security policies such as account lockout, access control, password policies, etc.

  • Network Partitions. With very few exceptions, do not attempt to make a direct correlation between NDS partitions (which are disassociated with namespace) and partitions in Active Directory that map to DNS domains and namespace.

Defining the Scope of the Project

The scope of the project starts to take shape after the business goals have been defined. For example, many organizations choose to limit the scope of their migration project to the first step, essentially building the future Windows Active Directory environment, to focus on creating the foundation for future growth. This approach builds the infrastructure on which you will migrate the directory and file and print services. After you have a solid Windows Active Directory infrastructure in place, you are ready for future phases or projects, such as mail and application migration. By effectively limiting the initial scope of the migration, you have less to worry about, particularly in the areas of application compatibility, desktops, scripts, etc. The scope of your project will depend on your business goals and their relative priority.

To help define the scope, you need to answer these questions:

  • How many servers will need to be migrated?

  • Where are these servers currently located?

  • What services are currently provided by the legacy platform that will need to be migrated?

  • Will data be consolidated?

  • Do all applications need to be tested or just specific business-critical applications? As a result, what core business applications will need to be upgraded or replaced?

  • What additional applications and devices need to be upgraded or modified to support the new servers and applications?

  • How will this migration affect the desktop configurations and applications?

The answers may not be obvious at this point in the process. But asking the questions and engaging in "what if" discussions and speculations can identify the primary pieces of the puzzle. Based on the goals and objectives for the project and the answers to these types of questions, the high-level scope of the work begins to take shape. Here are some general rules to consider:

  • Keep it as simple as possible.

  • Break up the project into logical segments.

  • Don't forget that the staff and user community will need to learn new skills to be productive.

Project Timeline

A final task to accomplish before the end of the Envisioning Phase is to prepare an estimate of the time frame for the project. It is common for the goals of the project to dictate the timeline, as a migration can affect other critical business project dependencies. All timeline decisions are preliminary at this point, but this early timeline will be important as a basis for the project schedule you will prepare during the Planning Phase.

One approach to sketching out the timeline is to start by setting a completion date and then working backward. This helps to develop a range of time that is available for each phase of the process. Even when the deadline for the completion of the project is the infamous "by yesterday," time should be allocated for the Planning and Stabilizing Phases. If a migration begins without planning or a clear understanding of the desired results, the result will often be flawed.

When migrating directory and file and print services, depending on the scope of the project, a time frame of two to four months is considered to be a short time frame, with four to six months offering a more comfortable window (the length of the deployment in a phased migration will be based upon your business needs). Within this time frame, several weeks are available for planning, a similar amount of time is available for the development and testing process, and then the deployment can proceed. The size and number of objects to be migrated will determine the actual length of the deployment.

Remember that change will bring with it a learning curve for both the user communities and the administrative staff. The greater the amount of change that employees need to adjust to, the more support and training will be required to ensure their productivity when the new platform is rolled out. Be sure that the necessary training will occur before the date that the users need to be fully productive on the new system.

Note: Hardware and software procurement can also cause delays, so for shorter time frames, they should be procured as soon as possible after the ideal configuration has been defined.

Assessing Project Risks

Risk is a part of every migration. Risk management involves anticipating, addressing, mitigating, and preventing risks. Prioritizing risks enables the team to address high-risk items early. Refer to the UMPG for guidance in the risk management process. After you come to some agreement about a vision, scope, and solution concept, you will be able to consider the risks your project faces and come up with a preliminary risk assessment, as one of the final tasks of the Envisioning Phase.

Some of the common risk conditions in a migration project include:

  • Existing directory problems, such as corruption

  • Application compatibility issues

  • Time frame—a short timeline that often requires cutting corners in the testing process

  • Bandwidth— WAN or LAN connectivity issues

  • Budget constraints

  • Lack of in-house expertise and resources for the project

  • “Political” issues

  • Lack of hardware and software availability