10 REASONS TO WAIT
1. No problems that need solving
Deploying a product just because it has some nifty features is a bad idea. You need to make a business case for Win2K in your company, including what problems the OS will solve; whether, how, and when the OS will save the company money; and what new capabilities (i.e., capabilities that will save the company money or make money for the company) the OS will enable. Financial officers and stockholders think in these terms. Your business case will help you determine how quickly to deploy Win2K in your company.
2. Thirty million lines of code
Win2K is the largest programming artifact in existence. Despite the unprecedented number of users that Microsoft encouraged to test the beta code and report bugs, the OS's size creates numerous places for code to fail. Unless you have a compelling reason to migrate immediately, wait until Service Pack 1 (SP1) for a large migration (see "When Should You Jump?").
3. First through the minefield
Users' early rollout experiences with an OS generate the bug reports that power service packs. So, you need to keep up with users' Win2K experiences through conferences, user groups, and the trade press. Find out how companies are implementing the OS, what successes they've had, what problems they've encountered, and how they worked around the problems.
4. DNS
A major topic for many companies is how Win2K, which relies on DNS and its latest extensions, integrates with a company's existing DNS infrastructure. This problem is larger than you might think, not because of the technical aspects but because most companies' production DNS runs on UNIX. Because NT and UNIX are notorious rivals, this situation generates OS loyalty concerns.
5. Application requirements
One of Win2K's main purposes is to support applications. Win2K enforces application requirements more stringently than NT 4.0 does, and almost all applications that work with hardware will require new Win2K drivers. Therefore, you need to get all your applications ready before you can roll out.
6. Support infrastructure
Your support infrastructure must change to take advantage of Win2K. You probably designed much of your support around NT (or rather NT's limitations), with a centralized or semicentralized Help desk and every major administrative entity in a separate domain. If you migrate to Win2K and push administrative rights further down into the organization, your support process will need to change. In fact, your support infrastructure will likely need to change for any Win2K installation that isn't just an upgrade in place. You need to work out these details before you migrate.
7. Need to plan
Because Win2K is a complex OS, you must do an unusual amount of planning before you deploy it. If you don't know much about the OS, you have a lot to learn. Then you must gather customer requirements, do design work, test, and pilot. 2000 will be a busy year.
8. Training
Managing a Win2K network is vastly different from managing an NT network. The challenge is training your support organizations early in Win2K concepts, operations, and administration tools. You need to train a core of personnel, preferably the sharpest people on each team, as early as possible. An experienced core of support team leaders can hold the organization together while everyone gains practical experience and can help bring other personnel up to speed.
9. Mixed environment
A scenario that needs emphasis in a Win2K migration discussion is the Win2K and NT 4.0 mixed environment. Unlike mixed mode, which is a Win2K domain with Win2K and NT 4.0 domain controllers, a mixed environment covers a broader range of configurations. A mixed environment is any combination of Win2K and NT 4.0 servers and clients on an NT network. Thus, you'll be operating in a mixed environment from the time you begin upgrading your domain controllers until your last client upgrades from NT Workstation 4.0 or Win98. A mixed environment is difficult to support because a troubleshooting scenario can involve several distinct interactions, such as Win2K domain controllers and NT 4.0 domain controllers (mixed mode); Win2K domain controllers and downlevel clients (i.e., NT 4.0, NT 3.51, or Win9x) or downlevel member servers (i.e., NT 4.0 or NT 3.51); Win2K member servers and downlevel clients; Win2K domain controllers and NT Workstation 4.0 or Win9x clients with the Directory Service Client (dsclient.exe) installed; or Win2K Pro clients and NT 4.0 domain controllers. Fourteen combinations of these five areas are possible instead of the usual two or three. You need experience with all these types of networking to troubleshoot problems.
10. Big bucks
Migrating to Win2K is a big, expensive project. Your migration strategy needs to encompass your entire company and will therefore involve many important areas (e.g., server hardware, training, funding for the project personnel from architects to operators, travel, customer communications). To have a fully functional Win2K network, you must upgrade your client hardware from its NT Workstation 4.0 hardware requirements. (Although by the time your company deploys Win2K Pro, the regular PC hardware upgrade process might have addressed Win2K's hardware requirements.) All these changes require money. And, don't forget that you must pay for new software licenses.
When Should You Jump?
Customers who migrate OSs fall into four categories: bleeding edge, early, mainstream, and conservative. (The time frames I give in each category assume that a customer begins Win2K product research and planning at least 6 to 8 months before deploying a new OS.) When you should deploy Win2K depends on what type of customer you consider yourself.
Bleeding-edge adopters typically migrate within 2 months after an OS's general availability date or when SP1 becomes available. Regarding Win2K, these customers might belong to the Win2K Joint Development Program or they might be small to midsized companies that require the technology for a competitive advantage. Deploying Win2K on a small network is less risky than deploying the OS on a large network. However, don't assume anything about the product's capabilities in your production environment other than the capabilities you've tested.
Early adopters migrate within 2 to 6 months after an OS's general availability date or when SP1 or SP2 releases. Although early Win2K adopters want Win2K's competitive advantages, they're unwilling to install the product straight out of the starting gate. These customers might need some of Win2K's new features to correct existing NT 4.0 infrastructure problems.
Mainstream adopters typically migrate within 6 to 18 months after an OS's general availability date or when SP2, SP3, or SP4 releases. These customers evaluate an OS before deployment, watching the released product's reliability from the sidelines. They know exactly what they want the OS to accomplish on their network. Their current infrastructure works well enough to let these customers wait until many of the bugs shake out. Because NT 4.0's first stable maintenance level was SP3, waiting until at least the first service pack releases before you deploy a new OS is wise.
Conservative adopters wait to migrate until an OS has been generally available for 2 or more years or until SP4 or later releases. These customers currently have reliable infrastructures and reasonably high availability that they can't afford to jeopardize. Their migration motivation includes the development of migration knowledge from companies that have already deployed the product, Win2K's eventual stability, the OS's features, and Microsoft's imminent cessation of NT 4.0 support.
Migrating to Win2K is a big project, so regardless of when you want to deploy the OS, you need to start planning now. Almost everything you currently know about Win2K is wrong, because Microsoft has completely changed or significantly upgraded everything in the OS since NT 4.0. Win2K's administrative model might be different from anything you've seen before. For a smooth deployment that doesn't affect your users, you must do a lot of up-front work on your organization and processes. You can't go very deep into domain design before you hit DNS, and Win2K will have a major effect on your enterprise's DNS architecture. Your DNS team must learn about the OS to understand all its ramifications. Win2K will also impose large hardware requirements that you must forecast for on your servers and clients. In addition, you'll need to decide on and design a host of new features. Finally, Win2K migration gives you the chance to end some of the political battles in your organization. You can use delegated administration to satisfy everyone—think of the process as streamlining the eighth OSI layer (i.e., politics) while you streamline layers five through seven.
Stephen Covey, a well-known management consultant, says the most productive type of work you can accomplish is work that is important but not urgent. Win2K work falls into this category. However, because migrating to Win2K involves so much work, the tasks become more urgent by the day.
Register
I work for the Federal Aviation Administration (FAA) as a contract PC support technician, and I'm writing this letter on my 133MHz laptop that has 32MB of RAM. Although my laptop isn't the most up-to-date model, it meets my needs (I have a more powerful desktop system for other tasks). I still run Win95 on the laptop because I've run Win98 on 133MHz to 166MHz machines at work and they're really slow. Microsoft tells you that Win98 will work fine on these slower machines, but it doesn't. Usually, I install Win98 on a machine only if the machine has at least 64MB of RAM and a 200MHz processor.
How much hard disk space will I need for Win2K? What do you suggest as a realistic minimum hardware configuration for the OS? I don't want to tell people not to go to Win2K, but I'd like to have some idea about whether the hardware I might be asked to put the new OS on will actually support it and not diminish performance.
Glenn S. Bloom May 16, 2000