IMPORTANT: Based on customer feedback, it is important that you have the right level of support from Gainsight to use this feature effectively.  If you are interested in leveraging Cross-Org in your implementation migration, please contact your Gainsight Project Manager or Gainsight CSM for more information.

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. To read about most frequently asked questions(FAQs) in Cross-org Migration, see Cross-org Migration FAQs.

Note: The Migration tool can be used to migrate Scorecards 2.0 configurations. For more information on migrating Scorecards 2.0, refer to Migrating Scorecards 2.0 using Cross-Org.

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. 

  1. Custom fields and objects created in Salesforce needs to be migrated using Salesforce change sets.  
  2. The source and target orgs need to be on the same version of Gainsight. 
  3. MDA must be enabled in source and target orgs. 

List of Supported Items

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

List of assets that can be migrated (click here to expand)
  1. Rules (Custom and Bionic Rules)
  2. Reports (reports built off of the scorecard fact object are not supported at this time)
  3. Success Plans (fields in Plan Info are not supported at this time)
  4. Playbooks
  5. Surveys   
  6. Dataspaces
  7. Powerlists
  8. Dashboard
  9. Email Templates (2.0 and 1.0) 
  10. Scorecards 2.0
List of items supported in MDA Schema step (click here to expand)
  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.
  5. Icons are not supported for migration.
  6. Only Standard and Custom columns are considered for migrations. 
  7. During the update, Index property is not copied. 
  8. During update, the primary property cannot be overridden or copied. 
  9. During update when the target collection has data already, the default value will not be changed. 
  10. During update when the target collection has data already, if target column has different maxLength property, the column will be ignored from the update. 
  11. Formula (or calculated) fields will not be updated. It will always be created as a new field.
  12. Support Bulk Insert for Schema and Meta. For more information, refer the Bulk Insert for Schema and Meta section in this article.
  13. Custom to Standard object migration - custom objects created in a source org can be migrated to a target org (standard object) using the cross-org migration tool.
    1. To enable this migration, this parameter needs to be set in the source and target org in the tenantMaster > configs property: "MIGRATOR_ALLOW_STANDARD_OBJECT_MIGRATION" : "true"
    2. If you have any schema related to the custom object (in source org), be sure to map it in the MDA Schema step to migrate it to the Target org. 
List of items supported/unsupported items in the Metadata step (click here to expand)
  1. Picklist -  For all Global, Account, and Relationship Level Configurations following are supported: 
    1. CTA Status (Alert Status) 
    2. CTA Priority (Alert Severity)
    3. CTA Snooze Reason (Relationship Activity)
    4. CTA Reason (Alert Reason)
    5. Customer Status
    6. Customer Stage 
    7. Adoption Measure
    8. Milestones
  2. GSMetaInfo - All Account & Relationship Level
    1. Objective Categories
    2. Success Plan Types 
    3. Task Type
    4. Scorecard Metric (Sc Metric)
    5. Due Date Source Type
    6. Due Date Skip Option
    7. Success Plan Status
    8. CTA Group Category
  3. CTA Types - All the Global, Account, and Relationship Type CTA Types gets migrated. 
  4. Scorecard Metric - Account level scorecard metrics are migrated. 
  5. Scoring Scheme Definition - Account level scoring scheme definitions are migrated. 
  6. Application Settings Definition - While migrating Application setting object, the following properties get migrated. 
    1. Cockpit Related Configuration Parameters 
      1. Cockpit Configuration (JBCXM__CockpitConfig__c) 
  7. GSRelationshipType - Relationship Attributes and Card View Configuration gets migrated. If you select any metadata related to a Relationship Type will also migrate the Relationship Type. For a Rel Type to get migrated you have to select at least one related metadata. 
  8. Scorecard Configuration 
    1. What We Migrate
      1. Account level scorecards (1.0) metrics and scorecard scheme definitions are migrated. 
      2. Scoring Scheme Mapping - Update the configuration related to whether Color/Number/Grading scheme is enabled. 
    2. What We Don’t Migrate
      1. Configuration option “Load Snapshot to Engagement every month” will not get updated. 
  9. Picklist/Multipicklist under Schema (Both Standard and Custom) data type. For more information, refer to the Dropdown Data Types section in this article. 
  10. URL data type
  11. Bulk Insert for Schema and Meta. For more information, refer to the Bulk Insert for Schema and Meta section in this article.
List of items supported in the Choose Assets step (click here to expand)

Rules

Custom Rules created on Data Spaces are not supported for migration. 

  1. SFDC Custom Rules
    1. SFDC rule will be migrated to target org. 
    2. All incomplete rules (with no setup/action exist) are ignored. 
    3. Rules with CTA Action: If a playbook is assigned in Setup Action step, that particular playbook will be automatically migrated.
  2. MDA Rules   
    1. Load to MDA action is supported.
    2. All the objects 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 object or field used in the rule must have the same lookup object and field in target org. 
    5. Lookup up to three-levels is supported. 
  3. Bionic Rules can be migrated. Load to Feature and Set Score (1.0) action type is not supported. If a rule contains this action it will not be migrated. 
  4. Rules having Set Score 2.0 as an Action Type can now be migrated.
  5. Migrate bucket details for Rules which have an S3 dataset. For more information, refer to the Migrate Rules with S3 Dataset section in this article. 

Reports

  1. MDA Reports
    1. Orgs must have Integration with HAPostgres. 
    2. MDA object and its fields get validated during migration. Migration happens only if MDA object is successfully validated. 
    3. Object validation include ObjectName, used Object fields(fieldName), dataType, and joins.
    4. Duplicate Reports of the same name will not be migrated (validation from Report API). 
  2. SFDC Reports    
    1. Orgs must have Integration with HAPostgres. 
    2. SFDC object and its fields get validated during migration. Migration happens only if SFDC object is successfully validated.
    3. Object validation include ObjectName, used Object fields(fieldName), dataType, and lookups
    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 chooses 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 opens successfully.
  3. Data Space Reports
    1. Reports of type Data Space, which are present in source and Target org can be migrated. 
    2. You can also migrate dataspace reports from source to target org directly if it is not present in target org. 
    3. Reports which can include five level join fields created in data space.
    4. If report includes a data space, it will also be migrated. 
  4. Picklist and Multi-picklist values are supported.
  5. MDA/SFDC/Data Space report, if a report with the similar name is already present in target org, it cannot be migrated. 
  6. An update in data space requires an update in the associated reports, otherwise, the migration will fail. 
  7. WhoID/WhatID and Record data types can be migrated. For more information, refer to the WhoID/WhatID Data Types and RecordID Datatype sections in this article. 

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 not 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 joins migration of the PL will fail. 

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.

Playbooks

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

Surveys

  1. Multilingual Surveys that include static resources (languages) are now migrated when you are migrating a Survey.
  2. Surveys in any stage are migrated to the draft stage in the target org. 

Procedure

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

  1. Navigate to Administration > Migration. The Migration window is displayed. 
  2. Select New Migration option from the ADD MIGRATION drop-down menu. The New Migration window is displayed.
    You can also select the Upload Change Set option, to upload a configuration file from the re-run job. 

Select New Migration.png

  1. Enter the following details in the New Migration window.
    • Migration Job Name: Enter a name for the Migration job.
    • Username: Enter the username of the target org.
    • Password: Enter the password of the target org.
    • (Optional) Security Token: Enter the security token of the target org.
    • Organization Type: Select either Production or Sandbox option, based on your requirement.
    • Click AUTHENTICATE. The Run Delta Process window is displayed. 
Note: You can also authenticate the target org using a token, for more information, see Cross-org Migration
Target Org authentication.png
  1. (Optional) Click RUN, to execute the Delta process. This process returns the difference in assets and other data between source and target orgs.
  2. Click CANCEL, to start configuring the migration process. The Assets section is displayed.
  3. Select an entity from the Select Entity Type drop down menu. All the assets related to selected entity type are displayed.

  4. Select the asset to be migrated, from the left pane. All the items related to that asset are displayed. Here, Bionic Rule is selected. 

  5. Select the check box for the items (here Bionic Rules) to be migrated.
    Note: The bionic rules which are already migrated are shown with a double tick mark (in green) symbol, against them. You must only select those rules which do not have this symbol (here S3 Dataset Rule).

  6. Click Continue. The Configurations section is displayed.

Selecting an asset.gif

  1. Select the Meta data to be migrated, in the Configuration section. (Here, Reporting Category is being selected and the Adoption Category is migrated). 
  2. Click CONTINUE. The Objects section is displayed.

Migration Configuration.gif

  1. Select the objects and fields to be migrated. (Since all objects and fields are already migrated during previous migrations, no object or field is selected).

fiield lookup still image.png

  1. Click CONTINUE. The Summary section is displayed.

Select Object and fields.gif

  1. Verify if all the items selected in the prior sections are included in the Summary section.
  2. (Optional) Click the Download or Print icons, to print or download the configuration, respectively.

Download, Print, and migrate.png

  1. Click MIGRATE. The Migrate window is displayed. 
    1. (Optional) Select the Test Run check box to perform a test/dummy migration. This process will not migrate any assets but will inform you if the migration would succeed or fail, if performed. the migration logs are same as in case of an actual migration. 

Test migrate.gif

  1. (Optional) Select the Send Copy of Migration Status Email check box. You can enter Email IDs of recipients to whom a migration status mail must be sent. By default, only the logged in user receives a mail on the status of the migration task.

send mail.gif

  1. Click MIGRATE, to start the migration process. If you have selected Test Run option in the previous step, only a test migration would be performed. 

Save and Exit Migration Task

If you wish to pause a Migration task before completing all the configurations, you can use the Save and Exit option. This option saves your configurations. When you return to the migration screen, you can resume the migration process.   

To save the migration task, you must click the newly introduced Save and Exit button. To resume a saved migration task, click the ellipsis menu for the required migration task, and select Continue.

save and exit.gif

You must re-enter target org credentials, to resume the migration task.

Run Delta Process

Admins can use this process before running a migration to compare what exists in the source org with what exists in the target org. The process will identify the schema, meta, and asset differences between the source and target orgs so users know what to migrate.

After initiating a migration, a pop-up window will appear asking users if they would like to initiate the Delta Process. A date will be displayed to let users know the last time the delta process was run.

Delta process window.png

You can also initiate a Delta Process by clicking the RUN DELTA PROCESS button at the bottom of the MDA Schema, Metadata, and Assets steps of the migration.

Delta process from migration screen.png

The process can be initiated during migration configuration, but it will remove all selections that have been made. A pop-up window will inform users of this before the Delta Process begins.

Snip20180206_29.png

A key at the bottom right of the migration screen defines these symbols.

  • Already Migrated.png Already Migrated: This element is exactly the same in the source org and the target org.
  • Partially Migrated.pngPartially Migrated: This element exists in the target org, but does not have the same fields. This icon is not applied to Assets, as Assets can not be partially migrated. They are either present in an org, or they are not.
  • Failed in last migration.pngFailed in last Migration: This element was selected for migration during previous migrations. However, the migration process for this element failed.
  • Selected in last migration.pngSelected in last Migration: This element was selected for migration during previous migrations. However, the migration process for this element could not be completed.

Note: It is important to note the Entity Type of MDA Schema when reviewing the results of the Delta Process. Specific entities will be marked Partially Migrated even if other entities are the same across the Target and Source orgs.

If neither icon is visible, then the element is not present in the target org and either needs to be mapped there or inserted as new.

Note: These icons will only be visible if the Delta Process has run. If the process did not run, then the icons will not be visible even if the elements are present in the target org.

A summary of all Completed and In Progress Delta Processes can be viewed by navigating to Administration > Migration. A migration can not be completed while the delta process is running.

Note: Currently there is a limitation where objects with calculated fields will migrate successfully, but will show as partially migrated through the Delta Process. The calculated fields within the object are not mapped during this process.

Re-run a Migration Job

Use the following procedure to re-run a migration job: 

  1. Select a migration job that is completed. 
  2. Click Re-run. The Migration screen appears.
  3. Enter a name for the migration task and the credentials of the target org, to which you intend to migrate and click Authenticate Target Org. The Assets section is displayed. 
  4. Select the required asset, which could not be migrated previously.

meta re run.png

Follow the steps mentioned in the Procedure section and complete the migration task. 

Run a migration job using a Changeset file

Use the following procedure to run a migration job using a changeset file: 

  1. After a migration job is complete, click Download Change Set. A file with .mig extension, is downloaded. 

Donwload change set.png

  1. Select Upload Change Set option from the ADD MIGRATION window. 

Upload change set.png

  1. Click BROWSE FILES and select the .mig extension file, in the Upload Change Set window.

Browse mig file.png

  1. After successful processing of the migration file, the Authenticate Screen is displayed.

Auth screen_2.png

Follow the steps mentioned in the Procedure section and complete the migration task. 

Authenticate Target Org using a Token 

A new way of authenticating the target org is introduced in Cross-org Migration tool. Using Token option, you can generate a token for the target org and use it to start the migration process. This way of authorizing the target org can be used if you are unable to authenticate using the conventional way (username and password). The org Id of target org is used to generate the token.

  1. Click GENERATE TOKEN. The Generate Token window is displayed.

Generate token.gif

  1. Type the target org Id and click Generate Token. The token will be generated.

    generate token_1.png
  2. Click Copy to copy the token to clipboard. You can now use this token and start the migration process.
  3. Click CLOSE.

Copy Token New.png

  1. Select the New Migration option from the ADD MIGRATION window.
  2. Select the Migration Token option.  
  3. Enter a name in the Migration Job Name field.
  4. Enter (Paste) the migration token in the Migration Token field. 
  5. Click Authenticate.

token based authentication.png

Data Types Supported post 5.19 Release

Dropdown Datatype 

New Dropdown Data Types can be migrated through X-Org Migration Tool: Picklist/Multipicklist under Schema (Both Standard and Custom), and URL Datatype can be migrated using the X-Org Tool.

Perform the following steps to migrate Single Select and Multi Select Picklist:

  1. Navigate to Administration > Data Management > Dropdown Lists > + CATEGORY.

    1. Create two categories in which one is Single Select and another one is Multi Select variant.

Single-Multi select picklists cateories.gif

  1. Click on the Single Select Picklist name in the Category column. The following page is displayed.
  2. Click +ITEM. The Add New Item dialog box appears.
  3. Add new items for each categories as shown below.

  1. Create a Schema (here the newly created object’s name is Single Select Picklist).
  2. Enter the Display Name. Field name will be generated automatically.

  3. Select the Dropdown Lists option from the Data type dropdown list.

  4. Select the category that you created (here, the newly created category Single Select Picklist will be listed in the dropdown as you start typing the name).

  1. Navigate to Administration > Operations > Migration.
  2. select New Migration, from the ADD MIGRATION drop-down menu. The New Migration window is displayed.
  3. Enter the following details in the New Migration window.
    • Migration Job Name: Enter a name for the Migration job.
    • Username: Enter the username of the target org.
    • Password: Enter the password of the target org.
    • (Optional) Security Token: Enter the security token of the target org.
    • Organization Type: Select either Production or Sandbox option, based on your requirement.
    • Click AUTHENTICATE. The Run Delta Process window is displayed.

Picklist migration.png

  1. Click CANCEL, to start configuring the migration process. The Assets section is displayed.
  2. Select the required assets and click CONTINUE. The Configurations window is displayed.

No asset selection.png

  1. Select the ACCOUNT option from the Select Entity Type drop-down menu.
  2. Navigate down and select the Picklist MDA check box. List of migrated and non migrated pick lists is displayed.
  3. Clear the check box for Already Migrated column.
  4. Click CONTINUE. The Objects section is displayed.

selecting picklist.gif

  1. Select the required objects and click CONTINUE. The Summary section is displayed.
  2. Ensure that the required items are displayed on the Migration screen.
  3. Click MIGRATE, to start the migration process. 

Picklist migration_summary.gif

Note: In the target org, navigate to Administration > Data Management > All Objects and Dropdown Lists, to see the Schema and Picklist that you migrated.

WhoID/WhatID Datatype

WhoID/WhatID data types can be migrated through X-Org Migration Tool: Cross Org can migrate reports built on top of MDA objects with WhoID/WhatID/Record ID data type as a field.

  1. Navigate to Administration > Data Management > All Objects > +OBJECT.
  2. Create WhoID schema (WhoID Datatype for Report on MDA) and add fields in it. Refer the following image.

  1. Navigate to Administration > Report Builder > +REPORT.
  2. Build a report based on WhoId Source object as shown in the following gif.
    Note: Add the fields that you created in Data management.

  1. Navigate to Administration > Migration.
  2. Select the New Migration option from the ADD MIGRATION drop-down menu. The New Migration window is displayed.
  3. Enter the following details in the New Migration window.
    • Migration Job Name: Enter a name for the Migration job.
    • Username: Enter the username of the target org.
    • Password: Enter the password of the target org.
    • (Optional) Security Token: Enter the security token of the target org.
    • Organization Type: Select either Production or Sandbox option, based on your requirement.
    • Click AUTHENTICATE. The Run Delta Process window is displayed.

who Id migration.png

  1. Click CANCEL, to start configuring the migration process. The Assets section is displayed.
  2. Navigate to Report on MDA objects section and select the report (here it is Report using WhoID).

Note: Remaining steps are the same as listed in above. In this case, you are migrating WhoID datatype to the target org.

WHOid report migration.gif

  1. Navigate to the target org > Administration > Data Management > All Objects, to see the Schema and fields that you migrated from the source org.

RecordID Datatype

Record ID data types can be migrated through X-Org Migration Tool: Cross Org can migrate Record ID data type. Both Source and target orgs must have the same Record type. This should be considered as a prerequisite in order to perform the migration.

  1. In the source org, navigate to Setup > Objects > Click on Customer Info Custom Object (Customer info) > Click New under Record Type section > Add record (REC2). Create same record in the target org as well in order to migrate.

  1. Navigate to the source org > Administration > Report Builder > +REPORT.
  2. Select Customer Info as source object.
  3. Add Account Name in Show me.
  4. In the filter section, select Record Type ID from the Select a Field dropdown list.
  5. Select options (REC1, REC2) or select Check all check box.
  6. Click save icon after naming the report (Name: RecordType in Report)

  1. Navigate to Administration > Migration.
  2. Select the New Migration option from the ADD MIGRATION drop-down menu. The New Migration window is displayed.
  3. Enter the following details in the New Migration window.
    • Migration Job Name: Enter a name for the Migration job.
    • Username: Enter the username of the target org.
    • Password: Enter the password of the target org.
    • (Optional) Security Token: Enter the security token of the target org.
    • Organization Type: Select either Production or Sandbox option, based on your requirement.
    • Click AUTHENTICATE. The Run Delta Process window is displayed.

Record migrate.png

  1. Click CANCEL, to start configuring the migration process. The Assets section is displayed.
  2. Navigate to Sfdc Reports section and select the report (here it is RecordType in Report).

migrate sfdc reports.gif

Note: Remaining steps are the same as listed in above. In this case, you are migrating RecordID datatype to the target org.

Bulk Insert for Schema and Meta

You can migrate multiple or all schema and meta using X-Org migration tool. When Bulk insert is used for migrating Schema/Meta:

  1. Navigate to Administration > Migration.
  2. Select the New Migration option from the ADD MIGRATION drop-down menu. The New Migration window is displayed.
  3. Enter the following details in the New Migration window.
    • Migration Job Name: Enter a name for the Migration job.
    • Username: Enter the username of the target org.
    • Password: Enter the password of the target org.
    • (Optional) Security Token: Enter the security token of the target org.
    • Organization Type: Select either Production or Sandbox option, based on your requirement.
    • Click AUTHENTICATE. The Run Delta Process window is displayed. 
    • Click Cancel. The Assets window is displayed.
  4. Select all the assets, configurations, Objects and click migrate. Refer the image below.

Bulk migrate.gif

Migrate Rules with S3 Dataset

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

  • Only the rule was migrated successfully; the associated S3 bucket was not migrated.
  • The S3 Bucket field on the S3 file configuration section showed None and was disabled. This phenomenon occured irrespective of whether a Gainsight Managed bucket or custom bucket was used in the rule.

However, now when you a 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. You can view this asset on the Assets page of the Migration process screen.
  • A corresponding bucket with the same name as in 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.