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 or System Center 2012 R2 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
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
- System Center 2012 R2 Configuration
Manager
|
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
- System Center 2012 R2 Configuration
Manager
|
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 and System Center 2012 R2 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 System Center 2012 R2 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 and System Center 2012 R2 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
and System Center 2012 R2 Configuration Manager evaluate
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 or System
Center 2012 R2 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. |
See Also
