Commonly Asked Questions

What Core Components are Migrated by the Migration Tool?

•Agent policies

•Background tasks

•Certificates

•Credentials

•Custom patch XML files

•Custom PowerShell scripts that have been imported into the database

•Database (local only)

•Distribution servers (remote only)

•Files referenced by the Machine Group link to file feature

•Groups (machine, patch, product levels)

•License activation in a non-proxied online environment

•Global and user settings defined on the Tools > Options dialog

•Patch store if contained on a local drive (up to 10 GB of data and data that is not more than 90 days old)

•Results (scan results, deployment results, etc.)

•Templates

•Some user-specific options:

•Notifications & Warnings: Display the file size confirmation dialog before downloading

•Scans: Default Patch Scan Template, Use only the browse list, Use replacement patches

•Deployment: Default Deployment Template

What is Not Migrated by the Migration Tool?

See the section titled Post-Migration Tasks for a detailed explanation on how to manually manage the items that are not migrated by the tool.

•An agent running on the local console

•Data rollup configuration

•Share information for a distribution server that resides on the local console

•Proxy configurations

•Patch store data beyond the 10 GB limit or older than 90 days

•ITScript run files (the files that contain output information related to the execution of a script)

•Scheduled deployments

•Any user-specific option not identified in the What Core Components are Migrated list

When Should You Perform the Migration?

Soon after the completion of your regularly scheduled patch cycle to give yourself time to complete the migration.

How Long Will it Take to Perform the Migration?

•Simple configurations can be migrated in as little as 60 minutes

•Advanced configurations may require a few days of lead time to prepare for the migration and a few hours or days after the migration to perform system verification steps

Who Should Perform the Migration?

•Any administrator with a Security Controls account can perform the core backup and restore. Account data for the administrator currently logged on to the console machine is included in the core backup.

•Each additional administrator with a Security Controls user account must perform a separate User backup and restore.

You cannot restore multiple users under the same logged in account, and you cannot restore a user using a different account.

I Use a Remote Database, How is That Affected?

The remote database will not be moved but the connections to the remote database will be restored during the core component restoration process. You will restore your user account data using the normal process.

How Long Should I Maintain My Old Console?

•If you are not using agents, you can retire your old console as soon as the migration to the new console is complete.

•If you are using agents, you should continue to run the old console in parallel until all of your agents have checked in with the new console. See the section titled Before You Begin for additional information.