At some point in your IT management career you'll almost certainly need to manage a migration from one operating system or product to another. This migration can involve a server operating system such as migrating from Novell NetWare to Windows Server 2003 or a line-of-business application like moving your corporate e-mail system from Lotus Notes to Microsoft Exchange. When confronted with the need to perform any type of large-scale migration, there are a number of key questions that you'll need to ask yourself to prepare for the migration.
Old vs. new
The first thing you need to figure out when you're planning a migration is whether your existing hardware meets the hardware and software requirements for the new operating system or application. All reputable vendors will publish some sort of minimum hardware specifications on their Web site or in their product documentation; if your existing hardware doesn't fit the bill, you'll need to plan on investing in replacement equipment.
One important factor to keep in mind, of course, is there are the "minimum" hardware requirements listed on many vendor Web sites, and then there's the kind of hardware that you'd actually want to run on a production server out in the real world. For example, according to Microsoft's Web site you can install Windows 2000 Server on a Pentium 133 on as little as 128MB of RAM. Now while I'm sure it's true that you might be able install a server operating system on such a low-powered machine, I'm equally certain that you won't be all that happy with the results.
Especially since RAM and hard drive space are continuously dropping in price, you should specify the best hardware that you can budget for the migration project. An obvious benefit of this is that your new server or application will perform much better after the initial upgrade or migration. But you'll also recoup the cost of new hardware over time, since you can perform many incremental hardware upgrades on your state-of-the-art system (e.g., installing new RAM or an additional processor), rather than buying a brand new machine all over again in a few short years. Using the Windows server OS as an example, I wouldn't recommend deploying Windows 2000 or Windows Server 2003 on a machine running much less than a 1GHz processor with at least 512MB of RAM.
In addition to specifying the most powerful hardware you can budget, you should also verify that all of the hardware components installed in your servers are compatible with your new system; this is especially critical if you are migrating from one network operating system (NOS) to another one. Microsoft lists all hardware that is certified to run on its server operating systems in the Windows Catalog (formerly called the Hardware Compatibility List, or HCL.) You can view the Windows Catalog for Windows 2000 here and the Windows Catalog for Windows Server 2003 here. A final area of concern when migrating to a new server operating system will be to ensure that your existing applications will make the transition well. Does the current version of your database and e-mail servers function on the new operating system? Or do you need to plan for an application upgrade to take place during or immediately after the migration?
When planning your migration, you also need to determine how you're going to make the switch from one system to the other. There are a few common ways to do this:
- Using the "hard cut-over," you'll pick a drop-dead date for the migration to take place, at which point you migrate all of your users, applications and information in one fell swoop and then take the original system offline.
This calls for quite a bit of user training and awareness beforehand, so that your staff will know well in advance that they'll be using one e-mail system on Friday and then a completely different one when they come into work on Monday morning, for instance. It also requires planning from the standpoint of the actual migration. Can your administrators physically move all of the necessary data overnight or in a weekend? Or will you need to plan a more gradual approach?
- Another method of migrating one system to another is "co-existence," a method whereby two systems run in parallel and you move users from one to the other one gradually -- by location or by department, for example. The advantage to this approach is that it is far less intrusive to your users as a group and, therefore, less stressful for your administrators. Rather than having the entire company calling the help desk at 8 a.m. because something went wrong with the hard cut-over migration over the weekend, you can iron out problems on a much smaller scale as they occur. The disadvantage to this is that you need to maintain two completely separate systems for the duration of the migration, which can introduce some administrative complexities to your environment.
Whichever method you choose, remember that even the smallest upgrade or migration requires a rollback plan, a way of getting back to "the old way of doing things" if something really horrible goes wrong during the migration. These plans are even necessary in the case of a lengthy co-existence migration, since unforeseen issues with the new system can introduce themselves weeks or even months down the line. Situations that require rollback plans often stem from application incompatibility between the old and the new systems or from something as unforeseen as a power outage in the middle of the upgrade process.
For example, if you're migrating from Windows NT 4.0 to Active Directory, there's actually a relatively simple way to roll back from a failed upgrade. By default, an NT 4.0 domain that's been upgraded to Active Directory will be running in the Windows 2000 mixed domain functional level. This means that any NT 4.0 Backup Domain Controllers (BDCs) will still be able to function on your network, since Active Directory will translate its database into a format that the NT 4.0 BDCs can understand; and therein lies your safety valve to recover from an upgrade gone wrong. As long as your Windows 2000 domain controller is online, you've got yourself an Active Directory domain running in Windows 2000 mixed mode. But as far as your NT 4.0 BDCs are concerned, they're still happily sitting on an NT 4.0 network because of this backward compatibility. If you take the 2000 DC offline, your NT 4.0 machines will still just think that they're members of an NT 4.0 domain. So in the case of an NT-to-Active Directory migration, you can keep an NT 4.0 BDC online until you're absolutely certain that you're happy with the 2000/2003 upgrade, and only take it offline when you're ready to make the switch to a higher-functionality level like Windows 2000 native mode.
Laura Hunter (CISSP, MCSE: Security, MCDBA, Microsoft MVP) is a senior IT specialist with the University of Pennsylvania. You can reach Laura at firstname.lastname@example.org. Be on the lookout for Laura's Active Directory Consultant's Field Guide for more technical advice on Active Directory migrations and other Windows administration tasks, arriving soon from APress.