Identifying Migration Risks

Article
10/08/2009

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

The next step is to assess the risks associated with data migration. The best way to identify these risks is to set up a test lab with clients and servers, similar to those in your production environment, and conduct trial migrations. In addition to testing your actual migration method, test any applications that are installed on client computers to determine if the applications are affected by the migration. For example, applications that depend on components stored on a particular file server might not work correctly if the file server or share is renamed after the migration is complete. If you identify problems, update your migration plan so that you prevent or mitigate those problems.

There are a number of solutions you can implement either before or during the migration to prevent problems from occurring. For example, you can ensure that shortcuts and links on client computers work correctly after the migration by doing one of the following:

Implementing DFS. If you have implemented DFS before the migration, the migration is transparent to users; you just need to update the link target location.
Migrating to clustered file servers. In this case, the migration is transparent if you create virtual servers that use the same name as the previously used file servers. You can also transparently migrate any stand-alone DFS namespaces to clustered file servers. Using the previous server names, create your virtual servers, and then migrate the namespaces by using Dfsutil.exe.
Using a third-party migration tool. Use a tool that can identify and fix broken links, such as OLE links or application-related links in the registry.

No migration plan is complete until you develop and test "back-out" procedures to follow if the migration fails at any stage in the process. Verify that you can restore data to its previous state and location in the event that you need to roll back the migration.

The following sections describe additional risks to consider during the migration.

NTFS permissions

When evaluating migration methods, determine whether the methods support migrating NTFS permissions. If you use domain local groups to assign permissions to files and folders, members of those groups will have the same access to the files and folders after they are moved to the new server. However, if you assign permissions to computer local groups, members of those groups cannot access the files after the migration. Either reconfigure permissions to use domain local groups before the migration, or plan to create new computer local groups on the target server and give those groups the appropriate permissions to the files after the migration is complete.

NTFS compression

If you use compression on the source servers, determine if you still require compression on the target server. Hardware on the target server is typically more powerful, with greater storage capacity. Therefore, compression might not be necessary, although you do need to account for the additional space required by the uncompressed data. Also, when you copy compressed files from one server to another, the compression attribute is lost unless you enable compression on the target volume.

Files encrypted by using EFS

Migrating encrypted files has a number of risks. Only administrators who are EFS recovery agents can copy or move files that are encrypted by other users. When these administrators copy or move encrypted files to a remote shared folder, the files are decrypted locally, transmitted in plaintext, and then re-encrypted on the target server only if the remote computer is trusted for delegation and the target volume uses NTFS. When the files are encrypted again on the target server, they have new file encryption keys that are encrypted by using the administrator’s public key, if it is available, or by using a new public key, which EFS generates if the profile is unavailable. As a result, the users who originally encrypt the files are no longer able to access them. Therefore, do not copy or move encrypted files from one server to another; use a backup and restore method instead.

Important

When EFS recovery agents copy encrypted files to a target server that is not trusted for delegation, or to a target volume that uses FAT, the files become plaintext on the target server.

For more information about EFS recovery agents, see "Designing a Public Key Infrastructure" in Designing and Deploying Directory and Security Services of this kit.

Choosing a Migration Method

Because many migration methods require downtime to move data, migrating data can be challenging in the following situations:

The data has high uptime requirements as specified by SLAs in your organization, and the migration method might require more downtime than the SLA allows.
Users expect to be able to access that data throughout their workday or at all times.

When planning your migration, consider the advantages and disadvantages of each migration method that is available to you, such as those described in the following sections. Your organization might use other methods not described here.

Backup and restore data

This method involves making a backup of the source server and restoring the data on a target server. Depending on your backup method and hardware, this method might involve moving tapes from one backup device to another (for direct-attached backup hardware) or restoring data from a tape library.

Advantages:

Large organizations routinely back up and restore data, so you can use existing backups to begin the migration.
Backing up and restoring data does not impact network bandwidth when it is performed on the local servers.
You can use this method to migrate encrypted files.
Disadvantages:
Both the source server and the target server must support the backup device and its related software.
If users are accessing files during the backup, you must make arrangements to migrate files that change while the backup occurs.
Backup programs do not migrate shared folder information to the destination server. As a result, folders that are shared on the source server are not shared when you restore them on the destination server. You must share the destination folders manually or by using scripts, and then use Permcopy.exe, which is available on the Windows Server 2003 Deployment Kit companion CD, to migrate any share permissions. For more information about Permcopy.exe, click Tools in Help and Support Center for Windows Server 2003, and then click "Windows Resource Kit Tools Help"

Use third-party migration tools, hardware, or services provided by hardware vendors

A number of third-party migration tools can automate the entire migration process. These migration tools typically offer features such as bandwidth throttling, scheduling, incremental file migration, and monitoring. Many hardware vendors also provide hardware solutions and services that can assist you in migrating data.

Copy the data

This method involves using Robocopy.exe to copy data from one server to another and then using Permcopy.exe to migrate share permissions. Use the /SEC parameter in Robocopy.exe to copy NTFS permissions from the source folder to the destination folder. After you finish moving the data, share the folders on the target server (either manually or by using scripts), and then use Permcopy.exe to copy share permissions from the source server to the target server.

Permcopy.exe and Robocopy.exe are available on the Windows Server 2003 Deployment Kit companion CD. For more information about Permcopy.exe and Robocopy.exe, click Tools in Help and Support Center for Windows Server 2003, and then click "Windows Resource Kit Tools Help."