Deployment Blocker No. 4: Promise to capture all data everywhere
Like the promise to bring all applications over to the new environment, this is a promise that cannot be kept, especially if the users have been running unmanaged, which means they are storing their data—um, where? And does anybody really know which data is important to keep in these unmanaged or even the managed environments? Not bloody likely.
There is no data transfer tool in the world that can read people’s minds. And if there was, you probably wouldn’t really want to know what was in there.
Accordingly, there are two methods that data transfer tools use:
Location specific: Instruct the data transfer tool to go to a specific location, and back up all files there. For instance, Microsoft’s User State Migration Tool by default will automatically capture all profiles under c:\Users, or C:\Documents and Settings, and (not surprisingly) is excellent at capturing all the preferences of Microsoft products, including Microsoft Office.
Vacuum cleaner: based on a list of file extensions you give the data transfer tool, it hunts through the entire disk, or disks, to find those file extensions no matter where they exist, gather them up, and dump them into a new target directory.
The problem with the location specific approach is that in unmanaged environments, where each individual user has the ability to save anywhere they want, you don’t really know which locations to direct the data transfer towards.
The Vacuum Cleaner approach is effective, but you have to know what file extensions you have to capture—and if you don’t really know much about the applications users are running, you aren’t going to be able to guess what those file extensions are (see mind reader comment above). The vacuum cleaner approach can also produce an exceedingly messy result on the other end. The target directory on the
new system can be organized with the same file folder structure the original file was discovered in upon the old system, and this is helpful, but it is still rather confusing to many users.
Worst of all, regardless of which method (or both) is used, application preferences may get lost if you don’t capture them too. It is not always blazingly obvious where those files or registry entries are, it can take quite a bit of research to track them down.
Then there are certain customers that do have legal or contractual requirements to maintain data for extended periods of time. But even in those situations, I have occasionally discovered that the regulations are a lot less onerous than the lawyers’ interpretation. People who are unfamiliar with the tools think it makes sense to gather up everything “just in case”, not realizing the huge hit to time and storage this will cause.
The point is please don’t promise the moon here, because users will inevitably be disappointed somewhere along the line. Until you get to a managed environment, you cannot in conscience guarantee capture of all the data.
A Better Way: Set expectations with the users up front, and push as much of the data backup and cleanup responsibility toward them. Only they know where their important data is, so work with them to help them put where the data transfer tool will capture it. Also, after identifying all applications that will be moving to the new environment, research where those applications store personal preferences and what their data extensions are (e.g. *.trm). If an application is poorly written, and it has user’s preferences for the application configuration stored in the system or Program Files directories rather than the users’ own profile, you’ll have to dig that fact out application by application. Finally, use file copy technology for the image, so you can move data in place on the local partition as you wipe and load to the new system, rather
than being forced to move it over the network to a remote location. I’ll write more on this shortly in another blog; this is a huge time saver and limits the risks of massive data transfers.
This is part of a ten part series of blogs “Top Ten Deployment Blockers”