To migrate clients from the source hierarchy to a Microsoft System Center 2012 Configuration Manager destination hierarchy, you must perform two tasks. You must migrate the objects that are associated with the client and you must reassign the clients from the source hierarchy to the destination hierarchy. For best results, migrate the objects first so that they are available when the clients are migrated. The objects associated with the client are migrated by using migration jobs. For information about how to migrate the objects that are associated with the client, see Planning a Migration Job Strategy in System Center 2012 Configuration Manager.

Use the following sections to plan how you migrate clients to the destination hierarchy.

Planning How to Migrate Clients to the Destination Hierarchy

When you migrate clients from a source hierarchy, the client software is updated based on the version of the source hierarchy:

  • Configuration Manager 2007 source hierarchy: When you migrate clients from a source hierarchy that runs a supported version of Configuration Manager 2007, the client software upgrades to the client version for the destination hierarchy.

  • System Center 2012 Configuration Manager SP1 source hierarchy: When you migrate clients from a System Center 2012 Configuration Manager SP1 hierarchy to another System Center 2012 Configuration Manager SP1 hierarchy, the client software does not change or upgrade. Instead, the client reassigns from the source hierarchy to a site in the destination hierarchy.

    Note
    It is not supported to migrate from a source hierarchy that runs System Center 2012 Configuration Manager with no service pack, to a destination hierarchy that runs System Center 2012 Configuration Manager SP1. Instead, upgrade all sites and clients in the source hierarchy to System Center 2012 Configuration Manager SP1. After the source hierarchy upgrades, you can migrate between the hierarchies.

Use the following information to help you plan the client migration:

  • To upgrade or reassign clients from the source site to the destination site, use any client deployment method that is supported for deploying clients in the destination hierarchy. Typical client deployment methods include client push installation, software distribution, Group Policy, and software update-based client installation. For more information, see Determine the Client Installation Method to Use for Windows Computers in Configuration Manager.

  • Ensure the device that runs the client software is a supported operating system version and meets the minimum hardware requirements for the destination hierarchy.

  • Before you migrate a client, run a migration job to migrate the information the client will use in the destination hierarchy.

  • Clients that upgrade retain their run history for deployments to prevent deployments from rerunning unnecessarily in the destination hierarchy:

    • For Configuration Manager 2007 clients, advertisement run history is retained.

    • For System Center 2012 Configuration Manager clients, deployment run history is retained.

  • You can migrate clients from sites in the source hierarchy in any order that you choose. However, consider migrating limited numbers of clients in phases, rather than large numbers of clients at a single time. A phased migration reduces the network bandwidth requirements and server processing when each newly upgraded client submits its initial full inventory and compliance data to its assigned site.

  • When you migrate Configuration Manager 2007 clients, the existing client software is uninstalled from the client computer, and the new client software is installed.

  • System Center 2012 Configuration Manager cannot migrate a Configuration Manager 2007 client that has the App-V client installed, unless the App-V client version is 4.6 SP1 or later.

You can monitor the client migration process in the Migration node of the Administration workspace in the Configuration Manager console.

After you migrate the client to the destination hierarchy, you can no longer manage that device by using your source hierarchy and should consider removing the client from the source hierarchy. Although this is not a requirement when you migrate hierarchies, it can help prevent identification of a migrated client in a source hierarchy report, or an incorrect count of resources between the two hierarchies during the migration. For example, when a migrated client remains in the source site database, you might run a software updates report that incorrectly identifies the computer as an unmanaged resource when it is now managed by the destination hierarchy.

Planning How to Handle Data Maintained on Clients During Migration

When you migrate a client from its source hierarchy to the destination hierarchy, some information is retained on the device, while other information is not available on the device after migration.

The following information is retained on the client device:

  • The unique identifier (GUID), which associates a client with its information in the Configuration Manager database.

  • The advertisement or deployment history, which prevents clients from unnecessarily rerunning advertisements or deployments in the destination hierarchy.

The following information is not retained on the client device:

  • The files in the client cache. If the client requires these files to install software, the client downloads them again from the destination hierarchy.

  • Information from the source hierarchy about any advertisements or deployments that have not yet run. If you want the client to run the advertisements or deployments after it migrates, you must redeploy them to the client in the destination hierarchy.

  • Information about inventory. The client resends this information to its assigned site in the destination hierarchy after the client migrates, and the new client data has been generated.

  • Compliance data. The client resends this information to its assigned site in the destination hierarchy after the client migrates, and the new client data has been generated.

When a client migrates, information that is stored in the Configuration Manager client registry and file path is not retained. After migration, reapply these settings. Typical settings include the following:

  • Power schemes

  • Logging settings

  • Local policy settings

Additionally, you might have to reinstall some applications.

Planning for Handling Inventory and Compliance Data During Migration

Client inventory and compliance data is not saved when you migrate a client to the destination hierarchy. Instead, this information is recreated in the destination hierarchy when a client first sends its information to its assigned site. To help reduce the resulting network bandwidth requirements and server processing, consider migrating a small number of clients in phases rather than migrating a large number of clients at a single time.

Additionally, you cannot migrate customizations for hardware inventory from a source hierarchy. You must introduce these to the destination hierarchy independently from migration. For information about how to extend hardware inventory, see How to Extend Hardware Inventory in Configuration Manager.

See Also