Let’s continue about server data migration and now is the time to choose the best solution.

We will take 3 tools:

Robocopy

Secure Copy

XCopy

Using this comparison it’s very easy to define the best one. It’s definitely Secure Copy

I can higly recommend this solution for everyone.
We migrated over a terrabyte of server data to a new hardware. All shares, shares permissions, file attributes, compression settings, local users and groups were successfully migarted without any issue. The process went pretty fast and smooth so it was very huge time saver.

The process of moving to a new file server can be disruptive and painful. For example, data may get lost in transition from the old server to the new one. The new server may block some user access. Too many errors in the migration process and business projects can be delayed.

But this can all be avoided by carefully planning, executing and troubleshooting the move.

1. Planning

The next step is to familiarize yourself with the servers. You should know the data on the old server, as well as the share names (names of the shared resources), the folder names, and who has access rights. Learn all about the new server, too, concentrating on the RAID, hardware, and any differences between the two servers.

Next, list the roles and functionalities on the old server. Examples include DHCP, DNS, WINS, File/Print Server, and FSMO roles. Also note the location of the essential data on the old server. Allocate space for it on the new server. Compile network IP information and set aside an IP address for the new server. List the applications you will need to migrate. Confirm that the current version of the applications will run on the new OS or get the latest versions.

After that, you need to do backups. It’s better to do a full server backup. Also, set aside downtime for the migration. Users can’t be logged in during the process. Before execution, disconnect the servers from the Internet to prevent remote access. This will ensure that no one gains access during the server move.

Finally, make a recovery plan in case the migration doesn’t complete on time.

2. Executing

Set up RAID and mount the volumes on the new server and prepare the old and new servers to “talk” to each other. Plan IP addressing and naming conventions so the old and new servers don’t use the same name. Execute domain preparation—if the old server is Windows 2000, for example, IT will need to bring it up to a Windows Server 2003 schema, so that the new server can be added to the domain.

If the new server is the first domain controller, all other computers will have to join that domain. If there is an existing domain controller, make the new server a secondary domain controller. Once IT confirms that both servers are hosting Active Directory, they can promote the new server to primary domain controller and demote the old server to secondary domain controller. Then, the other computers won’t have to rejoin the domain.

Any new functionalities need to be assigned to the new server during execution. Assign the roles, then install them on the new server. Some roles must be migrated before others.

Once you have copied the data to the new server, unshare the old shares. Map users to the new server and create the new shares on the new server but keep the old server intact for a week or two in case there are issues.

3. Troubleshooting Common Issues

One common issue has to do with group permissions on the new server. The process of adding people to the right group isn’t always successful. As a result, people can’t get to resources they need. When this happens IT should check for existence of the new shares, see that these were set up properly, and check whether anyone was missed.

While IT can fix missing shares in a group, missing too many shares across groups can be a big problem, impairing work across the business all at once.

A couple of issues that people can miss revolve around getting Mac computers to use the new server. People commonly name their domains “companyname.local”. If they put a Mac computer on the domain, it takes over the domain because of that naming convention. Mac can’t take control of Active Directory, but it corrupts it. IT has to give the domain a different name.

IT may also overlook this Mac issue: getting Macs to map to the new server. Mac users need to map their own drives to the new server individually. By sending notices early on about the old and new server locations, IT can help ensure those users make the change.

By stepping back and carefully planning the move, planning a careful execution, and knowing how you will respond to issues, you can turn apprehensions over file server migration into extreme confidence

Some tools that may be helpful:

Robocopy

Secure Copy

XCopy

On my next article I will try to point out all of the pros and cons of them and will choose the best solution