X-Org Migration

Overview

X-Org helps you to migrate configuration and assets from source org to target org. For example, you can migrate a custom object's schema, reports, rules, and playbook assets from a source org to a target org. To access this feature navigate to the Administration > General > X-Org.

Business use case: If you have built and tested rules in your sandbox org, you may want to migrate them to your production org. This feature saves admins valuable time and is enabled within your org by default.

Prerequisites: You must be a Super Admin in order to complete a migration.

Supported Modules and Assets for Dependency Resolution

In order to streamline operations in Gainsight, businesses need to efficiently manage dependencies between various objects and components such as rules, playbooks, surveys, templates, reports, dashboards, and so on.  These components and objects may have dependencies on each other. For example, a rule may depend on a specific playbook or template, or a dashboard may depend on certain reports or data sources.

Dependency resolution is used to identify and display all the dependencies of an asset automatically and ensure that they are migrated to the target tenant. 

IMPORTANT: When an asset is selected for migration, all of its dependencies are also selected automatically. Admins cannot deselect the list of dependencies.

Following is a list of modules in X-Org for that are either supported or not supported for dependency resolution

Supported Modules and Assets for Conflict Resolution

The Conflict Resolution feature in X-Org simplifies the migration process of assets between tenants. It automatically identifies and resolves any duplicate uniqueness ID at the target tenant without requiring admin intervention. This feature ensures that the migration process does not fail due to duplicate IDs.

The resolution is pre-configured for each module and is derived based on the following configuration:

• Update Configuration:  Overwrites the duplicate asset at the target tenant.
• Duplicate Configuration: Creates a copy of a duplicate asset at the target tenant.
• Skip Configuration: Skips migrating the duplicate asset at the target tenant.

The following are the supported modules in X-Org for Conflict Resolution:

• Cockpit/ Success Plan
• Journey Orchestrator
• Scorecards 
• Timeline 
• CX Center
• Data Management 
• Rules
• Layouts
• Renewal Center
• CSQL
• Adoption Explorer
• Data Designer
• Connectors

Setup Migration

To migrate assets from a source org to a target org, perform the following steps:

• Create a Connection Request
• Accept a Connection Request
• Create and Migrate a Bundle

Options in Connected Tenants Tab

Once the connection is accepted in the target org, you will see the connection details under the All Tenants section. The following details are displayed in this section:

• Tenant Name: Displays the name of the target org.
• Tenant ID: Displays the ID of the target org.
• Tenant Type: Displays the tenant type of the connection:
  • Source: The current org is a source org from where the assets need to be migrated to target org.
  • Target: The current org is a target org which receives the assets from the source org.
• Expiration Date: Displays the expiry date of the connection.
• Actions: It contains the following options based on the Tenant type:
  • Edit Access: (Only applicable to target org) You can edit the connection to update the expiry date.
  • Revoke Access: (Only applicable to target org) You can end the access source org’s access.
  • Delete: Deletes the connection between the two orgs.

Options in Bundles Tab

After a bundle is created, you can find the following options in the Bundles tab:

• View Bundle Content: Displays the assets of the bundle. You can also perform the following activities:
  • Edit: You can modify the bundle’s basic information and assets.
  • Prepare for Migration: You can directly migrate the bundle to the target org.
• Edit Bundle Content: Modify the bundle’s basic information and assets.
• Refresh Bundle: Refresh the bundle to update the assets information.
• Migrate Bundle: Copies the bundles to the target org.
• Delete Bundle: Deletes the bundles permanently from the respective org.

Options in Migration Tab

In the Migration tab, you can find the following options:

• Filter Migrated Bundles: Displays the migrated bundles as per the following options:
  • All, Inbound, or Outbound
  • All, Failure, In Progress, Partial Success, Pending, or Success
• Refresh: Refreshes the migration bundle list.
• Search: Helps to find the specific bundle by its name.

• Context Menu of the Bundle: The three-vertical dots menu of a Bundle contains the following options:
  • View Migration Detail: Displays the details of the migrated Bundle like name, migration type, target tenant ID, target tenant name, migration date and assets. You can also perform the following activities:
    • Download Logs: You can download a csv file containing the details of the migration.
    • Prepare for Migration: You can directly migrate the Bundle to the target org.
  • View Bundle Content: (Only applicable to Source org) Displays the assets of the Bundle. You can also perform the following activities:
    • Edit: You can modify the Bundle’s basic information and assets.
    • Prepare for Migration: Migrate the bundle directly to the target org.
  • Download Logs: Downloads a CSV file containing the details of the migration.

Migrate Rules with S3 Dataset

If you migrate a Rule with an S3 dataset task, the bucket details are also migrated successfully. When you migrate a Rule with an S3 dataset:

• The rule and the associated S3 bucket (Gainsight Managed or Custom) are successfully migrated.
• The bucket associated with an S3 dataset task is migrated as an independent asset.
• A corresponding bucket with the same name as provided in the source org is created in the target org. However, if the target org already has a bucket with the same name as in the source org, a new bucket will not be created.
• When a new bucket is created in the target org, the associated Access Key and Security Token are not copied from the source org.
• You must go to the Connectors 2.0 page and update the Access Key and Security Token for the bucket which was created due to migration.