Once connected, policy and agent information is retrieved from both VSS and VIPRE Cloud. The migrator compares policies between VSS and VIPRE Cloud to determine if there is a policy overlap.

The Migrator checks if a selected policy exists in VIPRE Cloud. If so, it skips policy and exclusion conversion – and moves on to the agent conversion process. If the policy does not exist in VIPRE Cloud, the Migrator:
 

• Converts VSS policies to VIPRE Cloud format
• Retrieves exclusion groups from VIPRE Cloud
• Applies those exclusion groups to the selected policies
• Creates additional exclusion groups in VIPRE Cloud as needed
• Copies updated VSS policies to VIPRE Cloud
• Assigns exclusion groups to policies

If a failure occurs during any step, the corresponding policy is marked as failed in the Migrator and skipped in the steps that follow. The Finish screen provides a list of failed policies if any exist.

For each policy, settings are mapped one-to-one between the VSS version and the VIPRE Cloud version. Due to differences between environments, some policy settings may not exist on either side. The bullets below describe the actions taken in these situations.

• VSS policy only: If a setting exists only in the VSS policy, it is ignored for migration to VIPRE Cloud.
• VIPRE Cloud policy only: If a setting exists only in VIPRE Cloud, it is defaulted to disabled/allowed. This can occur when migrating from older VSS versions which can lack some policy settings related to features introduced in newer releases.
• Both VSS and VIPRE Cloud: If a setting exists in both VSS and VIPRE Cloud, but is not exposed in the VIPRE Cloud UI, or is overwritten by VIPRE Cloud when being distributed to agents, that setting is given a default value that matches the normal VIPRE Cloud default.

Exclusions are converted by considering all exclusions associated with selected policies. The conversion is a multiple-pass operation intended to keep groups simple while minimizing the number of groups created in VIPRE Cloud. The process is outlined below. 

• Check for matching exclusions: Every exclusion in every selected policy is compared with the current VIPRE Cloud site scope exclusions. Matches are noted. Every existing VIPRE Cloud policy scope exclusion group is compared with each policy. If there is a complete match of the group, it is applied to the corresponding exclusions in that policy.
• Create temporary groups: A new exclusion group is created in memory for each policy that contains at least one exclusion without an existing VIPRE Cloud group associated with it. The new group is named the same as the policy, with an additional suffix as necessary to ensure it is unique in VIPRE Cloud. If a congruent group was already created (with the same collection of exclusions), it is used in favor of creating a copy. The new groups created in memory are compared with the selected policies and applied to those that match.
• Check for redundancy: Starting with the largest first, each new group is checked to see if it is redundant. If all the exclusions the group covers are already covered by other groups, the group is unassigned and discarded. Discarded groups are not added to VIPRE Cloud. This ensures we don't add more groups than necessary. A final pass is made, this time smallest to largest, to remove any redundant assignments. This ensures each policy has as few groups as possible assigned to it.
• Add and link new groups: Once the new groups have been created and assigned in memory, they are added to VIPRE Cloud. Policies are then copied to VIPRE Cloud if all the exclusion groups assigned to that policy were successfully added to VIPRE Cloud. Finally, the links between exclusion groups and policies are persisted in VIPRE Cloud.

Note: Exclusions are set up differently in VIPRE Cloud from VSS. If you are not yet familiar with how VIPRE Cloud differs, read these articles to learn about exclusions: ESC - Exclusions | EDR - Exclusions

The agent selection screen displays VSS policies and the agents that belong to those policies. Because of this, it only shows policies that have agents currently assigned to them. Policies with no active agents will not be listed; these 'empty' policies must be migrated using the policies migration function of the Migrator if you plan to use these policies in VIPRE Cloud.

When agents are moved from VSS to VIPRE Cloud, they will no longer show as protected in the VSS console. Therefore, by choosing to migrate agents from your VSS, you are, in effect indicating that you have no intention of deploying any new agents from that VSS.
 

On an agent-by-agent basis, the Migrator checks if the agent's policy exists in VIPRE Cloud. If it does not, it migrates the policy first. Once the policy and exclusions are in place, the Migrator proceeds to the agent migration.
 

1. Connect to agent - The Migrator connects to the VSS agent. It attempts to connect using both the credentials provided by the user and any pre-configured deployment credentials previously stored in the VSS
2. Cloud agent MSI transferred to agent - The Migrator pushes the VIPRE Cloud agent MSI to the agent
3. Installation / Upgrade - Instead of performing a VSS agent update, the installer tells the agent to upgrade to VIPRE Cloud, making it a Cloud agent
4. Configuration - The Migrator updates the new Cloud agent configuration so it can connect to the VIPRE Cloud console
5. Removal of VSS agent - The agent is removed from the catalog in VSS, and Unprotected Computer Discovery is turned off for the site. This avoids a situation where VSS could attempt to deploy VIPRE Server agents to Endpoint Cloud agents if it doesn't recognize them as protected

Once all agents are processed, the Migrator displays a summary screen with the successfully copied agents. If any agents did not succeed, they will also be listed here with details as to why.