Planning a Migration Job Strategy in System Center 2012 Configuration Manager
Updated: May 14, 2015
Applies To: System Center 2012 Configuration Manager, System Center 2012 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, System Center 2012 R2 Configuration Manager, System Center 2012 R2 Configuration Manager SP1
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 between hierarchies, 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 scenario 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
General Planning for All Migration Jobs
Planning for Collection Migration Jobs
Planning for Object Migration Jobs
Planning for Previously Migrated Object Migration Jobs
Types of Migration Jobs
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:
|
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:
|
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:
|
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
Not every object can migrate by a specific type of migration job. The following table identifies the type of objects that you can migrate with each type of migration job.
Note
Collection migration jobs are available only when you migrate objects from a Configuration Manager 2007 SP2 source hierarchy.
Object type |
Collection migration |
Object migration and previously migrated object migration |
|---|---|---|
Advertisements (Available to migrate from supported Configuration Manager 2007 source sites) |
Yes |
No |
Asset Intelligence catalog |
No |
Yes |
Asset Intelligence hardware requirements |
No |
Yes |
Asset Intelligence software list |
No |
Yes |
Boundaries |
No |
Yes |
Configuration baselines |
Yes |
Yes |
Configuration items |
Yes |
Yes |
Maintenance windows |
Yes |
No |
Operating system deployment boot images |
Yes |
Yes |
Operating system deployment driver packages |
Yes |
Yes |
Operating system deployment drivers |
Yes |
Yes |
Operating system deployment images |
Yes |
Yes |
Operating system deployment packages |
Yes |
Yes |
Software distribution packages |
Yes |
Yes |
Software metering rules |
No |
Yes |
Software update deployment packages |
Yes |
Yes |
Software update deployment templates |
Yes |
Yes |
Software update deployments |
Yes |
No |
Software update lists |
No |
Yes |
Task sequences |
Yes |
Yes |
Virtual application packages |
Yes |
Yes Important Although you can migrate a virtual application package by using object migration, the packages cannot be migrated by using the migration job type of Previously Migrated Object Migration. Instead, you must delete the migrated virtual application package from the destination site and then create a new migration job to migrate the virtual application. |
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.
Note
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 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
When you create a collection migration job, you must select one or more collections. After you select the collections the Create Migration Job Wizard displays the objects that are associated with the collections. By default, all objects associated with the selected collections are migrated, but you can clear the objects that you do not want to migrate with that job. When you clear an object that has dependent objects, those dependent objects are also cleared. All cleared objects are added to an exclusion list. Objects on an exclusion list are removed from automatic selection for future migration jobs. You must manually edit the exclusion list to remove objects that you want to have automatically selected for migration in migration jobs you create in the future.
Site Ownership for Migrated Content
When you migrate content for deployments, you must assign the content object to a site in the destination hierarchy. This site then becomes the owner for that content in the destination hierarchy. Although the top-level site of your destination hierarchy is the site that actually migrates the metadata for content, it is the assigned site that accesses the original source files for the content across the network.
To minimize the network bandwidth that is used during migration, consider transferring ownership of content to the closest available site. Because information about the content is shared globally in System Center 2012 Configuration Manager, it will be available at every site.
Although information about content is shared to all sites in the destination hierarchy by using database replication, any content that you assign to a primary site and then deploy to distribution points at other primary sites, transfers by using file-based replication. This transfer is routed through the central administration site and then to each additional primary site. By centralizing packages that you plan to distribute to multiple primary sites before or during migration when you assign a site as the content owner, you can reduce data transfers across low bandwidth networks.
Configure Role-based Administration Security Scopes for Migrated Data
When you migrate data to a destination hierarchy, you must assign one or more role-based administration security scopes to the objects whose data is migrated. This ensures that only the appropriate administrative users have access to this data after it is migrated. The security scopes that you specify are defined by the migration job and are applied to each object that is migrated by that job. If you require different security scopes to be applied to different sets of objects, and you want to assign those scopes during migration, you must migrate the different sets of objects by using different migration jobs.
Before you configure a migration job, review how role-based administration works in System Center 2012 Configuration Manager, and if necessary, configure one or more security scopes for the data that you migrate to control who will have access to the migrated objects in the destination hierarchy.
For more information about security scopes and role-based administration, see the Planning for Role-Based Administration section in the Planning for Security in Configuration Manager topic.
Review Migration Actions
When you configure a migration job, the Create Migration Job Wizard displays a list of actions that you must take to ensure a successful migration and a list of actions that Configuration Manager takes during the migration of the selected data. Review this information carefully to verify the expected outcome.
Scheduling Migration Jobs
By default, a migration job runs immediately after it is created. However, you can specify when the migration job runs when you create the job or later by editing the properties of the job. You can schedule the migration job to run at the following times.
Run the job now
Run the job at a specific start time
Not run the job
Specify Conflict Resolution for Migrated Data
By default, migration jobs do not overwrite data in the destination database, unless you configure the migration job to skip or overwrite data that has previously been migrated to the destination database.
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
You can exclude specific objects from a collection migration job. When you exclude a specific object from a collection migration job, that object is added to a global exclusion list that contains all the objects that you have excluded from migration jobs created for any source site in the current source hierarchy. Objects on the exclusion list are still available for migration in future jobs but are not automatically included when you create a new collection-based migration job.
You can edit the exclusion list to remove objects that you have previously excluded. After you remove an object from the exclusion list, it is then automatically selected when an associated collection is specified during the creation of a new migration job.
Unsupported Collections
Configuration Manager can migrate any of the default user collections, device collections, and most custom collections from a Configuration Manager 2007 source hierarchy. However, Configuration Manager cannot migrate collections that contain users and devices in the same collection.
The following collections cannot be migrated:
A collection that contains users and devices.
A collection that contains a reference to a collection of a different resource type. For example, a device-based collection that has either a subcollection or a link to a user-based collection. In this example only the top-level collection migrates.
A collection that contains a rule to include unknown computers. The collection migrates, but the rule to include unknown computers does not migrate.
Empty Collections
An empty collection is a collection that has no resources associated with it. When Configuration Manager migrates an empty collection, it converts the collection to an organizational folder that contains no users or devices. This folder is created with the name of the empty collection under the User Collections or Device Collections node in the Assets and Compliance workspace in the Configuration Manager console.
Linked Collections and Subcollections
When you migrate collections that are linked to other collections or that have subcollections, Configuration Manager creates a folder under the User Collections or Device Collections node in addition to the linked collections and subcollections.
Collection Dependencies and Include Objects
When you specify a collection to migrate in the Create Migration Job Wizard, any dependent collections are automatically selected to be included with the job. This behavior ensures that all necessary resources are available after migration.
For example: You select a collection for devices that run Windows 7 and that is named Win_7. This collection is limited to a collection that contains all your client operating systems and that is named All_Clients. The collection All_Clients will be automatically selected for migration.
Collection Limiting
Because System Center 2012 Configuration Manager collections are global data and are evaluated at each site in the hierarchy, plan how to limit the scope of a collection after it is migrated. During migration, you can identify a collection from the destination hierarchy to use to limit the scope of the collection that you are migrating so that the migrated collection does not include unanticipated members.
For example, in Configuration Manager 2007, collections are evaluated at the site that creates them, and at child sites. An advertisement might be deployed to only a child site, and this would limit the scope for that advertisement to that child site. In comparison, System Center 2012 Configuration Manager evaluates collections at every site, and associated advertisements are then evaluated for each site. Collection limiting lets you refine the collection members based on another collection to avoid the addition of unexpected collection members.
Site Code Replacement
When you migrate a collection that contains criteria that identifies a Configuration Manager 2007 site, you must specify a specific site in the destination hierarchy. This ensures that the migrated collection remains functional in your destination hierarchy and does not increase in scope.
Specify Behavior for Migrated Advertisements
By default, collection-based migration jobs disable advertisements that migrate to the destination hierarchy. This includes any programs that are associated with the advertisement. When you create a collection-based migration job that contains advertisements, you see the Enable programs for deployment in Configuration Manager 2012 after an advertisement is migrated option on the Settings page of the Create Migration Job Wizard. If you select this option, programs that are associated with the advertisements are enabled after they have migrated. As a best practice, do not select this option and instead, enable the programs after they have migrated when you can verify the clients that will receive them.
Note
You see the Enable programs for deployment in Configuration Manager 2012 after an advertisement is migrated option only when you create a collection-based migration job, and the migration job contains advertisements.
To enable a program after migration, clear the option Disable this program on computers where it is advertised on the Advanced tab of the program properties.
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 Create Migration Job Wizard is configured to overwrite previously migrated objects, and this setting cannot be changed.
Note
This migration job can identify objects that are automatically updated by the source hierarchy and objects that an administrative user updates.