This lesson identifies key issues that should drive the move from Windows NT 4.0 to Windows 2000. It provides a checklist of items you should consider and prioritize according to your goals.
After this lesson, you will be able to
Estimated lesson time: 25 minutes
Microsoft Windows 2000 has raised the standard on providing comprehensive security within an operating system. Next-generation applications such as Microsoft Exchange Server 2000, which depend on the underlying Windows 2000 Active Directory directory services, are now in demand. However, moving a corporation from a flat Windows NT domain structure to Active Directory demands extensive planning and testing. Windows 2000 isn't simply an upgrade of Windows NT, it's an entirely evolved product offering a wider range of functionality and flexibility. Hence, if the migration were to fail, it could be catastrophic for your organization.
A goal is a general statement of purpose. You can set goals with respect to the overall business or in terms of the migration project. The business goals are the reasons you are embarking on the effort (for example, "we want to decentralize management of our systems"). The migration goals are the objectives to be achieved (or maintained) by the migration process (for example, "we want to deploy an Active Directory–based organization of resources"). Migration goals will include some that relate directly to the migration process itself (for example, "at no point during the migration will DNS requests fail").
The first phase of the project is the mapping of the business goals to the migration goals, based on your knowledge and experience gained during the evaluation phase. You must revisit this mapping during the project to ensure that the core issues are still being addressed and that no changes are required in light of newly acquired knowledge.
When you're mapping business goals to migration goals, you need to prioritize each of the objectives. For example, a business goal of "there will be no system downtime" might conflict with the goal "the migration won't require the purchase of any additional servers," because redundant systems might be required if the first goal is to be achieved.
You must prioritize the goals before you begin the project and involve all the stakeholders. You should also revisit the goals regularly and adjust the priorities as business circumstances change during the migration.
Setting goals and priorities might significantly impact the organization politically. Therefore, you should make sure that a clear chain of command exists up to the highest levels and directly involves your executive sponsor (that is, the "boss" or CEO in charge of the project).
Consider the following list of goals and decide which are business goals, which are migration goals, and which might be mutually conflicting. Then check your answers with those provided in Appendix A, "Questions and Answers."
When considering the project, you should understand the concepts of vision and scope. The vision reflects the short-term and long-term project goals. The scope sets the project's bounds by defining what's to be delivered and, equally importantly, what isn't to be delivered. Consider the following issues in light of these two concepts:
You should consider each of these issues with respect to your organization's needs and develop a set of migration goals. You can then use these goals to prioritize the work and to aid you when you present the project to management.
After carefully considering the issues, you might feel that no migration is required. However, your system is unlikely to be completely static. Based on historical evidence, development for Windows NT applications will wane after a while in favor of Windows 2000–based applications, such as the Microsoft BackOffice 2000 suite of products. Current Windows NT systems would be unable to take advantage of these products' benefits.
Before you begin the migration process, you will need to plan for all the potential risks and implications. The migration should be part of a managed project to obtain the most benefit from the new Windows 2000 facilities and to minimize disruptions caused by the migration itself. It is important that you consider the project from both a business and a technical perspective and perform the tasks described in the following sections.
In the first phase of the project design, consider the deliverables to be expected and have a detailed description of each of the objectives and scope. The objectives will identify the project goals; the scope will identify those systems and processes that will be affected by the migration (and those that won't).
You should also set broad measures by which you can judge the project's success, such as "15 percent fewer support calls relating to password resets." You must have sound business reasons for the migration; otherwise, there's no point in performing it at all.
To develop your deliverables, list each of the goals, and then map each goal to a set of quantifiable end-points. For example, if one of the goals is to increase overall security, three of the deliverables might be to implement Internet Protocol Security (IPSec) for data encryption across the network, install Windows 2000 Certificate Services for two-way validation between clients and servers, and have a local data encryption policy using the Windows 2000 version of NTFS. You would then put a time frame on each of the deliverables and develop a budget for hardware and labor costs. You can use this methodology to outline a business case for the migration.
When creating a business case, remember to use a language and format appropriate for the target audience.
If the migration is to succeed, it must have a proper mandate within the organization. This means that senior management must be convinced of the importance of the effort and provide appropriate support.
Whenever there is any sort of major change within an organization, there will be some resistance. There might be a few people who are unconvinced of the benefits of Windows 2000 and might cause the migration project to falter or lose impetus at crucial points. To minimize these delays, those initiating the project must obtain proper levels of support and involvement at appropriate levels. It's best if you can identify an executive sponsor who will drive the project at the highest levels.
Everyone in the organization should understand the migration issues and benefits. Hence, you must create a communication strategy by which to promote information concerning the migration.
Members of the upgrade project team will naturally need to communicate, but you should keep staff at all levels who are affected by the migration well informed. You might want to produce newsletters, handouts, e-mail lists, discussion groups, and Web sites as appropriate.
If your organization has a corporate newsletter, internal Web site, or similar means of corporate communication, its representatives should be directly involved in establishing and promoting your project from the start.
The project must be sold to the organization as a whole. Everyone who will be required to change their working practices as a result of the change, or whose work will be disrupted during it, must be told why the project is necessary and the benefits it will bring.
This process will also involve managing people's uninformed expectations that the migration will provide more benefits than is realistic.
Any significant project contains a set of potential threats to the business processes remaining on-line. Create a risk analysis plan by assessing what could potentially go wrong with the migration and the steps that need to be taken to avoid these potential disasters. If you don't do this from the outset, business performance could be negatively impacted should an unplanned-for complication arise during the migration.
Consider everything that could fail at each phase of the project. Examples include hard disks crashing during the operating-system upgrade, application software proving incompatible with the new environment, or key personnel leaving during the project.
In summary, when building the business case, you must identify any obvious risks and describe the measures you'll use to deal with them.
For every change, you should determine the level of risk (how likely a problem is to happen) and the impact of the risk (which systems, processes, budgets, and timelines will be affected). High-level risks with high impact will require contingency plans—for example, preparing a level of rollback for critical changes that could be prone to failure. Examine Microsoft's Knowledge Base regularly on the Microsoft Technet Web site at www.microsoft.com/technet for any potential technical showstoppers and solutions to such problems.
Business continuity should be a regular part of every project meeting—risks should never be considered only at the outset.
The project should contain a pilot phase in which you create and test small-scale installations. You can then evaluate them before you undertake a business-wide change. This is a good way of minimizing risk and plays a part in training as the project enters later phases.
Although creating a project plan for the migration doesn't guarantee success, not making one can virtually doom any large-scale migration to failure. The plan should identify specific migration phases and provide a roadmap of the development. Your target organization might have a preferred project planning and management methodology. If so, you should use it.
Note that the issues described in the preceding sections apply not only to the Windows 2000 migration process, but to any large-scale endeavor. Consider using project management tools such as Microsoft Project.
Consider the following statements and decide whether they are concerned with vision or scope. Check your answers with those provided in Appendix A, "Questions and Answers."
In this lesson, you learned that you must start with the project's business goals and ensure that they're met by the migration goals. You also saw how essential it is to plan the Windows 2000 migration and not consider it to be merely a simple change of operating system. You should approach it as a properly managed project with far-reaching consequences to the organization.
You also learned that you must identify specific goals for the upgrade. You should set these goals in consultation with those at the highest level. You should also have some means of assessing the project's success, measured in light of the goals set.
In addition, you must promote the project within the organization so that everyone understands why it's being performed and the benefits it will bring. You should start the promotion at the outset and involve all who will be affected by it.
Finally, the project must also contain risk assessment at every level, with the development of alternative contingency plans where appropriate. Prototyping and pilot scheme evaluation must also occur when appropriate.