Use migration jobs to configure the specific data that you want to migrate to your System Center 2012 Configuration Manager environment. Migration jobs identify the objects that you plan to migrate, and they run at the top-level site in your destination hierarchy. You can configure one or more migration jobs per source site. This allows you to migrate all objects at one time or limited subsets of data with each job.

You can create migration jobs after Configuration Manager has successfully gathered data from one or more sites from the source hierarchy. You can migrate data in any sequence from the source sites that have gathered data. With a Configuration Manager 2007 source site, you can migrate data only from the site where an object was created. With System Center 2012 Configuration Manager source sites, all data that you can migrate is available at the top-level site of the source hierarchy.

Before you migrate clients, ensure that the objects that clients use have migrated and that these objects are available in the destination hierarchy. For example, when you migrate from a Configuration Manager 2007 SP2 source hierarchy, you might have an advertisement for content that is deployed to a custom collection that contains a client. In this case you should migrate the collection, the advertisement, and the associated content before you migrate the client. This is because, when the content, collection and advertisement are not migrated before the client migrates, this data cannot be associated with the client in the destination hierarchy. If a client is not associated with the data related to a previously run advertisement and content, the client can be offered the content for installation in the destination hierarchy, which might be unnecessary. When the client migrates after the data has migrated, the client is associated with this content and advertisement, and unless the advertisement is recurring, is not offered this content for the migrated advertisement again.

Some objects require more than the migration of data from the source hierarchy to the destination hierarchy. For example, to successfully migrate software updates for your clients to your destination hierarchy, in the destination hierarchy you must deploy an active software update point, configure the catalog of products, and synchronize the software update point with a Windows Server Update Services (WSUS).

Use the following sections to help you plan your migration jobs.

Types of Migration Jobs

System Center 2012 Configuration Manager supports the following types of migration jobs. Each job type is designed to help define the objects that you can include in that job.

Migration job type Source hierarchy More information

Collection migration

Supported for migration from the following source hierarchies:

  • Configuration Manager 2007 SP2

Migrate objects that are related to collections you select. By Default, collection migration includes all objects that are associated with members of the collection. You can exclude specific object instances when you use a collection migration job.

Object migration

Supported for migration from the following source hierarchies:

  • Configuration Manager 2007 SP2

  • System Center 2012 Configuration Manager SP1

Migrate individual objects that you select. You select only the specific data that you want to migrate.

Previously migrated object migration

Supported for migration from the following source hierarchies:

  • Configuration Manager 2007 SP2

  • System Center 2012 Configuration Manager SP1

Migrate objects that you previously migrated, when those objects have updated in the source hierarchy after they were last migrated.

Objects That You Can Migrate

General Planning for All Migration Jobs

Use the Create Migration Job Wizard to create a migration job to migrate objects to your destination hierarchy. The type of the migration job that you create determines which objects are available to migrate. You can create and use multiple migration jobs to migrate data from the same source site, or from multiple source sites. The use of one type of migration job does not block the use of a different type of migration job.

After a migration job runs successfully, its status is listed as Completed and it cannot be run again. However, you can create a new migration job to migrate any of the objects that were migrated by the original job, and the new migration job can include additional objects as well. When you create additional migration jobs the objects that have been previously migrated display with the state of Migrated. You can select these objects to migrate them again; however, unless the object has been updated in the source hierarchy, migrating these objects again is not necessary. If the object has been updated in the source hierarchy after it was originally migrated, you can identify that object when you use the migration job type of Objects modified after migration.

You can delete a migration job before it runs. However, after a migration job completes, it remains visible in the Configuration Manager console and cannot be deleted. Each migration job that has completed or has not yet run remains visible in the Configuration Manager console until you complete the migration process and clean up migration data.

After you have completed migration by using the Clean Up Migration Data action, you can reconfigure the same hierarchy as the current source hierarchy to restore visibility to the objects you previously migrated.

You can view the objects contained in any migration job in the System Center 2012 Configuration Manager console by selecting the migration job, and then clicking the Objects in Job tab.

Use the information in the following sections to help you plan for all migration jobs.

Data Selection

Site Ownership for Migrated Content

Configure Role-based Administration Security Scopes for Migrated Data

Review Migration Actions

Scheduling Migration Jobs

Specify Conflict Resolution for Migrated Data

Planning for Collection Migration Jobs

Collection migration jobs are available only when you migrate data from a source hierarchy that runs a supported version of Configuration Manager 2007. You must specify one or more collections to migrate when you migrate by collection. For each collection that you specify, the migration job automatically selects all related objects for migration. For example, if you select a specific collection of users, the collection members are then identified, and you can migrate the deployments associated with that collection. Optionally, you can select other deployment objects to migrate that are associated with those members. All these selected items are added to the list of objects that can be migrated.

When you migrate a collection, Configuration Manager also migrates collection settings including maintenance windows and collection variables, but cannot migrate collection settings for AMT client provisioning.

Use the information in the following sections to understand additional configurations that can apply to collection-based migration jobs.

Excluding Objects from Collection Migration Jobs

Unsupported Collections

Empty Collections

Linked Collections and Subcollections

Collection Dependencies and Include Objects

Collection Limiting

Site Code Replacement

Specify Behavior for Migrated Advertisements

Planning for Object Migration Jobs

Unlike collection migration, you must select each object and object instance that you want to migrate. You can select the individual objects, such as advertisements from a Configuration Manager 2007 hierarchy or a publication from a System Center 2012 Configuration Manager hierarchy, to add to the list of objects to migrate for a specific migration job. Any objects that you do not add to the migration list are not migrated to the destination site by the object migration job.

Object-based migration jobs do not have any additional configurations to plan for beyond those applicable to all migration jobs.

Planning for Previously Migrated Object Migration Jobs

When an object that you have already migrated to the destination hierarchy is updated in the source hierarchy, you can migrate that object again by using the Objects modified after migration job type. For example, when you rename, or update the source files for a package in the source hierarchy, the package version increments in the source hierarchy. After the package version increments, the package can be identified for migration by this job type.

This job type is similar to the object migration type except that when you select objects to migrate, you can only select from objects that have been updated after they were migrated by a previous migration job.

When you select this job type, the conflict resolution behavior on the Settings page of the New Migration Job Wizard is configured to overwrite previously migrated objects, and this setting cannot be changed.

This migration job can identify objects that are automatically updated by the source hierarchy and objects that an administrative user updates.

See Also