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
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 System Center 2012 Configuration Manager 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 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
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 by using database replication, any content that you assign to
a System Center 2012 Configuration Manager 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 the 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
System Center 2012 Configuration Manager
can migrate any of the default user collections, device
collections, and most custom collections from the Configuration
Manager 2007 source hierarchy. However,
System Center 2012 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 System Center 2012
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,
System Center 2012 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 System Center 2012
Configuration Manager collection 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
would then be 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 System Center 2012 Configuration Manager
site. This ensures that the migrated collection remains functional
in your System Center 2012 Configuration Manager
environment and does not increase in scope.
Specify Behavior for Migrated
Advertisements
By default, collection-based migration jobs disable
advertisements that migrate to System Center 2012
Configuration Manager and 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 New 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
