In this 22 Minute video we walk through the process of upgrading a machine from Windows XP to Windows 7. There is no direct upgrade path from XP to Windows 7 so we are using the User State Migration Tool to migrate user data and settings. Note that this USMT example does not migrate OS or Applications. You will have to install the operating system and the applications on the destination computer. Some applications do not have to be installed on the destination computer. For details on what applications are covered in the MigApp.xml file check out the USMT Application blog post: Upgrading Windows XP to Windows 7 and Migrate Microsoft Office and Other Applications Using The User State Migration Tool (USMT)
You can find the downloadable files at the following URLs on Edge:
Right-Click, Save As below links…
Lite-Touch, High-Volume Deployment. This strategy requires limited interaction during deployment. Interaction occurs at the beginning of installation, but the remainder of the process can be automated. Microsoft recommends this strategy to organizations with a dedicated IT staff that have managed networks with 200–500 client computers. Prior deployment experience is not required but is beneficial for using this strategy. Personally, I would use this method for almost all size organizations. Maybe not to upgrade Gramma’s computer but certainly would for even small companies.
This step-by-step guide to Windows migration for IT pros provides a basic example of how to migrate files and settings from Windows XP to Windows 7 using USMT 4.0. (You can also migrate files and settings from a computer running Windows Vista®.) At the end of this process, you will have used the ScanState and LoadState tools to complete an end-to-end migration.
You can also customize your migration by editing configuration files used by these tools. For a comprehensive description of all of the tools and configuration files, see the User State Migration Tool (USMT) 4.0 User's Guide (Usmt.chm) downloaded with the Windows Automated Installation Kit (Windows AIK) or this Microsoft Web site.
In this example, you gather data from a source computer running Windows XP, create a migration store using the default settings in ScanState, install Windows 7 on a new or newly repartitioned computer, and then apply data from the migration store.
This process includes:
Step 1: Gather data using the Scan State toolStep 2: Install Windows 7Step 3: Apply data using the LoadState tool
Step By Step Detail…
Step 1: Gather data using the Scan State tool – From your XP or Windows Vista (SOURCE) computer…
cd \<USMTpath> <ENTER>
scanstate <USMTStorePath> /o /c /i:miguser.xml /i:migdocs.xml
Step 2: Install Windows 7
You can use an unattended answer file to customize your Windows 7 deployment. For more information, see Step-by-Step: Basic Windows Deployment for IT Professionals or the Windows Automated Installation Kit for Windows 7 RC
It is a pretty easy process even if you want to do it manually…
1. Insert Windows 7 DVD
2. Restart WindowsXP-to-7
3. BOOT TO DVD - WAIT
4. SHOW ENGLISH, click NEXT
5. Click Install Now.
6. Check Accept License Agreement
7. Click Custom (advanced).
8. Select DISK 0 Partition 1
9. Select Drive Options button
10. FORMAT, OK
Step 3: Apply data using the LoadState tool
Net Use G: <USMTpath>
loadstate <StorePath> /c /lac /lae /i:miguser.xml /i:migdocs.xml
If you want additional information on what applications can be migrated check out this blog post…
Upgrading Windows XP to Windows 7 and Migrate Microsoft Office and Other Applications Using The User State Migration Tool (USMT)
User State Migration Tool 4.0Windows Automated Installation Kit for Windows 7 RCStep-by-Step: Windows 7 Upgrade and Migration
Applies To: Windows 7, Windows Vista
This topic describes new features as well as changes in command-line options in Microsoft® Windows® User State Migration Tool (USMT) 4.0.
USMT 4.0 contains new ScanState command-line options. In addition, some command-line options have changed.
The following table lists new command-line options for the ScanState command.
/listfiles: "path to a file"
Generates a text file listing all the files included in the migration.
/p: "path to a file"
When an optional file location is specified, the /p option indicates that the new space-estimate algorithms are used. If you do not specify the optional file location, the /p option's functionality is the same as in USMT 3.0. These include an estimation of the disk space that is needed to create and build the migration store, as well as the space needed to host the migration-store contents. These estimates are provided in an .xml file at the location specified on the command line.
If the /nocompress option is also specified, the estimate will be for an uncompressed migration store. If the /nocompress option is not specified, the estimate will be for a compressed migration store.
Enables the creation of a hard-link migration store at the specified location. The /nocompress option must be specified with the /hardlink option. Additionally, the <HardLinkStoreControl> element can be used in the Config.xml file to change how the ScanState command creates hard-links to files that are locked by another application.
This option enables the volume shadow copy service to migrate files that are locked or in use by another application.
This option can be used only with the ScanState executable file and cannot be combined with the /hardlink option.
/auto: "path to script files"
This option enables you to specify the location of the default .xml files and then launch your migration. If no path is specified, USMT will reference the directory where the USMT binaries are located. The /auto option includes the following options /i:MigDocs.xml /i:MigApp.xml /v:13.
/offline: "path to an offline.xml file"
This option is used to define a path to an offline .xml file that specifies offline migration options; for example, an offline Windows directory to capture user state from, as well as remapping on drive letters and mount points.
/genmigxml: "path to a file"
This option specifies that the ScanState command should use the document finder to create and export an .xml file that defines how to migrate all of the files found on the computer on which the ScanState command is running. The document finder, or MigXmlHelper.GenerateDocPatterns helper function, can be used to automatically find user documents on a computer without authoring extensive custom migration .xml files.
/offlinewindir: "path to a windows directory"
This option specifies the offline Windows directory that the ScanState command gathers user state from. The offline directory can be Windows.old when you run the ScanState command in Windows or a Windows directory when you run the ScanState command in Windows PE. This option is incompatible with the /offline option.
/offlinewinold <Windows.old directory>
This command-line option enables the offline migration mode and starts the migration from the location specified. It is only intended to be used in Windows.old migration scenarios, where the migration is occurring from a Windows.old directory.
Creates a hard-link to the EFS file instead of copying it. Use only with the /hardlink and /nocompress options.
The following ScanState command-line options have changed in USMT 4.0.
Option in USMT 3.0Explanation for change in USMT 4.0
The /p option estimates the space needed to contain the compressed or uncompressed migration store. When an optional file location is specified, the /p:"path to a file" command-line option uses the new space-estimation algorithms.
/encrypt: "encryption strength"
You can specify a parameter to define the desired encryption strength for the migration store.
The /genconfig option now generates sample <ErrorControl> and <ProfileControl> sections in the Config.xml file that enable the new error control and local group migration behavior.
The /o option is now is required to overwrite both the migration store and the Config.xml file.
USMT 4.0 contains new LoadState command-line options. In addition, some command-line options have changed.
The following table lists new LoadState command-line options.
Enables user state data to be restored from a hard-link migration store. The /nocompress option must be specified with the /hardlink option.
This option enables you to specify the location of the default .xml files and then launch your migration. If no path is specified, USMT will reference the directory where the USMT binaries are located. The /auto option include the following options /i:MigDocs.xml /i:MigApp.xml /v:13.
The following LoadState command-line options have changed in USMT 4.0.
/decrypt: "encryption strength"
The /decrypt option now accepts a command-line parameter to define the encryption strength specified for the migration store encryption.
The /targetxp command-line option is no longer valid in USMT 4.0 because Windows XP is not supported on a destination computer.
The MigSys.xml file is no longer valid. This file was used only in Windows XP migrations where Windows XP was the operating system on the destination computer.
The /q option is no longer supported, because both the ScanState and LoadState commands require administrator privileges to run.
The following table lists all new Usmtutils.exe command-line options in USMT 4.0.
New option in USMT 4.0Description
This option returns a list of supported cryptographic algorithms (AlgIDs) on the current system.
Removes the directory path specified by the <storeDir> argument on all of the fixed drives. This command is useful for deleting hard-link stores that cannot otherwise be deleted due to a sharing lock. For example: usmtutils /rd D:\MyHardLinkStore
usmtutils /rd D:\MyHardLinkStore
Did you mean to do migapp and migdocs? I was expecting only user state information, but it looks like I got everything (165GB MIG file). Whereas when I run with miguser and migapp using the XP USMT, I get a MIG that is consistently the size of the user state data.
You are correct. If you want to get the docs use migdocs.xml. Users use miguser.xml Thanks for the note. I fixed the post.
I did what it said and I get an error message saying ' scanstate ' is not recognized as an internal or external command , operable program or batch file. It worked before . Now I wanted to update my docs and the command wont work. My storage is my network drive.
Im coming from Vista x86 to Windows 7 x64.
Hi Mike, you have to install the USMT utilities which are part of the Automated Installation Kit (AIK). It it is installed, just change to the directory where you have it installed.
Nice and simple to understand the basic working of USMT.
I have a scenario where i need to migrate winxp to win7. Knowning that USMT 4.0 supports running from winpe, here's what i would like to achieve:
Boot the pc (running XP) with winpe, run scanstate (store state on network server).
Next apply the win7 image, then call loadstate. And finally once we reboot.
Basically i would like to see the usage of USMT (scan/load) from WINPE.
Thanks again for the wonderful work.
I have not tried running Scanstate from WinPE.
I would think that this would give you a less than desirable outcome.
I think it would not see the users as the WinPE does not have users.
I could see grabbing the folders, but then not sure if would be able to put them back down in the right place on the loadstate.
I will look into it when I get a chance.
I plan to migrate from WIndows XP to WIndows 7 via the "PC refresh using Windows.old and the hard-link migration store" as discussed in the USMT 4.0 user's guide. Is it possible to do with via an automated deployment of Win 7 using the MDT 2010 toolkit?
Congrats on a great blog Dan - this was great as usual. However - having a problem with load state. Keeps giving me an error 27 that the store path or permissions is wrong. I finally put the usmt.mig on the local drive on the new win7 install - c:\store - took ownership, opened up permissions wide open. Same error.
loadstate c:\store /c /lac /lae /i:miguser.xml /i:migdocs.xml
1. when running usmt commands in win7 (and vista) you have to open an Admin cmd console or you get event 71.
2. your instructions on Scanstate would have been better if you'd made a quick note about migapps.xml as another option.
I'm a Microsoft partner specializing in deployments where relatively small organizations (less than 50 clients, usually in non-active directory environments-- although many of my clients have some version of Windows server installed on their network). I am watching the video associated with this post, and I just want to say that I agree with you 1000% in the utility of MDT 2010 in small environments. As you say anything from five clients and up is appropriate. I just wish that Microsoft provided more appropriate documentation for scenarios in the 5 to 25 client range. When I worked for Microsoft a few years back, they were always moaning about the need to do a better job in the small to medium-sized enterprise space. In my opinion products such as SBS are too complicated/restrictive -- particularly in the smaller end of the space. At any rate I'm not going to rant here, I'm just glad you acknowledge the utility of MDT 2010 at the small end of the spectrum.
I'm a Microsoft partner specializing in deployments where relatively small organizations (less than 50 clients, usually in non-active directory environments-- although many of my clients have some version of Windows server installed on their network). I am watching the video associated with this post, and I just want to say that I agree with you 1000% in the utility of MDT 2010 in small environments. As you say anything from five clients and up is appropriate. I just wish that Microsoft provided more appropriate documentation for scenarios in the 5 to 25 client range. When I worked for Microsoft a few years back, they were always moaning about the need to do a better job in the small to medium-sized enterprise space. In my opinion products such as SBS are too complicated/restrictive -- particularly in the smaller end of the space. At any rate I'm not going to rant here, I'm just glad you acknowledge the utility of MDT 2010 at the small end of the spectrum. Found the video valuable.
hey i have a situation where in my network users use roaming profiles and i want to migrate these roaming profiles to windows 7 systems. would i be able to use the migrated roaming profiles in windows 7? also will these migrated profiles be able to sync normal with the server.
Note that windows 7 use a ".V2" files extension for roaming profiles and windows XP doesn't.
Sorry, not sure how roaming profiles are handled. Will have to dig into that when I get a chance. If anyone else, has the answer, please post a comment.
It's awesome, but one thing i would like to ask u is that do i need to create a new partition for the installation or i just do clean install?
can u plx reply for me. I want to do this with my vista machine.(only one machine)
No, you do not need to create a new partition. However, if it is important data, you should do a backup (just in case) The only time I have seen USMT fail is when options were not done correctly or things were not turned on that need to be turned on. However, this information was not helpful to the people that lost data.
Mr.Dan, I solve problem. which is the administrator account was disable by default. i did not know it. so i just enable it and now run the scanstate command and it's working. This is actually way faster than using the win easy transfer. One again thanks for your help. if i have the further problem i will bother u agian :D.
Have a great day, Pro. ;)
Nothing much, i just wondering that is there another way which is similar to this method and that is faster than this one? ;) Can u sneak for me ;;)
If you run the USMT with the HardLink migration it is much faster (assuming you have a fair amount of data) however, please make a backup before, just to be safe.
Sorry Mr. Dan,
Now i can run the windows 7 cd, but i got error says:
Windows Setup could not reinitialize the deployment engine. To install Windows, restart the installation.
i did, but still get the same error?
Do u know why?
I got problem when running loadstate command. it said invalid store path.
It's weird. before my store location was G: drive now it's change to E:\ drive, i specify store path using E:\USMT\Save but still can't make it's work.
While install the windows 7 i did delete few partitions. My computer now look like i just did fresh install.....Can i still retrieve or reload my file and setting or.....:(( hu hu. Can u show me the ways? please.....
Finally, everything is working, i could not use the loadstate command to complete so i user easy transfer to do. Now ti's working perfect. Anyhow, thanks for your help.
I was wondering if we can do the same to activated accounts already on a system whos os has failed, and needed to be reinstalled
--- if you are referring to he activation key, YES you can use a key that has been used before. You may have to call in for activation