You can migrate software update objects, such as software update packages and software update deployments.

To successfully migrate software update objects, you must first configure your destination hierarchy with configurations that match your source hierarchy environment. This requires the following actions:

• Deploy an active software update point in the destination hierarchy.
  
  
• Configure the catalog of products and languages to match the configuration of your source hierarchy.
  
  
• Synchronize the software update point in the destination hierarchy with a Windows Server Update Services (WSUS).
  
  

When you migrate software updates, consider the following:

• Migration of software update objects can fail when you have not synchronized information in your destination hierarchy to match the configuration of your source hierarchy.
  
  

  Warning
  It is not supported to use the WSUSutil tool to synchronize data between a source and destination hierarchy.

• You cannot migrate custom updates that are published by using System Center Updates Publisher. Instead, custom updates must be republished to the destination hierarchy.
  
  

When you migrate from a Configuration Manager 2007 source hierarchy, the migration process modifies some software updates objects to the format in use by the destination hierarchy. Use the following table to help you plan the migration of software update objects from Configuration Manager 2007.

Configuration Manager 2007 object	Object name after migration
Software update lists	Software update lists are converted to software update groups.
Software update deployments	Software update deployments are converted to deployments and update groups. Note After you migrate a software update deployment from Configuration Manager 2007, you must enable it in the destination hierarchy before you can deploy it.
Software update packages	Software update packages remain software update packages.
Software update templates	Software update templates remain software update templates. Note The Duration value in Configuration Manager 2007 deployment templates does not migrate.

When you migrate objects from a supported System Center 2012 Configuration Manager or System Center 2012 R2 Configuration Manager hierarchy, the software updates objects are not modified.

You can migrate content from a supported source hierarchy to your destination hierarchy. For a Configuration Manager 2007 source hierarchy, this content includes software distribution packages and programs and virtual applications, such as Microsoft Application Virtualization (App-V). Beginning with System Center 2012 Configuration Manager source hierarchies, this content includes applications, and App-V virtual applications. When you migrate content between hierarchies, it is the compressed source files that migrate to the destination hierarchy.

Packages and Programs

When you migrate packages and programs, they are not modified by migration. However, before you migrate these, you must configure each package to use a Universal Naming Convention (UNC) path for its source file location. As part of the configuration to migrate packages and programs, you must assign a site in the destination hierarchy to manage this content. The content is not migrated from the assigned site, but after migration the assigned site accesses the original source file location by using the UNC mapping.

After you migrate a package and program to the destination hierarchy and while migration from the source hierarchy remains active, you can make the content available to clients in that hierarchy by using a shared distribution point. To use a shared distribution point, the content must remain accessible on the distribution point at the source site. For information about shared distribution points, see the Share Distribution Points Between Source and Destination Hierarchies section in the Planning a Content Deployment Migration Strategy in System Center 2012 Configuration Manager topic.

For content that has migrated, if the content version changes in either source hierarchy or the destination hierarchy, clients can no longer access the content from the shared distribution point in the destination hierarchy. In this scenario, you must re-migrate the content to restore a consistent version of the package between the source hierarchy and the destination hierarchy. This information synchronizes during the data gathering cycle.

Tip

For each package that you migrate, update the package in the destination hierarchy. This action can prevent issues with deploying the package to distribution points in the destination hierarchy. However, when you update a package on the distribution point in the destination hierarchy, clients in that hierarchy will no longer be able to acquire that package from a shared distribution point. To update a package in the destination hierarchy, in the Configuration Manager console, navigate to the Software Library, right click on the package, and then select Update Distribution Points. Do this action for each package that you migrated.

Tip
You can use Microsoft System Center Configuration Manager Package Conversion Manager to convert packages and programs into System Center 2012 Configuration Manager or System Center 2012 R2 Configuration Manager applications. Download Package Conversion Manager from the Microsoft Download Center site. For more information, see Configuration Manager Package Conversion Manager.

Virtual Applications

When you migrate App-V packages from a supported Configuration Manager 2007 site, the migration process converts them to applications in the destination hierarchy. Additionally, based on existing advertisements for the App-V package, the following deployment types are created in the destination hierarchy:

• If there are no advertisements, one deployment type is created that uses the default deployment type settings.
  
  
• If one advertisement exists, one deployment type is created that uses the same settings as the Configuration Manager 2007 advertisement.
  
  
• If multiple advertisements exist, a deployment type is created for each Configuration Manager 2007 advertisement, using the settings for that advertisement.
  
  

Important
If you migrate a previously migrated Configuration Manager 2007 App-V , the migration fails because virtual application packages do not support the overwrite migration behavior. In this scenario, you must delete the migrated virtual application package from the destination hierarchy, and then create a new migration job to migrate the virtual application.

Note
After you migrate an App-V package, you can use the Update Content Wizard to change the source path for App-V deployment types. For information on how to update content for a deployment type, see the How to Manage Deployment Types section in the How to Manage Applications and Deployment Types in Configuration Manager topic.

When you migrate from a System Center 2012 Configuration Manager or System Center 2012 R2 Configuration Manager source hierarchy, in addition to App-V deployment types and applications, you can migrate objects for the e App-V virtual environment. For information about App-V environments, see the App-V Virtual Environments section in the Introduction to Application Management in Configuration Manager topic.

Advertisements

You can migrate advertisements from a supported Configuration Manager 2007 source site to the destination hierarchy by using collection-based migration. If you upgrade a client, it retains the history of previously run advertisements to prevent the client from rerunning migrated advertisements.

Note
You cannot migrate advertisements for virtual packages. This is an exception to the migration of advertisements.

Applications

You can migrate the criteria for collections from a supported System Center 2012 Configuration Manager or System Center 2012 R2 Configuration Manager source hierarchy. For this, you use an object-based migration job. When you migrate a collection, you migrate the rules for the collection and not information about the members of the collection or information or objects related to the members of the collection.

Migration of the collection object is not supported when you migrate from a Configuration Manager 2007 source hierarchy.

You can migrate the following operating system deployment objects from a supported source hierarchy:

• Operating system images and packages. The source path of boot images are updated to the default image location for the Windows Administrative Installation Kit (Windows AIK) on the destination site. The following are requirements and limitations to migrating operating system images and packages:
  
  
  • To successfully migrate image files, the computer account of the SMS Provider server for the destination hierarchies top-level site must have Read and Write permission to the image source files of the source sites Windows AIK location.
    
    
  • When you migrate an operating system installation package, ensure that the configuration of the package on the source site points to the folder that contains the WIM file, and not to the WIM file itself. If the installation package points to the WIM file, the migration of the installation package will fail.
    
    
  • When you migrate a boot image package from a Configuration Manager 2007 source site, the package ID of the package is not maintained in the destination site. The result of this is that clients in the destination hierarchy cannot use boot image packages that are available on shared distribution points.
    
    
• Task sequences. When you migrate a task sequence that contains a reference to a client installation package, that reference is replaced with a reference to the client installation package of the destination hierarchy.
  
  

  Note
  When you migrate a task sequence, Configuration Manager might migrate objects that are not required in the destination hierarchy. These objects include boot images and Configuration Manager 2007 client installation packages.

• Drivers and driver packages.
  
  

You can migrate configuration items and configuration baselines.

Note

Uninterpreted configuration items from Configuration Manager 2007 source hierarchies are not supported for migration. You cannot migrate or import these configuration items to the destination hierarchy. For information about uninterpreted configuration items, see the “Uninterpreted Configuration Item” section in the About Configuration Items in Desired Configuration Management topic in the Configuration Manager 2007 documentation library.

You can import Configuration Manager 2007 Configuration Packs. The import process automatically converts the Configuration Pack to be compatible with System Center 2012 Configuration Manageror System Center 2012 R2 Configuration Manager.

You cannot migrate the AMT provisioning information between hierarchies and must take additional steps before you can manage an AMT-based computer out of band in the destination hierarchy. These steps include the removal from clients of the AMT provisioning information from the source site, and then provisioning new information from a site in the destination hierarchy. To do this, make sure that you have installed and configured a site in the destination hierarchy for AMT provisioning, and then use one of the following strategies:

• In the source site, remove the AMT provisioning information and select the option Disable automatic provisioning. Migrate the client. Then in the destination site, provision the AMT-based computer.
  
  
• In the destination site, configure the AMT Provisioning Removal Account in the Out of Band Management Component Properties: Provisioning tab. Specify a Windows account that has been specified as an AMT User Account in the source site. For migration from a supported Configuration Manager 2007 site, ensure this AMT User Account has the Platform Administration (Configuration Manager 2007 SP2) or PT Administration (Configuration Manager 2007 SP1) permission. Migrate the client and assign it to the destination site. Then remove the provisioning information from the AMT-based computer by using the AMT Provisioning Removal Account, and provision it again.
  
  

  Warning

  If the account that you specify for the AMT Provisioning Removal Account is not an AMT User Account for the computer, or the AMT User Account does not have the required permission, or if the audit log contains data, you will not be able to remove the provisioning information from the destination site. If you are not sure whether the AMT-based computer is configured with this AMT User Account, for Configuration Manager 2007 source sites either check and update the management controller in the Configuration Manager 2007 site, or remove the provisioning information when the client is still assigned to the Configuration Manager 2007 site. If AMT auditing is enabled, either clear the audit log or disable auditing when the client is still assigned to the Configuration Manager 2007 site. For more information about how to manage the audit log in Configuration Manager 2007, see How to Manage the Audit Log for AMT-based Computers in the Configuration Manager 2007 documentation library.

• Migrate the client. Manually remove the provisioning information in the BIOS extensions of the AMT-computer. Then in the destination site, provision the AMT-based computer.
  
  

For more information about how to remove the AMT provisioning information, configure AMT User Accounts, and update the management controllers from a Configuration Manager 2007 site, see the following topics in the Configuration Manager 2007 documentation library:

• How to Remove Provisioning Information for AMT-Based Computers
  
  
• How to Configure AMT Settings and AMT User Accounts
  
  
• How to Update AMT Settings in Provisioned Computers Using Out of Band Management
  
  

For more information about how to configure AMT provisioning, the AMT Provisioning Removal Account, and how to remove AMT provisioning information in a System Center 2012 Configuration Manager or System Center 2012 R2 Configuration Manager site, see the following:

• How to Provision and Configure AMT-Based Computers in Configuration Manager
  
  
• The How to Remove AMT Information section in the How to Manage AMT Provisioning Information in Configuration Manager topic.
  
  

You can migrate boundaries between hierarchies. When you migrate boundaries from Configuration Manager 2007, each boundary from the source site migrates at the same time and is added to a new boundary group that is created in the destination hierarchy. When you migrate boundaries from a System Center 2012 Configuration Manager or System Center 2012 R2 Configuration Manager hierarchy, each boundary you select is added to a new boundary group in the destination hierarchy.

Each automatically created boundary group is enabled for content location but not for site assignment. This prevents overlapping boundaries for site assignment between the source and destination hierarchies. When you migrate from a Configuration Manager 2007 source site, this helps prevent new Configuration Manager 2007 clients that install from incorrectly assigning to the destination hierarchy. By default, System Center 2012 Configuration Manager and System Center 2012 R2 Configuration Manager clients do not automatically assign to Configuration Manager 2007 sites.

During migration, if you share a distribution point with the destination hierarchy, any boundaries that are associated with that distribution automatically migrate to the destination hierarchy. In the destination hierarchy, migration creates a new read-only boundary group for each shared distribution point. If you change the boundaries for the distribution point in the source hierarchy, the boundary group in the destination hierarchy updates with these changes during the next data gathering cycle.

Configuration Manager does not support the migration of reports. Instead, use SQL Server Reporting Services Report Builder to export reports from the source hierarchy, and then import them to the destination hierarchy.

Note
Because there are schema changes for reports between Configuration Manager 2007 and System Center 2012 Configuration Manager, test each report that you import from a Configuration Manager 2007 hierarchy to ensure that it functions as expected.

For more information about reporting, see Reporting in Configuration Manager.

You can migrate organizational folders and search folders from a supported source hierarchy to a destination hierarchy. In addition, from a System Center 2012 Configuration Manager source hierarchy, you can migrate the criteria for a saved search to a destination hierarchy.

By default, the migration process maintains your search folder and administrative folder structures for objects and collections when you migrate. However, in the Create Migration Job Wizard, on the Settings page, you can configure a migration job to not migrate the organizational structure for objects by clearing the check box for this option. The organizational structures of collections are always maintained.

One exception to this is a search folder that contains virtual applications. When an App-V package is migrated, the App-V package is transformed into an application in System Center 2012 Configuration Manager. After migration of the search folder, only the remaining packages are found, and the search folder cannot locate an App-V package because of this conversion to an application when the App-V package migrates.

When you migrate a saved search from a System Center 2012 Configuration Manager source hierarchy, you migrate the criteria for the search, and not the information about the search results. Migration of a saved search is not applicable from a Configuration Manager 2007 source site.

You can migrate customizations for Asset Intelligence from a supported source hierarchy to a destination hierarchy. There are no significant changes to the structure of Asset Intelligence customizations between Configuration Manager 2007 and System Center 2012 Configuration Manager.

Note
System Center 2012 Configuration Manager does not support the migration of Asset Intelligence objects from a Configuration Manager 2007 site that is using Asset Intelligence Service 2.0 (AIS 2.0).

There are no significant changes to software metering between Configuration Manager 2007 and System Center 2012 Configuration Manager. You can migrate your software metering rules from a supported source hierarchy to a destination hierarchy.

By default, software metering rules that you migrate to a destination hierarchy are not associated with a specific site in the destination hierarchy and instead apply to all clients in the hierarchy. To apply a software metering rule to clients at a specific site, you must edit the metering rule after it migrates.

Concepts