When planning for your migration, you should identify which applications and settings you want to migrate. For more information about how to create a custom .xml file to migrate the settings of another application, see Create a Custom XML File.
First, create and prioritize a list of applications that to be migrated. It may be helpful 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.
Next, 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 the organization. The application owner should have the most experience with an application. The application owner provides insight into how the organization installs, configures, and uses the application.
Next, determine and locate the application settings that to be migrated. You can acquire much of the information that you need for this step when you are testing the new applications for compatibility with the new operating system.
After completing the list of applications that to be migrated, review the list and work with each application owner on a list of settings to be migrated. For each setting, determine whether it needs to be migrated or if the default settings are adequate. Then, determine where the setting is located; for example, in the registry or in an .ini file. Next, consider the following questions to determine what needs to be done to migrate the setting successfully:
- Is the destination version of the application
newer than the source version?
- Do these settings work with the new
- Do the settings need to be moved or
- Can the first-run process force the
application to appear as if it had run already? If so, does this
work correctly, or does it break the application?
After answering these questions, create a custom .xml file to migrate settings. Work with the application owner to develop test cases and to determine the file types that need to be migrated for the application.
Locating Where Settings Are Stored
If the storage mechanism or location of a given setting is not clear, it can be difficult to create rules to migrate the setting. Settings can be stored in the registry, within .ini files, or within a text or binary file. To determine the location of a setting, start by checking the vendor’s documentation or their 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. The Regmon tool monitors registry activity, while the Filemon monitors file-system activity. To determine where a setting is stored, start the Regmon and Filemon tools to monitor the registry and file system, and then change the setting. Once you’ve done this, look in the log file for the registry and file-system data being written when you changed the setting, and note where that data is located.
Using an application-packaging tool, you can typically take a system snapshot, make a setting change, and then take another system snapshot to see what has changed. We recommend doing this on a computer that only has Windows® and the relevant application installed. For example, antivirus software can result in many instances of file-system and registry data being read and written. This will make it difficult to find the setting you are looking for. Also, be sure to keep an unprotected computer like this isolated from the network.