How to migrate to Windows 2000

In a standard project plan for upgrading from Windows 2000 from NT, 80% of your time will be spent in design, testing and planning, whereas implementation time will be relatively short, says Tech Tonics consultant Chris Morrison.

In a standard project plan for upgrading from Windows 2000 from NT, 80% of your time will be spent in design, testing and planning, whereas implementation time will be relatively short, says Tech Tonics consultant Chris Morrison.

Speaking at a seminar last week on rolling out Windows 2000 on the server or desktop, Morrison claimed several reasons for migration:

  • Many new applications are coming out that don’t run on Windows NT 4.0 and Microsoft’s support for Windows NT 4.0 ends next June
  • Users might be paying high support costs because their environment isn’t stable and they require functionality and stability
  • They can standardise and simplify their environment
  • Windows 2000 is easier to support.
Morrison outlines a project plan starting with the discovery phase — collecting information about the environment such as hardware, software, network infrastructure and email configuration. “This is absolutely critical but people often skip over this phase because they think they know their environment.”

Morrison’s hot tip is to compile a list of applications. “Usually the applications list just keeps growing, sometimes at the rate of two or three new ones per week.”

In the planning phase companies need to define their business requirements,” says Morrison. “This not only helps with how the project proceeds but whether it is a success at the end.”

Set up the project and then develop a high-level project plan and a resource plan, he says. “People have time off and holidays and you need to be able to ensure you allocate after-hours time also.”

When it comes to the question of whether to do servers or desktops first, Morrison says it depends on the functionality you want and the business justification and Tech Tonics has done both.

Enterprises with regular hardware refresh cycles, those that intend to improve desktop management and those that consider “soft benefits” such as increased staff productivity will have a much faster return on investment for migration.

The design phase includes developing adesign document, completing detailed project and implementation plans, and resource allocation.

“You may require [Microsoft’s] Active Directory to roll out the desktop,” says Morrison. “Make sure you justify that on your business drivers and it needs to be property designed before implementation. Keep it simple. No one in New Zealand should need more than one [directory] forest and avoid numerous domains if possible.”

When it comes to Active Directory migration most people do an “in-place” migration as opposed to parallel, says Morrison. “In-place means you can keep the structure and there is less to move although it has a higher perceived risk and longer time is spent in mixed mode.

“With parallel systems it’s a clean start, it’s in native mode and you have domain consolidation from the start. But everything must be moved, there is resource sharing, you might have to buy new hardware and you have two domains to administer. Migration time is quite high too, ranging from several weeks to months depending on the server count and number of domains.”

For desktop migration tools Tech Tonics recommends formatting and re-imaging over in-place upgrades. “We don’t recommend in-place because anything that’s wrong will come across to the new infrastructure.”

The build phase, where the solution is build and design is confirmed, includes a server hardware and software audit, a network infrastructure audit and email configuration. The test phase is where the solution is tested and signed off.

“Don’t just fire up the application to see if it’s there, make sure end user functionality is still there also,” says Morrison. “Often in New Zealand there isn’t enough application testing time.”

The final phase is implementation, in which the environment is rolled out to end users and users are trained.

Morrison’s top 10 pitfalls

  • No business unit buy-in
  • Having a single project for servers and desktops
  • Underestimating the complexity leading to a shortfall in time and money
  • “Project stuffing” without additional time or budget
  • Continuous migrations with no break
  • Not measuring progress and success
  • No strategic business migration plan
  • Not enough application testing time
  • A “hopeless” quest for homogeneity
  • Political issues delaying a project or leading to bad decisions.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about Microsoft

Show Comments