CEP meeting #10 summary “SCCM 2007 to SCCM 2012 Migration”

Today the 10th theme of the Configuration Manager 2012 CEP was presented by Eric Orman, part of the Configuration Manager product team. This livecast session was about migrating ConfigMgr 2007 to ConfigMgr 2012. In the past the easiest way of migrating SMS 2003 to SCCM 2007 was a side by side migration. With SCCM 2012 things are going to change for the best, the very best 🙂

Like I mentioned in earlier blogs while I was at TechEd in Berlin, the CM team is going to make the migration of SCCM 2007 to SCCM 2012 much easier.

With the new Migration Feature in SCCM 2012 the CM Team wants to reach the following goals:

  • Assist with the migration of Objects
  • Assist with the migration of Clients
  • Minimize WAN impact
  • Assist with flattening of the hierarchy
  • Maximize reusability of x84 server hardware

The migration process of SCCM 2007 to SCCM 2012 can be split up in three phases: Plan, Deploy and Migrate.


  • Assess current environment
  • Test/Proof of Concept
  • Design
  • Requires SCCM 2007 SP2
  • SCCM 2012 requirements: Windows 2008 x64, SQL 2008 x64 (sp1 & cumulative update 10)


  • Setup initial SCCM 2012 site(s)
  • Configure Software Update Point and Synchronize Updates
  • Setup server roles
  • Make sure the hierarchy is operating  and software deployment works


  • Enable data gathering process to acquire information from the existing SCCM 2007 environment
  • Migrate objects
  • Migrate Clients
  • Migrate DP
  • Uninstall Configuration Manager 2007 sites
  • Rinse & Repeat

The Migration process

Since the session is about the migration of SCCM 2007, the migration process is described below

  1. Enable migration by specifying a SCCM 2007 source hierarchy central site.
  2. Enable Distribution Point Sharing.
  3. Create migration jobs.
  4. Begin to upgrade and reassign clients to SCCM 2012 sites.
  5. Distribute or leverage distribution point sharing for deployment of migrated objects to SCCM 2012 client.
  6. After migrating the clients, either distribute content to the SCCM 2012 Distribution Points or upgrade SCCM 2007 Distribution Points to a SCCM 2012 Distribution Points.
  7. Decommission SCCM 2007 infrastructure

Enabling migration:

Enabling the migration is done by connecting to the top most SCCM 2007 site. This is done by specifying a migration source; this is always the top most Primary Site Server in the source hierarchy. After creating the migration source, the gathering process will start. This is no processor or network intensive process and after the initial gathering only delta data is processed. SCCM 2012 checks the SCCM 2007 sites every 4 hours to keep the data accurate.

Step two in enabling the migration is to configure the credentials per site top down.

Enable distribution point sharing:

If you enable distribution point sharing, you are able to share the ”old” SCCM 2007 distribution point with the SCCM 2012 clients. The SCCM 2012 clients can access the data on the distribution points while transitioning everything to SCCM 2012. The clients can fall back to the distribution points for software update deployment and classic distribution of applications. Boot images and app-v content is excluded while sharing distribution points.

Migrating distribution points can be done by an in place upgrade or a side by side migration. (moving data to a new distribution point.)

Create migration jobs

Migration jobs can be created

  • Collections
  • Advertisements
  • Bounderies
  • Software Distribution Packages and Virtual Application Packages
  • Software Updates
    • Deployments, Deployment Packages, Templates and Software Update Lists
  • Operating System Deployment  
    • Boot images, driver packages, drivers, images, packages and task sequences
  • Settings Management
    • Configuration Baselines and Configuration Items
  • Asset Intelligence Customizations
  • Software Metering Rules

At this moment the migration of the Forefront Endpoint Protection integration is not yet covered in the Beta 2 version, but it will be in the final version.

Migrating  jobs can be created for:

  • Collections
  • Objects
  • Objects modified after migration

When choosing to create a migration job for a collection, it will give you the opportunity to migrate all associated advertisements, software deployment packages, software update deployments (if SUP is installed), software update deployments packages and configuration baselines. When migrating a hierarchy of collections, the empty collections in the hierarchy are migrated to organizational folders. Permissions are always set on collections not on folders. Sub-collections and liked collections are history!

Mixed collections are not supported.

When migrating a global collection (like All Windows 7 machines), you can limit the scope because normally when a collection is migrated it will be available globally.

When choosing to create a migration job for a task sequence, it will migrate all reference packages of the task sequence. So after the migration of the task sequence, you can use it instantly. Nice!

When a migration job fails, it is not necessary true that the whole job is failed. A part the job can be completed.

The jobs can be scheduled or runned instantly.


Software and Hardware Inventory is not migrated.


The boundaries are grouped when migrated. When the Shared Distribution Point option is enabled the boundaries are automatically migrated.

Software Updates:

Ensure that the Software Update Point is configured and the Update Repository contains the same updates as in the SCCM 2007 environment. You can use wsutil.exe export/import

Supported by the migration:

  • Conversion of Update lists to Update groups
  • Software Update Deployments are migrated to Deployments and Groups
  • Software Update Packages
  • Software Update Templates

Software deployment

  • Classic packages and programs are installed as is.
  • App-v packages are converted to applications. After the migration a deployment needs to be created.

OS Deployment


  • OS-Image / Package
  • Task Sequences
  • Drivers and driver packages

Special cases:

  • Boot image source path for beta is replaced by default image on SCCM 2012 site due to new WAIK
  • SCCM 2012 will not convert the Client installation package

Settings Management (DCM)


  • Configuration and baselines created by customers and ISV’s, un-interpreted configuration items are not supported
  • Upon re-migration of a object the changes are added as a new revision

Existing SCCM 2007 config packs can also be added to SCCM 2012 through the import feature.

Additional objects that can be migrated:

  • Asset intelligence customizations
  • Software metering rules
  • Search and administrative folders

Migration rules and prepare your environment:

  • Never use the same Site Code in the SCCM 2007 and SCCM 2012 environments
  • Always use UNC paths as packet sources for packages
  • Avoid mixing user and devices in one collection, this is not supported anymore
  • Don’t use collections with multiple query rules

Theme 10 was a session with loads of information, during MMS I will attend a lot of SCCM 2012 session so read all about it over here! J Can’t wait until it’s the end of March, because SCCM 2012 Beta2 will go public!

Next session is March 9, SCCM 2012 overview.


Leave a Reply

Your email address will not be published. Required fields are marked *

Previous Post

Migrating Exchange 2003 to Exchange 2010 Notes from the field

Next Post

System Center stuff coming up on our YouTube channel

Related Posts