Over at ZDNet, I’ve put together an article that explains the inner workings of the Windows Easy Transfer utility in Windows 7, summarizing its advantages and its weaknesses, and explaining how best to use it. The context, of course, is that when the Windows 7 Release Candidate comes out (sometime before the e4nd of May), you’ll be strongly encouraged to avoid upgrading from the beta and instead will be expected to do a clean install. Which is a perfect scenario for using the Windows Easy Transfer utility to capture the settings and files from your existing installation and restore them on the new, clean install.
The whole thing is here:
How hard will it be to move to the Windows 7 Release Candidate?
Over the years,I’ve been lukewarm at best on the various iterations of this utility, from the Files and Settings Transfer Wizard in XP to the first appearance of Windows Easy Transfer in Vista. But with Windows 7, Microsoft appears to have gotten this stuff mostly right. The big missing piece is that you can’t migrate programs themselves. I also wish that third-party developers (and even the community) could create templates for adding settings for additional programs.
Ed Bott (@ wordpress.com) 
As I recently had a drive die due to changing the partitions around, and I only could recover the data (copying the registry file to a new installation of windows) seems like a bad idea to me, so I now have a blank installation of windows with my data, and none of the programs, at least not “installed”, I wondered about whether there would be a way to change the registry functions to make this step easier.
I really like Debian’s forced model of all system wide configuration data goes in /etc/ and all user-specific data goes in your home directory, (note in particular that the user-specific stuff is not standardized at all, with some programs using a file, some using a directory (I think gnome and kde do a decent job of having a more standardized system, but I haven’t used them very much), and when I copied my pidgin configs the other day to a new computer, I couldn’t find it until I figured out that .purple contained the configs for pidgin – I assume there’s some historical reason for that…)
So, I got to thinking about .ini files in the “old days”. I wonder if there is a way to go back to more of that model, but have a stronger, enforced standard, where all system-wide .ini (maybe use XML, since that’s the current fad?) files are in a certain directory, and user-specific files live in your Application Data directory. And then use the same registry functions to write to those files, so applications wouldn’t have to change anything, but just the data would be written to a different place, silently, behind the scenes.
The advantage would be that stuff that used to be stored in the registry could be copied manually (or by files and transfer type wizards) on an application-by-application basis.
I’m sure there is lots of stuff that could (and should?) stay in the registry, but it seems to me that the ability to copy programs from one machine to the other with settings intact would be a great thing.
I guess this doesn’t solve the “program not installed, so it doesn’t show up in the control add/remove programs window” problem, but I think even if you had to re-install the program, but then could overwrite all of the config settings easily, it would still be better than where we are now.
My short-term solution to programs not being migratable is to use as many programs as I can that do not require formal installation to work. So far the only two real stalwarts are Word and Outlook.
@John,
In case of Windows, the user data indeed goes to the user directory, however, its not in a text-readable form. Its in the file called NTUSER.dat that contains all the user specific registery entries. The reason MS uses registry is not that its bloated, as proponents of other OS’s say, but because its fast to access data in that way. I don’t know the exact structure, but its like a mini-sql database. Consider what would happen if you start using text files instead of those enormous databases, just to make them more readable. Some might say it would give them power, and make it more user friendly, but this will come at the cost of efficiency.
However, I’ve come to believe that the best solution to such a problem will be having an MS Access database for every single application that resides in the directory related to that application. This would prevent things getting mixed up, and will make the registry much less unfriendly.
Right, but the .dat file isn’t useful to anyone is it?
Firefox also switched from text files to a sqlite database, and it is quite annoying. Though it at least has a tool I can use to get information out of it relatively easily, though I’d greatly prefer a text file.
As far as efficiency, I wonder how much data is stored per-application anyway? It seems wasteful for most (all?) applications to have a separate database for each application?
And since my current systems use text files for (user and system-wide configuration) can it really be that much less efficient for Windows to do it? I haven’t ever noticed a delay in reading in the tiny text files, and they usually have lots of comments in them, so the text parser has to be smart enough to read through the file and ignore the comments, so that would take even more time to do it.
I guess the question could be asked about how much memory is used up holding the configuration values, after the initial read. I’m the first guy to say that software shouldn’t keep using more and more RAM, but does holding the bytes of configuration data really take up all that much space?