REVIEW: LapLink PCmover Pro, PCmover Enterprise Fill Microsoft's Windows 7 Migration Holes
Microsoft hasn't made it easy for consumers or corporate IT workers to move from Windows XP to Windows 7 without the potential for a significant loss of time and productivity.
While there are a few scenarios in which a Windows Vista PC can be upgraded to Windows 7 while retaining existing applications, data and settings, there are no similarly supported scenarios for moving from XP to Windows 7. Users or administrators must perform a clean installation of the new operating system, requiring applications to be reinstalled and desktops reconfigured.
Into the breach steps LapLink, maker of the PCmover line of personality transplant tools capable of moving applications and their configuration settings to a new operating system without requiring reinstallation or reconfiguration. PCmover also promises to move documents and settings from the old system to the new one, although Microsoft offers free tools that replicate some of this functionality.
To get a feel for LapLink's ability to move files, settings and applications from Windows XP to Windows 7, as well as for the enterprise policy controls needed for business usage, I tried both the consumer-oriented PCmover Professional ($70 with media) and the business-focused PCmover Enterprise ($27.50 per license for 500 user licenses).
To test PCmover Professional, I upgraded a well-used Windows XP Pro workstation running on a PC with an Athlon 64 X2 3800 and 4GB of RAM to 64-bit Windows 7 Ultimate.
Aside from a ton of games, most of which I did not intend to migrate, the XP installation housed myriad applications-Office 2007 Home and Student, Skype Pidgin, various Adobe tools, Nero 8, Firefox, VLC, TiVo Desktop, iTunes plus an assortment of Apple network configuration tools, TurboTax and some other random programs. (Yes, this was my family PC.)
Because it was an in-place upgrade, I couldn't take advantage of PCmover's direct personality transplant capabilities. Instead, I had to utilize LapLink's built-in Windows 7 Upgrade Assistant, which walked me through defining the files, applications, settings and user accounts that I wanted to move to the new PC. PCmover bundled up that list of data into a "Moving Van" that was saved on the local hard drive.
After building the Moving Van, I performed a clean install of Windows 7 over the XP partition without first formatting the drive, thereby saving the old operating system (and the Moving Van) to a folder called c:\Windows.old. By running the Upgrade Assistant on the new OS, I could then map old users to users on the new operating system or create new user accounts when necessary.
Applications are copied or moved (the user decides, depending on how much free space is available on the hard drive) from Windows.old to the appropriate location in the new file system. In this way, the Moving Van won't necessarily get too large even if a lot of applications are migrated.
PCmover did not offer a lot of smarts or advice about which applications were safe for migration. It is therefore important to run Microsoft Upgrade prior to running PCmover. Microsoft Upgrade will identify troublesome apps and leave them off the migration roster when using PCmover. During tests, I was able to identify prior to migration that my anti-virus, video card and printer software would be a problem in Windows 7 x64, so I didn't include those in the Moving Van.
Once everything is migrated, PCmover Pro presents an applet called StartUp This. Basically, PCmover by default stops any program that auto-started in XP from doing the same in Windows 7 until the user is able to test and approve the application. I could individually approve applications to auto-start using the applet. I did find it odd that StartUp This listed applications that were not migrated to the new PC, indicating that PCmover doesn't do a good job cleaning up some parts of the Registry (like the Run key).
The Windows file system has a tendency to get cluttered over time, and PCmover offers some ways to avoid moving the clutter to the new OS instance. For instance, using the Upgrade Assistant, I was able to avoid moving temp files and folders by creating exclusion rules for extensions and some folder locations, as well as for certain types of temp files (such as the ones Office produces).
The migration went fairly quickly. Despite all the applications and settings I migrated, building the Moving Van took only about 4 minutes, and unpacking to the new OS took only about 12 minutes (although it may have taken longer if I had chosen to copy applications rather than move them).
As for content, things went better than I expected, although not everything worked after migration. For each of my local users, the desktop looked as it did before, bookmarks made it over for both Internet Explorer and Firefox, and the passwords were the same as before the upgrade. However, My Document folder redirections were not migrated, so I had to manually reset those settings.
For applications, it was a mixed bag.
Problems often seemed due to licensing or activation schemes employed by various pieces of third-party software. I was worried that Microsoft Office 2007 Home and Student would want me to reactivate, but it worked fine after briefly popping up a dialog box. However, Nero 8 refused to work post-migration, requiring a complete clean reinstallation. Pidgin and Skype both worked post-migration, although Skype lost its saved account and password data. iTunes required a repair but not a reinstallation, while TiVo Desktop lost its media key and one of its underlying services (yet somehow worked). TurboTax 2008 couldn't find a necessary CAB file, so it failed to run (and I had lost the media).
PCmover Pro offers an undo function to remove the contents of the Moving Van from the new OS, in case something goes catastrophically wrong. When I tried the undo, I was presented with an explained error message, but the restore continued to work correctly otherwise.
Upon the next login, I received a few more errors during startup, but the errors were not fatal. Migrated applications were moved back into the c:\Windows.old folder, and settings were restored to default, leaving a fairly clean Windows 7 instance. Since the actual upgrade to Windows 7 is outside PCmover's purview, users would need to use a third-party disk cloning tool to go all the way back to Windows XP.
PCmover Enterprise, on the other hand, provides organizations with a way to centrally control much of the PC migration process via policy. From a central console, administrators can define and enforce migration policies that pinpoint what can and cannot be transferred to new PCs, as well as customize the amount of interaction that end users can have prior to the migration.
PCmover Enterprise comprises two elements: the PCmover Policy Manager and the PCmover Client. With the former, administrators define multiple policies that dictate (or exclude) the files, applications and settings targeted for migration; enumerate which PCs are targeted for both ends of the migration; and define which users can perform the migration. The PCmover Client, which can be stored on a network share or distributed via removable storage, is the engine that performs the actual migration. Analogous to PCmover Professional, PCmover Client culls the files, applications and settings from the old machine and then copies and installs that bolus of data to the new machine.
PCmover Policy Manager can be installed on a Windows server or workstation in the network; the PCmover client just needs to be kept in a share accessible to end users.
When installing PCmover Policy Manager, PCmover Enterprise automatically creates an editable Master Policy file that will be used for every migration action. Since this policy will apply globally to every migration, rules defined within it should have broad application-for example, mapping the share where reports will be saved or banning the transfer of certain music or video file extensions disallowed per company policy. A secondary Session Policy file is for rules that can be applied to specific migration actions.
Via policy, I found that I could dictate whether the migration would move only files, or add settings or applications, as well. I could map network shares, and I could dictate which existing local users and profiles got migrated to the new computer. I could create exclusion lists of directories or file extensions to bar from transfer, and I could granularly include or exclude applications from transfer.
Unfortunately, the only way to dictate migration policy for applications is to identify the application ID by hand or list the application name (which would not be effective if trying to exclude migration of certain versions of the same application).
I could also centrally dictate how a migration occurred-whether the transfer was done directly over the network or via a direct USB or LapLink cable connection between PCs, or whether the migration data got saved to removable storage or a share for later deployment.
I could also set policies that defined which users or machines were allowed to use the policy defined in the upgrade action-to limit who performed migrations and which machines could be migrated. Unfortunately, this capability isn't tied into Active Directory, so I couldn't leverage existing domain security groups or Organizational Units within the policy. (I had to type in login names instead.)
Via policy, I could also control the amount of interaction the users could have throughout the data collection process. Administrators have the option to granularly allow or deny users the right to override any of the default collection rules defined in a policy.
I was impressed by this wealth of options and controls over the migration process, but I found the Policy Manager a little hard to navigate. Once I'd created the Master Policy and a few targeted Service Policies, it was difficult to tell which policy I was working in at one time and easy to make changes to the wrong policy. Existing policies are displayed in a Recent Policy pane in the middle of the console, but the actual policy under edit is shown at the top in the title bar. Instead of double clicking a policy to edit, I had to highlight it and then click an indistinct Open Policy hyperlink down below.
With policies defined, I could define a migration pair using the New Migration wizard. I enumerated the source and target computers, and defined which Session Policy to use for the pair. I could also forgo the use of a Session Policy, and either automatically apply default answers or prompt the user for every bit of information. Given that every transfer pair needs to be explicitly defined by repeating this step, and that each pair creates its own policy item that shows up in the Recent Policy dialog, the tool may not scale well visually or logistically to very large networks.
The PCmover Client can be run by the end user by e-mailing them a link to the executable on a network share, or the client can be triggered via script or by third-party enterprise software deployment tools.
IT administrators should be wary of LapLink's licensing and activation processes when using PCmover Enterprise. Whenever the PCmover Client is run on an originating host, the executable will take the proffered licensing data and activate over the network by default. I found that if the data collection and transfer doesn't take place for whatever reason, the activation still counts against the license total. With the licensed activations consumed, PCmover Client presents a license error that stops the migration process completely.
In the future, I'd like to see LapLink add license management reporting tools to its enterprise console, especially as migration projects will stop dead in their tracks if licenses get consumed faster than anticipated.
Senior Analyst Andrew Garcia can be reached at agarcia@eweekcom.