Windows Server 2008 has been out for a while and has proven to be a stable operating system. Now that Microsoft has released the first "real" service pack (SP2), more companies are looking at the possibility of upgrading to Windows Server 2008. Although the coexistence of Windows Server 2008 and Windows 2003 shouldn't pose a problem, the actual server migration process can be a bit tricky. In this article, I want to talk about some of the issues that you may encounter when migrating
The file server migration process can be deceptively simple. In fact, Microsoft offers a free utility to assist you with the migration process (I will be writing about that utility next month). Even so, there is usually a lot more to performing a migration than just running a migration utility.
One of the first things to consider is whether or not you will be reusing your existing file server hardware. Keep in mind that if you deploy new server hardware, then the migration process will likely be easier -- especially if you are using the Windows Distributed File System (DFS) on your current file servers. One of the primary advantages to using new hardware is that you can leave your existing server in its current state. That way, if something goes wrong during the migration process, you can still fall back on your old server.
If you choose to reuse your existing hardware, it's important to carefully plan the operating system upgrade. This is especially true if you are using DFS or a clustering solution.
How long will the migration take?
Another major consideration is the amount of time it takes to complete the file server migration process. For instance, suppose you are not using DFS, and you want to use new hardware to host the new file server. In that situation, you can install and configure Windows Server 2008 on the new server without disrupting the users. There is going to come a point, though, when you will have to move the data to the new server.
If DFS isn't being used, then there is going to be a period of time when the data will be unavailable to your users. You have to figure out how long that period of time is going to be and perform the migration so that it will have the least amount of negative impact.
If you are planning to use a backup and restore architecture to move the data, you will need to figure out how long the data will take to transfer. You might be able to quickly back up your old file server by using the Virtual Shadow Copy Service (VSS) to take a snapshot, but the restore process will probably take a long time to complete, and users won't have access to their data until you make the new server available to them.
In some cases, it may be possible to simply transplant a RAID array from your old file server into your new server. That would certainly speed up the migration process for you, but it may also minimize the benefits of using new hardware.
Evaluate the migration
You are going to need a way of evaluating the file server migration process once it completes. Specifically, you must verify that all of the data has been transferred to the new location and that nothing has become corrupted in the process. Your backup software should be able to do this if you are using the backup and restore method.
Additionally, you must verify that permissions have transferred as well. I recommend making note of the permissions of some key folders before you start the migration. That way, you can use your notes to spot check the permissions on the new server when the process completes.
The final step in the migration process is to redirect users to the new file server. This is usually just a matter of modifying a logon script to use a different drive mapping. Even so, the method that you will use for the redirection needs to be planned ahead of time. It shouldn't be an afterthought once the file server migration completes.
ABOUT THE AUTHOR
Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit his personal Web site at www.brienposey.com.
This was first published in April 2009