Migrate from vRA 7 to CMP with OneFuse

Migration tools for OneFuse managed objects from VMware vRealize Automation 7x to CloudBolt CMP

23 minute read

The OneFuse Migration Tools vRealize Orchestrator Package provides examples for the user to “create” OneFuse Managed Objects via Brownfield ingest from vRealize Automation 7x VMs and apply necessary OneFuse Properties on CloudBolt’s VMs (to enable future deprovisioning from CMP+OneFuse). Once migrated, OneFuse Managed Objects will exist and the user has the option to flexibility to 1) destroy via API without deprovisioning or 2) destroy normally within the deployment in CloudBolt CMP, which then calls OneFuse to destroy and deprovision the resource.

The Migration Tools vRO Package is beneficial for those 1) currently utilizing the SovLabs Heritage Plug-in for vRealize Automation 7x to generate names, reserve IP Addresses and DNS records and more, and/or 2) if utilizing custom scripts to provision vRA7x VMs for names, reserving IP Addresses and DNS records and more, and 3) there is interest in finding an efficient way to migrate to OneFuse and CloudBolt CMP. The Migration Tools vRO Package contains sample workflows that can be used out-of-the-box or copied then modified to fulfill requirements. Check back here for updates to the Migration Tools vRO Package.

The following table depicts sample workflows for OneFuse Modules in the Migration Tools vRO Package:

OneFuse Module / Feature	Migration Tools vRO Package Minimum Version
Ansible Tower	2023.0.0 `Build 19639314`
DNS Module	2023.0.0 `Build 19639314`
IPAM Module	2023.0.0 `Build 19639314`
Microsoft Active Directory Module	2023.0.0 `Build 19639314`
Naming Module	2023.0.0 `Build 19639314`
ServiceNow CMDB Module	2023.0.0 `Build 19639314`

Prerequisites

OneFuse installed and setup:
OneFuse configured:
- DNS requires necessary Credentials, Endpoints and DNS Policies
- IPAM requires necessary Credentials, Endpoints and IPAM Policies
- Naming requires Sequences and Naming Policies
If combining OneFuse and CMP on the same appliance, version 2023.1.1 at minimum is required along with CloudBolt CMP licensed. If utilizing a separate appliance for CloudBolt CMP:
1. Getting started
2. Installation and setup
3. OneFuse XUI imported from the Content Library
The source vRealize Automation 7x installed and setup with OneFuse Endpoint:
1. Getting started
2. Installation and setup
  - While this source vRA 7x instance could be configured to use OneFuse, the purpose of this Prerequisite Step is to create the OneFuse Endpoint.

Download the migration tool vRealize Orchestrator workflow package

Access CloudBolt’s Download Article for CMP/OneFuse 2023.5.

The article will always contain the latest vRO Migration Package Download Link.

Go to https://support.cloudbolt.io/cloudbolt/s/article/cloudbolt-2023-5--1983840286--1
Download the OneFuse VMware vRO Migration Package.

Import the migration tool vRealize Orchestrator workflow package

For a new install and upgrades, perform the following to import the latest Migration Tool vRealize Orchestrator Workflow Package.

Log in to vRealize Orchestrator 7x.

The Migration Tools vRO Package needs to be imported to the source vRealize Orchestrator 7x.
Select Assets > Packages.
Select Import.
1. Select Browse.
2. Select the Migration Tool vRealize Orchestrator Workflow Package (.package) to upload.
3. Select Open.
4. Review the imported package information.
  
  You might be prompted to indicate that you trust the publisher certificate of the source vRealize Orchestrator instance before you can import the file.
5. Select Import.
Verify the OneFuse vRealize Orchestrator Workflow Package successfully imported:
- io.cloudbolt.onefuse.migration is listed in the list of Packages under Assets > Packages.
- The Build Number is found in the Description field of the vRO Package.

Run the Create CMP Migration Endpoint workflow

Specify the connection to the target CloudBolt CMP instance.

Log in to vRealize Orchestrator 7x.

The workflow needs to run on the source vRealize Orchestrator 7x.
Select Library > Workflows from the left menu.
Go to the following workflow via tree view: Workflows > OneFuse > Migration Tools > Configuration
Select the Workflow: Create CMP Migration Endpoint > select Run.
Fill out the form fields.
Select the [Run] button.
Verify the Workflow completed successfully.

Create CMP Migration Endpoint form fields

Field Label	Description
Common parameters
CMP Migration Host (FQDN or IP)	Enter the Target CMP Host in FQDN or IP Address format.
Connection Protocol	Select the appropriate protocol: HTTPS or HTTP.
Username	Username for OneFuse Service Account for the Target CMP.
Password	Password for user account.
Port	Enter the Port number for this Target CMP Migration Endpoint.
Ignore Certificate Warnings?	Check yes to silently accept the certificate.
Verify whether the target hostname matches the names stored inside the server’s X.509 certificate	Check yes if the target hostname matches the names stored inside the server’s X.509 certificate.
Proxy Settings
Use Proxy?	Check yes if using a Proxy.
Proxy Host FQDN / IP	(Shown when Use Proxy?* is `Yes`)* Enter the Proxy Host in Host in FQDN or IP Address format.
Proxy Port	(Shown when Use Proxy?* is `Yes`)* Enter the Port number for this Proxy Host.

Managing CMP Migration Endpoint(s)

When credentials and/or endpoints are updated, use the workflows below to update the CMP Migration Endpoint previously configured.

Only one CMP Migration Endpoint may exist at a given time.

To update the existing CMP Endpoint, run the workflow OneFuse > Migration Tools > Configuration > Update CMP Migration Endpoint.
To delete the existing CMP Endpoint, run the workflow OneFuse > Migration Tools > Configuration > Delete CMP Migration Endpoint.

Migrate existing resources to OneFuse managed objects

Ansible Tower

Migrate Ansible Tower Deployments from vRA 7x VM to create OneFuse Managed Ansible Tower Deployments. In addition, apply necessary OneFuse vRA Properties to the migrated CMP Resource(s) so that when the resource is destroyed from CMP, OneFuse will destroy the Ansible Tower Deployments.

Optionally, if there are any vRA Properties that identify and/or filter the VMs for particular Names, it will be helpful to have a list to reference when running the workflow below.

Log in to vRealize Orchestrator 7x.

The workflow needs to run on the source vRealize Orchestrator 7x.
Select Library > Workflows from the left menu.
Go to the following workflow via tree view: Workflows > OneFuse > Migration Tools > Ansible Tower > From vRA7 > To CMP
Select the Workflow: Migrate Ansible Tower from vRA7 to CMP+OneFuse > select Run.
Fill out the form fields.
Select the [Run] button.
Verify the Workflow completed successfully.

Migrate Ansible Tower from vRA7 to CMP+OneFuse

Field Label	Description
Endpoints
OneFuse Endpoint	Select the OneFuse Endpoint (created in prerequisite step 4, Installation and Setup).
Same OneFuse Endpoint name in CMP?	Select whether or not this OneFuse Endpoint Name is the same as the OneFuse Endpoint Name in the target CMP instance.
OneFuse Endpoint name in CMP	(Shown when Same OneFuse Endpoint name in CMP?* is `No`)* Enter the OneFuse Endpoint name in the target CMP instance.
vRA 7.x Tenant Name	Select from the dropdown the vRA 7 Tenant.
Policy and Config
OneFuse Policy Name to migrate to	Select the OneFuse Ansible Tower Policy Name to migrate the Deployments to from the dropdown.
Preferred order to select name to be migrated	Select the order of preference to migrate the name from the dropdown. - Hostname, virtualMachineName - It will look at the `Hostname` property first - virtualMachineName, Hostname - It will look at the `virtualMachineName` property first
Limit scope based on vRA7 Business Group	Choose whether or not to limit the migration to a specific vRA7 Business Group.
Business Group name	(Shown when Limit scope based on vRA7 Business Group* is `Yes`)* Select desired vRA7 Business Group Name.
Limit scope based on ALL vRA7 Properties - Number of Properties	Filter VMs based on ALL specified number of vRA7 Properties. (Migrate any Name on a VM, regardless of using SovLabs Heritage Plug-in for the module.) Select from the dropdown: - 0 - Do not Limit scope based on ALL - 1 - Limit scope based on 1 vRA Property - 2 - Limit scope based on 2 vRA Properties - 3 - Limit scope based on all 3 vRA Properties
Limit scope based on ANY vRA7 Properties - Number of Properties	Filter VMs based on ANY specified number of vRA7 Properties. (Migrate any Name on a VM, regardless of using SovLabs Heritage Plug-in for the module.) Select from the dropdown: - 0 - Do not Limit scope based on ANY - 2 - Limit scope based on matching at least one of the 2 vRA Properties - 3 - Limit scope based on matching at least one of the 3 vRA Properties
Settings
Allow Ingest of duplicates	Recommended to select No. In the event this workflow runs multiple times and this is Yes, it will create the OneFuse Managed Object (regardless if another with the same values exist) and overwrite the vRA Property with the latest Managed Object reference.
Dry run?	If Yes, this will not perform an actual migration. It will only provide logs for the actions this workflow would have perform. Select No to perform a migration.
Error handling	Select from the dropdown: - Roll back: Completely roll back all migration creation/vRA Properties injection - Skip failures and report: Will log the failure, continue with the migration and at the end, provide a summarized report via vRO Logs. (The following variables for a particular Workflow run captures the outputs: `managedObjectsPropString`, `ingestedManagedObjectsPropString`, `customPropertiesPropString`, `trackingIdPropString`, `resourceObjectsPropString` and `statusPropString`. Please note that more output properties may exist.)

DNS

Migrate DNS Reservations from vRA 7x to create OneFuse Managed DNS Records. In addition, applies necessary OneFuse vRA Properties to the migrated CMP Resource(s) so that when the resource is destroyed from CMP, OneFuse will destroy the DNS Record(s).

Customers using the SovLabs Heritage Plug-in for vRA7x and the DNS module did not have to apply the DNS Configuration name as a vRA Property. During the VM lifecycle, the SovLabs DNS module would match the domain and apply the proper DNS Configuration accordingly. Therefore, this migration workflow will solely rely on vRA Properties provided to filter vRA 7x VMs.

Optionally, if there are any vRA Properties that identify and/or filter the VMs for particular Domains (regardless of using SovLabs DNS Module or not), it will be helpful to have a list to reference when running the workflow below.

Log in to vRealize Orchestrator 7x.

The workflow needs to run on the source vRealize Orchestrator 7x.
Select Library > Workflows from the left menu.
Go to the following workflow via tree view: Workflows > OneFuse > Migration Tools > DNS > From vRA7 > To CMP
Select the Workflow: Migrate DNS Reservations from vRA7 to CMP+OneFuse > select Run.
Fill out the form fields.
Select the [Run] button.
Verify the Workflow completed successfully.

Migrate DNS Reservations from vRA7 to CMP+OneFuse

Field Label	Description
Endpoints
OneFuse Endpoint	Select the OneFuse Endpoint (created in prerequisite step 4, Installation and Setup).
Same OneFuse Endpoint name in CMP?	Select whether or not this OneFuse Endpoint Name is the same as the OneFuse Endpoint Name in the target CMP instance.
OneFuse Endpoint name in CMP	(Shown when Same OneFuse Endpoint name in CMP?* is `No`)* Enter the OneFuse Endpoint name in the target CMP instance.
vRA 7.x Tenant Name	Select from the dropdown the vRA 7 Tenant.
Policy and Config
OneFuse Policy Name to migrate to	Select the OneFuse DNS Policy Name to migrate the DNS record(s) to from the dropdown.
Domains for the Policy to register against	Enter the Domain(s) that the DNS record(s) are registered to (for example, example.com).
Validate NIC DNS Suffix against provided Domains	Choose whether or not to validate if the Domains match the NIC DNS Suffix.
Limit scope based on vRA7 Business Group	Choose whether or not to limit the migration to a specific vRA7 Business Group.
Business Group name	(Shown when Limit scope based on vRA7 Business Group* is `Yes`)* Select desired vRA7 Business Group Name.
Limit scope based on ALL vRA7 Properties - Number of Properties	Filter VMs based on ALL specified number of vRA7 Properties. (Migrate any DNS reservation on a VM, regardless of using SovLabs Heritage Plug-in for the module.) Select from the dropdown: - 0 - Do not Limit scope based on ALL - 1 - Limit scope based on 1 vRA Property - 2 - Limit scope based on 2 vRA Properties - 3 - Limit scope based on all 3 vRA Properties
Limit scope based on ANY vRA7 Properties - Number of Properties	Filter VMs based on ANY specified number of vRA7 Properties. (Migrate any DNS reservation on a VM, regardless of using SovLabs Heritage Plug-in for the module.) Select from the dropdown: - 0 - Do not Limit scope based on ANY - 2 - Limit scope based on matching at least one of the 2 vRA Properties - 3 - Limit scope based on matching at least one of the 3 vRA Properties
Settings
Disregard SovLabs Disable DNS Properties	If Yes, it will perform a migration even if the vRA 7x VM has the `SovLabs_DisableDNS` vRA Property. If No, it will skip the vRA 7x VM with the `SovLabs_DisableDNS` vRA Property.
Allow Ingest of duplicates	Recommended to select No. In the event this workflow runs multiple times and this is Yes, it will create the OneFuse Managed Object (regardless if another with the same values exist) and overwrite the vRA Property with the latest Managed Object reference.
Dry run?	If Yes, this will not perform an actual migration. It will only provide logs for the actions this workflow would have perform. Select No to perform a migration.
Error handling	Select from the dropdown: - Roll back: Completely roll back all migration creation/vRA Properties injection - Skip failures and report: Will log the failure, continue with the migration and at the end, provide a summarized report via vRO Logs. (The following variables for a particular Workflow run captures the outputs: `managedObjectsPropString`, `ingestedManagedObjectsPropString`, `customPropertiesPropString`, `trackingIdPropString`, `resourceObjectsPropString` and `statusPropString`. Please note that more output properties may exist.)

IPAM

Migrate IPAM Reservations from vRA 7x to create OneFuse Managed IP Addresses. In addition, applies necessary OneFuse vRA Properties to the migrated CMP Resource(s) so that when the resource is destroyed from CMP, OneFuse will destroy the IP Address(es).

This workflow currently only enables migration of VMs that used the SovLabs Heritage Plug-in IPAM module to reserve IP Addresses.

Log in to vRealize Orchestrator 7x.

The workflow needs to run on the source vRealize Orchestrator 7x.
Select Library > Workflows from the left menu.
Go to the following workflow via tree view: Workflows > OneFuse > Migration Tools > IPAM > From vRA7 > To CMP
Select the Workflow: Migrate IPAM Reservations from vRA7+SovLabs to CMP+OneFuse > select Run.
Fill out the form fields.
Select the [Run] button.
Verify the Workflow completed successfully.

Migrate IPAM Reservations from vRA7+SovLabs to CMP+OneFuse

Field Label	Description
Endpoints
OneFuse Endpoint	Select the OneFuse Endpoint (created in prerequisite step 4, Installation and Setup).
Same OneFuse Endpoint name in CMP?	Select whether or not this OneFuse Endpoint Name is the same as the OneFuse Endpoint Name in the target CMP instance.
OneFuse Endpoint name in CMP	(Shown when Same OneFuse Endpoint name in CMP?* is `No`)* Enter the OneFuse Endpoint name in the target CMP instance.
vRA 7.x Tenant Name	Select from the dropdown the vRA 7 Tenant.
Policies
Migrate all Policies to OneFuse Policies with matching names	Select No to specify the SovLabs IPAM Profile - this workflow have to run for each SovLabs IPAM Profile. Select Yes only if the corresponding OneFuse IPAM Policies have the same name as the SovLabs IPAM Profile. This will get and migrate all VMs that have the SovLabs IPAM Profiles for the vRA Tenant.
SovLabs Plug-in Policy Name to migrate from	Select from the dropdown the SovLabs IPAM Profile - this will perform migrations on all VMs with the specified SovLabs IPAM Profile.
OneFuse Policy Name to migrate to	Select the OneFuse IPAM Policy Name to migrate the IP Address(es) to.
Settings
Allow Ingest of duplicates	Recommended to select No. In the event this workflow runs multiple times and this is Yes, it will create the OneFuse Managed Object (regardless if another with the same values exist) and overwrite the vRA Property with the latest Managed Object reference.
Dry run?	If Yes, this will not perform an actual migration. It will only provide logs for the actions this workflow would have perform. Select No to perform a migration.
Error handling	Select from the dropdown: - Roll back: Completely roll back all migration creation/vRA Properties injection - Skip failures and report: Will log the failure, continue with the migration and at the end, provide a summarized report via vRO Logs. (The following variables for a particular Workflow run captures the outputs: `managedObjectsPropString`, `ingestedManagedObjectsPropString`, `customPropertiesPropString`, `trackingIdPropString`, `resourceObjectsPropString` and `statusPropString`. Please note that more output properties may exist.)

Microsoft Active Directory computer accounts

Migrate Microsoft Active Directory Computer Account from vRA 7x VM to create OneFuse Managed Computer Accounts. In addition, apply necessary OneFuse vRA Properties to the migrated CMP Resource(s) so that when the resource is destroyed from CMP, OneFuse will destroy the Computer Account(s).

Optionally, if there are any vRA Properties that identify and/or filter the VMs for particular Names, it will be helpful to have a list to reference when running the workflow below.

Log in to vRealize Orchestrator 7x.

The workflow needs to run on the source vRealize Orchestrator 7x.
Select Library > Workflows from the left menu.
Go to the following workflow via tree view: Workflows > OneFuse > Migration Tools > AD > From vRA7 > To CMP
Select the Workflow: Migrate AD from vRA7 to CMP+OneFuse > select Run.
Fill out the form fields.
Select the [Run] button.
Verify the Workflow completed successfully.

Migrate AD from vRA7 to CMP+OneFuse

Field Label	Description
Endpoints
OneFuse Endpoint	Select the OneFuse Endpoint (created in prerequisite step 4, Installation and Setup).
Same OneFuse Endpoint name in CMP?	Select whether or not this OneFuse Endpoint Name is the same as the OneFuse Endpoint Name in the target CMP instance.
OneFuse Endpoint name in CMP	(Shown when Same OneFuse Endpoint name in CMP?* is `No`)* Enter the OneFuse Endpoint name in the target CMP instance.
vRA 7.x Tenant Name	Select from the dropdown the vRA 7 Tenant.
Policy and Config
OneFuse Policy Name to migrate to	Select the OneFuse Microsoft Active Directory Policy Name to migrate the Computer Accounts to from the dropdown.
Preferred order to select name to be migrated	Select the order of preference to migrate the name from the dropdown. - Hostname, virtualMachineName - It will look at the `Hostname` property first - virtualMachineName, Hostname - It will look at the `virtualMachineName` property first
Limit scope based on vRA7 Business Group	Choose whether or not to limit the migration to a specific vRA7 Business Group.
Business Group name	(Shown when Limit scope based on vRA7 Business Group* is `Yes`)* Select desired vRA7 Business Group Name.
Limit scope based on ALL vRA7 Properties - Number of Properties	Filter VMs based on ALL specified number of vRA7 Properties. (Migrate any Name on a VM, regardless of using SovLabs Heritage Plug-in for the module.) Select from the dropdown: - 0 - Do not Limit scope based on ALL - 1 - Limit scope based on 1 vRA Property - 2 - Limit scope based on 2 vRA Properties - 3 - Limit scope based on all 3 vRA Properties
Limit scope based on ANY vRA7 Properties - Number of Properties	Filter VMs based on ANY specified number of vRA7 Properties. (Migrate any Name on a VM, regardless of using SovLabs Heritage Plug-in for the module.) Select from the dropdown: - 0 - Do not Limit scope based on ANY - 2 - Limit scope based on matching at least one of the 2 vRA Properties - 3 - Limit scope based on matching at least one of the 3 vRA Properties
Settings
Allow Ingest of duplicates	Recommended to select No. In the event this workflow runs multiple times and this is Yes, it will create the OneFuse Managed Object (regardless if another with the same values exist) and overwrite the vRA Property with the latest Managed Object reference.
Dry run?	If Yes, this will not perform an actual migration. It will only provide logs for the actions this workflow would have perform. Select No to perform a migration.
Error handling	Select from the dropdown: - Roll back: Completely roll back all migration creation/vRA Properties injection - Skip failures and report: Will log the failure, continue with the migration and at the end, provide a summarized report via vRO Logs. (The following variables for a particular Workflow run captures the outputs: `managedObjectsPropString`, `ingestedManagedObjectsPropString`, `customPropertiesPropString`, `trackingIdPropString`, `resourceObjectsPropString` and `statusPropString`. Please note that more output properties may exist.)

Names

Migrate Names from vRA 7x VM to create OneFuse Managed Names. In addition, apply necessary OneFuse vRA Properties to the migrated CMP Resource(s) so that when the resource is destroyed from CMP, OneFuse will destroy the Name(s).

Optionally, if there are any vRA Properties that identify and/or filter the VMs for particular Names, it will be helpful to have a list to reference when running the workflow below.

Log in to vRealize Orchestrator 7x.

The workflow needs to run on the source vRealize Orchestrator 7x.
Select Library > Workflows from the left menu.
Go to the following workflow via tree view: Workflows > OneFuse > Migration Tools > Naming > From vRA7 > To CMP
Select the Workflow: Migrate VM Names from vRA7 to CMP+OneFuse > select Run.
Fill out the form fields.
Select the [Run] button.
Verify the Workflow completed successfully.

Migrate VM Names from vRA7 to CMP+OneFuse

Field Label	Description
Endpoints
OneFuse Endpoint	Select the OneFuse Endpoint (created in prerequisite step 4, Installation and Setup).
Same OneFuse Endpoint name in CMP?	Select whether or not this OneFuse Endpoint Name is the same as the OneFuse Endpoint Name in the target CMP instance.
OneFuse Endpoint name in CMP	(Shown when Same OneFuse Endpoint name in CMP?* is `No`)* Enter the OneFuse Endpoint name in the target CMP instance.
vRA 7.x Tenant Name	Select from the dropdown the vRA 7 Tenant.
Policy and Config
OneFuse Policy Name to migrate to	Select the OneFuse Naming Policy Name to migrate the Names to from the dropdown.
Preferred order to select name to be migrated	Select the order of preference to migrate the name from the dropdown. - Hostname, virtualMachineName - It will look at the `Hostname` property first - virtualMachineName, Hostname - It will look at the `virtualMachineName` property first
Limit scope based on vRA7 Business Group	Choose whether or not to limit the migration to a specific vRA7 Business Group.
Business Group name	(Shown when Limit scope based on vRA7 Business Group* is `Yes`)* Select desired vRA7 Business Group Name.
Limit scope based on ALL vRA7 Properties - Number of Properties	Filter VMs based on ALL specified number of vRA7 Properties. (Migrate any Name on a VM, regardless of using SovLabs Heritage Plug-in for the module.) Select from the dropdown: - 0 - Do not Limit scope based on ALL - 1 - Limit scope based on 1 vRA Property - 2 - Limit scope based on 2 vRA Properties - 3 - Limit scope based on all 3 vRA Properties
Limit scope based on ANY vRA7 Properties - Number of Properties	Filter VMs based on ANY specified number of vRA7 Properties. (Migrate any Name on a VM, regardless of using SovLabs Heritage Plug-in for the module.) Select from the dropdown: - 0 - Do not Limit scope based on ANY - 2 - Limit scope based on matching at least one of the 2 vRA Properties - 3 - Limit scope based on matching at least one of the 3 vRA Properties
Settings
Allow Ingest of duplicates	Recommended to select No. In the event this workflow runs multiple times and this is Yes, it will create the OneFuse Managed Object (regardless if another with the same values exist) and overwrite the vRA Property with the latest Managed Object reference.
Dry run?	If Yes, this will not perform an actual migration. It will only provide logs for the actions this workflow would have perform. Select No to perform a migration.
Error handling	Select from the dropdown: - Roll back: Completely roll back all migration creation/vRA Properties injection - Skip failures and report: Will log the failure, continue with the migration and at the end, provide a summarized report via vRO Logs. (The following variables for a particular Workflow run captures the outputs: `managedObjectsPropString`, `ingestedManagedObjectsPropString`, `customPropertiesPropString`, `trackingIdPropString`, `resourceObjectsPropString` and `statusPropString`. Please note that more output properties may exist.)

ServiceNow CMDB deployments

Migrate ServiceNow CMDB Deployments from vRA 7x VM to create OneFuse Managed ServiceNow CMDB Deployments. In addition, apply necessary OneFuse vRA Properties to the migrated CMP Resource(s) so that when the resource is destroyed from CMP, OneFuse will destroy the ServiceNow CMDB Deployments(s).

Optionally, if there are any vRA Properties that identify and/or filter the VMs for particular ServiceNow CMDB Deployments, it will be helpful to have a list to reference when running the workflow below.

Log in to vRealize Orchestrator 7x.

The workflow needs to run on the source vRealize Orchestrator 7x.
Select Library > Workflows from the left menu.
Go to the following workflow via tree view: Workflows > OneFuse > Migration Tools > ServiceNow CMDB > From vRA7 > To CMP
Select the Workflow: Migrate ServiceNow CMDB Deployments from vRA7 to CMP+OneFuse > select Run.
Fill out the form fields.
Select the [Run] button.
Verify the Workflow completed successfully.

Migrate ServiceNow CMDB Deployments from vRA7 to CMP+OneFuse

Field Label	Description
Endpoints
OneFuse Endpoint	Select the OneFuse Endpoint (created in prerequisite step 4, Installation and Setup).
Same OneFuse Endpoint name in CMP?	Select whether or not this OneFuse Endpoint Name is the same as the OneFuse Endpoint Name in the target CMP instance.
OneFuse Endpoint name in CMP	(Shown when Same OneFuse Endpoint name in CMP?* is `No`)* Enter the OneFuse Endpoint name in the target CMP instance.
vRA 7.x Tenant Name	Select from the dropdown the vRA 7 Tenant.
Policy and Config
OneFuse Policy Name to migrate to	Select the OneFuse ServiceNow CMDB Policy Name to migrate the ServiceNow CMDB Deployments to from the dropdown.
Preferred order to select name to be migrated	Select the order of preference to migrate the name from the dropdown. - Hostname, virtualMachineName - It will look at the `Hostname` property first - virtualMachineName, Hostname - It will look at the `virtualMachineName` property first
Limit scope based on vRA7 Business Group	Choose whether or not to limit the migration to a specific vRA7 Business Group.
Business Group name	(Shown when Limit scope based on vRA7 Business Group* is `Yes`)* Select desired vRA7 Business Group Name.
Limit scope based on ALL vRA7 Properties - Number of Properties	Filter VMs based on ALL specified number of vRA7 Properties. (Migrate any Name on a VM, regardless of using SovLabs Heritage Plug-in for the module.) Select from the dropdown: - 0 - Do not Limit scope based on ALL - 1 - Limit scope based on 1 vRA Property - 2 - Limit scope based on 2 vRA Properties - 3 - Limit scope based on all 3 vRA Properties
Limit scope based on ANY vRA7 Properties - Number of Properties	Filter VMs based on ANY specified number of vRA7 Properties. (Migrate any Name on a VM, regardless of using SovLabs Heritage Plug-in for the module.) Select from the dropdown: - 0 - Do not Limit scope based on ANY - 2 - Limit scope based on matching at least one of the 2 vRA Properties - 3 - Limit scope based on matching at least one of the 3 vRA Properties
Settings
Allow Ingest of duplicates	Recommended to select No. In the event this workflow runs multiple times and this is Yes, it will create the OneFuse Managed Object (regardless if another with the same values exist) and overwrite the vRA Property with the latest Managed Object reference.
Dry run?	If Yes, this will not perform an actual migration. It will only provide logs for the actions this workflow would have perform. Select No to perform a migration.
Error handling	Select from the dropdown: - Roll back: Completely roll back all migration creation/vRA Properties injection - Skip failures and report: Will log the failure, continue with the migration and at the end, provide a summarized report via vRO Logs. (The following variables for a particular Workflow run captures the outputs: `managedObjectsPropString`, `ingestedManagedObjectsPropString`, `customPropertiesPropString`, `trackingIdPropString`, `resourceObjectsPropString` and `statusPropString`. Please note that more output properties may exist.)