USMT 4 Update Released to Support Office 2010 Migrations

Microsoft has created an update for USMT 4.0 that adds support for Office 2010. USMT 4.0 migrations of Office 2010 are now supported .

You can get the update here:

Here are some things you should be aware of:

  • Certain settings and customizations in MS Word won’t migrate from any version to Word 2010, because of with the way Word is designed and how data is stored in “HKEY_CURRENT_USER\software\Microsoft\Office\<OfficeVersion>\Word\Data".
  • Many Office settings (across all Office apps) won’t migrate when going from 32-bit Office to 64-bit Office. This is due to the way that the settings are stored in 64-bit Office installations.
  • If you’ve launched Office on the destination PC as a user before doing the migration of that user’s profile, most of your settings won’t migrate. This happens because Office relies on some code that only runs the first time that an Office app is launched to migrate settings.
  • This update isn’t a magic bullet. You may still need to do some customization to make USMT fit your particular configuration.

The update also fixes a couple of issues around hard-link migration performance when copying a folder with a huge number of files and an issue that affected certain time zones.

This post was contributed by David Hornbaker, a Senior Consultant with Microsoft Services - U.S. East Region.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use

Comments (9)

  1. Hi,

    The 4.0 migapp.xml does "work" when used with USMT 3.01 – and by that I mean it is schema compatible, will not cause a fatal error during 3.0 scanstate/loadstate, and will not corrupt the store in any way. However, under the covers it may be causing issues within the migration. That 4.0 XML and Office 2010 have not been tested in any fashion with USMT 3 (and never will be), so while it might appear to work fine on the surface, we have zero idea of any more insidous problems. Because it is untested, it is considered unsupported.

    Now, if you are using USMT 3.01 because you *have* to – such as migrating from Win2000 or to WinXP – I can offer you a supported workaround: migrate to a computer that has Office 2007 installed, then upgrade the office install to 2010 after the migration is done but before the users log on. 2010 will upgrade the office 2007 settings (as if there was no migration).  

    Ned Pyle


  2. doxley says:

    @JPMorgan – no, the files are not compatible between versions i'm afraid.

  3. doxley says:

    @JP Morgan – I understand your pain, it is something I've come across in the past.  A while back I asked the product team this question and they told me that it shouldn't work, and more importantly is an unsupported configuration and could cause a corrupt store.

    However, when I asked the question, the USMT 4.0 was still in beta.  Your best bet would be to head over to the USMT blog (…/usmt – although it looks like they haven't posted in a while) and ask this question, or get in contact with Microsoft support.  I really don't have access to the information that you need.


  4. doxley says:

    @JPMorgan – no, the files are not compatible between versions i'm afraid.

  5. Hi JP,

    From a schema/synatx standpoint the 4.0 migapp.xml will work – that is to say, it will run without fatal error using the 3.01 loadstate/scanstate. The store will not be corrupted. However, this XML has not been tested with USMT 3 (and never will be), so weird problems may be happening under the covers when you use it. No conspiracy here, we simply have no idea.

    Now, if you are using USMT 3 because you *have* to (i.e. you are migrating to XP computers or from Win2000 computers) then a way around this would be to have Office *2007* installed on the destination computer. You migrate the user state and that will work fine. Then, install Office 2010 and it will upgrade everything in the user profile when the user first logs on later. That would be fully supported and would work fine.

    If you are going to Vista or 7, you shouldn't be using 3.01, naturally. This is now all moot and you use USMT 4.0.

    I hope this helps,

    Ned Pyle


  6. James P Morgan says:

    I know that USMT3 is no longer supported, BUT, can the USMT 4 MIGAPP.XML be used as a replacement file for the USMT 3 MIGAPP.XML, AS IS, or IF SO, with 'some' modifications, to 'add' Office 2010 migration support?

    Thanks.. J P Morgan, – 770-793-1946

  7. James P Morgan says:

    Sirs , this is in reply to your response that the NEW USMT4 MIGAPP.XML is 'not compatible' with USMT 3 usage.

    I would assume that you would KNOW for SURE!!, However i was curious as to 'why not' and the IMPACT of

    using the USMT 4 MIGAPP.XML hot fix file (with Office 2010 support) and any 'loss' of data that would occur…

    My Findings:

    1) The 'default'  MIGUSER.XML file are 99.9% idenical between USMT 4 and USMT 3 (except for a few comment lines)

    SO, if MIGUSER.XML were 'identical'  i assumed (i know what happens when you do this) that i COULD replace the MIGAPP.XML  from USMT 4 and use with USMT 3.01.

    I performed the 'swap' and based on my 'findings' (initial/limited testing results using log files findings)

    1) specified the "/v:13" option

    2) set the "mig_enabled_diag" variable.

    AFTER running SCANSTATE 3.01 with above setting and NEW MIGAPP.XML from USMT 4 HOTFIX with Office 2010 support:

    1) did not 'see' any obvious unusual Warnings/Errors logged, that were that diff between the logs files generated using

      the OLD and NEW MIGAPP.XML files ( i would have assumed that the NEW MIGAPP.XML would have thrown syntax errors

       in thye log files (ie debug log)if it was that incompatible)

    2) The LOG file with OLD (original) USMT 3 MIGAPP.XML reported:

       successfully completed send operation: stored 7731 objects

        The MIG file created was 47,771 (in size)

    3) The LOG File with NEW (hotfix) USMT 4 MIGAPP.XML reported:

       successfully completed send operation: stored 7744 oobject

       The MIG file created was 47,776  (in size)

    The NEW MIGAPP actually found 13 more objects ( NOT LESS) to migrate.

    The NEW MIG file is ONLY 5 bytes diff (larger) than OLD MIG file. SO i assume (that word again) that NO data lost??!!

    The  Trace/debug files were generated (MIG_Enable_Diag=) and other than ORDERING of "MIG UNITS" , i do not

    'see' any obvious 'loss' of migration functionality between the TWO diff MIGAPP.XML files.

    BUT this was ONLY a BACKUP, did NOT do a RESTORE to verify that ALL expected Setting/files were migrated!!!


    Thanks.. J P Morgan

  8. james p morgan says:

    Daniel,Thanks for your feedback.. see NED'S reply below. The USMT BLOG has had NO ACTIVITY since Aug 2008!!! ??? So that dosnt look like someplace to go!!

    URL to Neds comment about USMT support..…/usmt-4-and-winpe-common-issues.aspx

    NedPyle [MSFT] 18 Feb 2010 8:03 AM Comments 1

    Ned here again. As odd as it sounds, when you call Microsoft for USMT 4.0 support, you will be sent to the Directory Services team. This is because we support user profiles loading and unloading, as that is a core piece of interactive logons. It’s a tangled web.

    J P Morgan 770-793-1946

Skip to main content