Identify Applications Settings

When planning for your migration, you should identify which applications and settings that you want to migrate. For more information about how to create a custom .xml file to migrate the settings of another application, see How To Create a Custom .xml File.


You should create and prioritize a list of applications that you want to migrate. It may be helpful to establish a committee to review the application lists and decide which applications will be redeployed and which applications will be retired. Often the applications are prioritized based on a combination of how widely the application is used and how complex the application is.

After you have created your list, you should identify an application owner to be in charge of each application. This is necessary because the developers will not be experts on all of the applications in your organization. The application owner might not be an expert on the application, but will be the person who has the most experience with the application. The application owner will provide insight into how the organization installs, configures, and uses the application.

Application settings

You will need to determine and locate the application settings that you want to migrate. You can acquire a lot of the information that you need for this step when you are testing the new applications for compatibility with the new operating system (for example, application inventory, and installation locations). Instead of duplicating your efforts, you can use your application tracking database to hold the info that you will need to determine what user application settings to migrate.

You should review the list of applications that you have decided to migrate and work with the application owner to list the possible settings. For each setting, you should determine whether it needs to be migrated or if you want to apply standard settings. Then determine where the setting is located (for example, in the registry or in an .ini file). Next you should consider the following questions to determine what needs to be done in order to migrate the setting successfully.

  • Is the destination version of the application newer than the source version?
  • Is it appropriate to migrate these setting to the new version (will it work)?
  • Do the settings need to be moved or altered?
  • Can the first run process fool the application into thinking it has run already? Does this work or break the application?

After answering the previous questions, you will then need to create a custom .xml file to migrate settings. You should work with the application owner to develop test cases and also to determine the file types that need to be migrated for the application.

Locating Where Settings Are Stored

If you do not know the storage mechanism or location of a given setting, it can be difficult to create rules to migrate the setting. Settings can be stored in the registry, .ini files, or a text or binary file. To determine the location of a setting, start by checking the vendor’s documentation or Web site.

If the location of a setting is not documented, you can use tools like Regmon and Filemon from the Sysinternals Web site ( or a non-Microsoft application-packaging tool to find it. Regmon monitor registry activity and Filemon monitors file system activity. To determine where a setting is stored, start Regmon and Filemon monitoring and then change the setting. Once you’ve done this, look for registry and file system writes that occurred when you changed the setting and note where those writes are located.

Using an application packaging tool, you can typically take a snapshot, make a setting change, and then take another snapshot to see what has changed. We recommend doing this on a computer that only has Windows installed and the relevant application. For example, antivirus software can result in many file system and registry reads and writes, which will make it difficult to find the setting you are looking for. Also, you should keep an unprotected computer like this isolated from the network.