In Administration > Migration, Gainsight offers a new tool to migrate your Custom Object's schema, Reports, Rules, Playbook assets, data spaces, power lists, and reports from a source org to a target org. For example, 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.

With the May 5.6 release, Gainsight offers two new options in Migration, Re-run and Changeset File. 

  • Rerun migration jobs for different orgs: Admins can now re-run a migration job with the pre-selected configuration (selection of schema, metadata, and assets) to a different org. For example, if you have run a migration job from Org A to Org B, and wish to perform migration from Org A to Org C, you can use the re-run feature to perform the migration. In large enterprise implementations of Gainsight, Customers often perform multiple migrations from same source org to different target orgs with similar items. However, it is very difficult to remember the same items of migration. Rerun is a feature that will help you to solve this problem. A Re-run job remembers the items migrated in first migration and you can repeat that migration to different target org. 
Limitations  (click here to expand)
  1. Only Insert as new records will be considered for a re-run. 
  2. During a re-run, if the migrator identifies a record as auto-mapped in the current source/target org and the record is set to Insert As new in the job, the record will be ignored.
  • Download a changeset file when a migration job is complete: The changeset file contains the information of schema, metadata, and assets selected during a migration job. Only the records which are inserted as new in the target org will be captured in the changeset file. If you want to perform migration to a different org with the same schema, metadata, and assets, you can directly upload the changeset file and perform the migration. For example, if you have run a migration job from Org A to Org B, and wish to migrate the new records from Org B to Org C, you can use the changeset file and start the migration. In Administration > Migration screen, a new option By Uploading Config is introduced for this purpose.
Use Cases (click here to expand)
  1. In large enterprise implementation/change management, Customers often do multiple practice migrations before deploying to production and different teams are responsible for these deployments.  These teams need to hand-off from one team to another, in order to make this simple a changeset file is made available to the customer which will have the pre-selected configuration for Migration.
  2. The change set file can be downloaded after the migration is completed. 
  3. The items selected previously in each step will be shown with an orange dot. 
Limitations (click here to expand)
  1. Only successfully migrated items will be added to the changeset file.  
  2. For MDA Schema and Metadata Selection steps only “Insert as new” records are added to the changeset file. 
  3. Item update scenarios are ignored in the changeset file. 

Prerequisites

  1. In order to start the migration, oAuth user of the source and target org must have Gainsight Administration (Gainsight_Admin) permission set. 
  2. Custom fields and objects created in Salesforce needs to be migrated using Salesforce change sets.  
  3. The source and target orgs need to be on the same version of Gainsight.  MDA must be enabled in source and target orgs. 

Limitations 

Click on the following links to view the limitations in Migration. 

Limitations in MDA Schema step
  1. Only Redshift Custom Collections are migrated. 
  2. Lookup properties are not migrated and lookup fields are ignored. 
  3. Update keys configured are not migrated. 
  4. During migration, field display names will not be changed, but field name will be changed. 
  5. Only Custom columns are considered for migrations. 
  6. During the update, Index property is not copied. 
  7. During the update, the primary property cannot be overridden or copied. 
  8. During update with data, the default value will not be changed. 
  9. During update with data, if target column has different maxLength property, the column will be ignored from the update. 
  10. Formula (or calculated) fields will not be updated. It will always be created as a new field.
Limitations in the Metadata Selection & Mapping step
  1. Picklist 
    1. What We Migrate
      1. Below Account and Relationship Level Configurations 
      2. Customer Stage 
      3. Milestone Name 
      4. CTA Reason 
      5. CTA Snooze Reason 
      6. CTA Priority 
      7. CTA Status 
      8. Usage Data Measures 
      9. LRM Different Booking Types 
    2. What We Don’t Migrate
      1. ScoreCard Measures - They will be filtered out 
  2. GSMetaInfo - All Account & Relationship Level “Objective Categories” and “Success Plan Types” of Success Plan configurations will get migrated. 
  3. GSRelationshipType - Relationship Attributes and Card View Configuration get migrated. 
  4. CTA Types - All the account related CTA Types gets migrated. All the CTA Types related to the relationship are filtered out. 
  5. Application Settings Definition - While migrating Application setting object, the below properties will get migrated from the same. 
    1. Cockpit Related Configuration Parameters 
      1. Cockpit Configuration (JBCXM__CockpitConfig__c) 
      2. CTA Association Metadata (JBCXM__CTA_Association_Metadata__c) 
      3. SFTask Associated (JBCXM__SFTaskAssociated__c) 
      4. Task Fields (JBCXM__TaskFields__c) 
    2. Case Object Related Configuration Parameters 
      1. CaseAccountField (JBCXM__CaseAccountField__c)
      2. CaseObjectName (JBCXM__CaseObjectName__c) 
  6. Engagement/Adoption Related Configuration Parameters 
    1. Adoption Aggregation Columns (JBCXM__AdoptionAggregationColumns__c) 
    2. Adoption Aggregation Type (JBCXM__AdoptionAggregationType__c) 
    3. Adoption Granularity (JBCXM__AdoptionGranularity__c) 
    4. Adoption Measure Column Map (JBCXM__AdoptionMeasureColMap__c) 
    5. Uses week end date as name of week (JBCXM__UsesEndDateAsWeekName__c) 
    6. Week Starts On (JBCXM__WeekStartsOn__c) 
    7. LicensedUser Not In Adoption Graph (JBCXM__LicensedUserNotInAdoptionGraph__c) 
    8. LicensedUser Not In Adoption Grid (JBCXM__LicensedUserNotInAdoptionGrid__c) 
  7. Other Parameters 
    1. Application Labels (JBCXM__ApplicationLabels__c) 
    2. PageSize (JBCXM__PageSize__c) 
    3. Revenue Band Config (JBCXM__RevenueBand__c) 
    4. Transaction Associated (JBCXM__TransactionAssociated__c) 
  8. Scorecard Configuration 
    1. What We Migrate
      1. Enable Scorecard 
      2. Enable Customer Level Rollup 
      3. Enable history tracking 
    2. What We Don’t Migrate
      1. Configuration option “Load Snapshot to Engagement every month” will not get updated. 
    3. Scoring Scheme - Update the configuration related to whether Color/Number/Grading scheme is enabled. 
    4. Scoring Scheme Definition - Update the Grades, ranges, labels related to applied Grading scheme. 
    5. Scorecard Metric - Create all new custom measures and related groups.
Limitations in the Choose Assets step. 

Rules

  1. SFDC Rules
    1. SFDC report will be migrated to target org. 
    2. All incomplete rules (with no setup/action exist) are ignored. 
    3. Relationship rules with “Create CTA” action are supported
    4. All rules containing non-supported actions, for example, other than LoadToUsage, LoadToCustomers, Create CTA, SetScore, LoadToMilestones, LoadToSfdc, LoadToRelationship are ignored.
    5. Rules with CTA Action: If a playbook is assigned in Setup Action step, that particular playbook also needs to be migrated along with rule. Otherwise, the rule will fail irrespective of the playbook available in target org already or not. Default owner needs to be set after the migration.
  2. MDA Rules   
    1. Load to MDA action is supported.
    2. All the collections used must exist in the target org with the same name.
    3. All the fields used in the rule must exist in target org with the exact field name and type.
    4. Any lookup collection or field used in the rule must have the same lookup collection and field in target org.
    5. Migration can fail in rule with Join SFDC mapping is with Accountid


Reports

  1. MDA Reports
    1. MDA object and its fields get validated during migration. Migration happens only if MDA object is successfully validated.
    2. Object validation include ObjectName, used Object fields(fieldName), dataType, and joins.
    3. Orgs must have Integration with HAPostgres. 
    4. Duplicate Reports of the same name will not be migrated (validation from Report API). 
  2. SFDC Reports    
    1. SFDC object and its fields get validated during migration. Migration happens only if SFDC object is successfully validated.
    2. Object validation include ObjectName, used Object fields(fieldName), dataType, and lookups
    3. Integration with HAPostgeS.
    4. Dataspace reports are supported. 
    5. Migration happens only if object validation is successful.
    6. Owner field information is removed if there are any.
    7. The "Created By ID" when the user choose from the drop-down in source org, after migration UI throws a popup saying -- ID does not exist, remove or update filter. However, migrated report open successfully.
  3. Data Space Reports
    1. Reports of type Data Space, which are present in source and Target org can be migrated
    2. Reports which can include five level join fields created in data space

Powerlist

  1. Salesforce, MDA, and Dataspace powerlist is supported.
  2. Schedule information isn’t passed along with migration.
  3. For Data space powerlist, if the dataspace is present in target org or if it is part of the migration process then the data space will be migrated along with the Powerlist.
  4. Relationship Type Powerlist isn't supported yet for Migration.
  5. Account lookup holder cannot contain a field with join. In this case, Migration can fail. If we have an accountid mapping and having joins in recipient fields of Powerlist of minimum two-level join

Dashboard

  1. The dashboard is supported in migration.
  2. All the dependent reports are also fetched and migrated along with dashboard. 
  3. If MDA report is already present, then it will be Verified in target org. 
  4. MDA, SFDC, Dataspace Reports are supported. Gainsight also supports Widgets of SFDC type in Dashboard. 
  5. If any report fails, the associated dashboard migration fails.

Data Space

  1. Data Space on SFDC objects is supported in migration.
  2. All the dependent reports also fetched and migrated along with dashboard.
  3. Unique name constraint applied, so duplicate data space (same name) cannot be migrated.

Reports

  1. All types of Reports are supported in Migration.Support of SFDC, MDA, and Data space.
  2. Picklist values in filters are not supported.
  3. MDA report, with a name already present in target org, cannot be migrated.
  4. An update is data space requires an update in the associated reports as well, otherwise, the migration can fail. 

Playbooks

  1. All type of playbooks are supported (Account + Relationship)
  2. Playbooks get migrated along with the tasks if all the dependencies are met.

Procedure

To migrate assets from a source org to a target org:

  1. Navigate to Administration > Migration.
  2. Click + MIGRATION > New. You can either select New (new migration) or By Uploading Config (uploading a configuration file from re-run job).
  1. Under Authenticate, enter the details of the target org:
    • Username: The username of the target org.
    • Password: The password of the target org.
    • (Optional) Security Token: The security token of the target org.
    • Organization Type: Select Production or Sandbox based on your requirement.
  1. Click AUTHENTICATE TARGET ORG. The MDA Schema screen appears. While migrating assets to a target org, you can also migrate the schema of custom objects or fields in an object. Alternatively, you can skip the schema migration step using SKIP & NEXT button.  

  1. In the MDA Schema screen, select a collection type. The list of custom object's schema appears in the left-pane. 
  2. In the Select a target object list, select an object to which you intend to migrate the schema. Once you select the target object, the list of Source Fields and Target Fields appear on the page. 
    1. Fields of the same datatype will be matched automatically. 
    2. If any field is unmapped, you can either insert the schema as a new row or replace the existing schema. Select an option from the drop-down in this case. 

Note: Formula fields have to be mapped manually if the mapping did not happen automatically. If the formula field has any dependent fields, the dependent fields also have to be mapped manually. 

  1. Click NEXT. The Meta Data Selection & Mapping screen appears. Metadata related to Reports, Playbooks, and Rules is displayed in this screen.

 

  1. In the Metadata Selection & Mapping screen, select an Entity Type. Once you select an option, the metadata associated with the assets appear. 
  2. To start mapping the fields, select a metadata item from the left pane. Data in the Source Value and Target Value columns appear. 
  3. After selecting an item, you can update/replace the metadata of the target org in this screen. You can perform either of the following actions:
    • If values are equal: If the metadata values of the source org and target org are equal, the values will be mapped automatically. In this case, you can also update the metadata of fields associated with the target value. 

 

  • If values are not equal(Insert new record): If the metadata values of the source org and target org are not equal, you can either insert the source value as a new record in target org or replace the existing value (using Insert as New option under the Target Value column).  
  • If values are not equal(replace existing record): If you want to replace the target value, select the target value from the drop-down. While replacing the target value you can also replace the metadata of associated fields. Select the check box under UPDATE ASSOCIATED FIELDS column. 
  1. After updating/replacing the metadata, click NEXT. The Choose Assets screen appears. 

  1. In the Choose Assets screen, select an asset from the list. You can select Playbooks, Rules, Reports, Data Spaces, Dashboards, and Power Lists.  
  1. Select the required assets and click NEXT. The Migrate screen appears.
  2. In the Migrate screen, provide a job name and review the list of MDA Schema, Configurations, and Assets to be migrated.
  1. Click MIGRATE. The migration process starts, and once it’s completed you will receive an execution report via email.
  2. Click the job name to see the execution log and job status.
 
  1. You can view the migration log in the Execution Log section. You can also Re-run the migration job or download the changeset file for further use.