Guidelines for migrating assets

• •To import assets related to other services, ensure that you import them without any MDM SaaS assets.
• •To import and export the asset types, such as authorization configuration, you need administrator privileges.
For example, when a user with the Admin role migrates assets to a target organization for the first time, the user can migrate all the assets, including the authorization and business event assets. When a user with the Designer or MDM Designer role migrates assets to a target organization for the first time, the user can migrate all the assets except authorization and business event assets. A user with the Admin role can then migrate the authorization asset first and then the business event assets.
• •After you migrate an asset, if you update the asset in the source organization, you must export and import the modified asset to the target organization. Ensure that you don't modify the assets manually in the target organization.
• •The user role that updates the assets must migrate the assets.
For example, if a user with the MDM Designer role updates an asset in a source organization, the same user must migrate the asset to a target organization. Otherwise, the migration fails.
• •Ensure that you create connections in a target organization before you migrate taskflows to the target organization.
• •Before you migrate assets to a target organization, ensure that you don't set any permission to assets, folders, or projects.
• •During migration, the licenses aren't verified. Ensure that you migrate the assets that are licensed in the target organization.
• •When you export a business entity, the assets related to the rule associations for DaaS real-time address verification and data enrichment aren't included in the exported file. To export all the assets related to these rule associations, export the objective group assets separately.
• •When you migrate a data enhancement rule that uses an Application Integration process, ensure that the value of the Process Name property in the rule matches the API name of the process.
Note: When you create a process by copying an existing process, Application Integration adds a version number to the API name of the process. For example, when you copy a process with the findAddresses API name, the API name of the copied process becomes findAddresses-1. After you migrate a data enhancement rule with the copied process, the version number is removed from the API name if no process with the same API name exists in the organization. However, the version number remains in the Process Name property of the data enhancement rule. To prevent data enrichment from failing, manually remove the version number from the process name in the data enhancement rule.
• •When you import a business entity that has its business ID format configured, the business ID format configuration isn't imported. After the import, ensure that you configure the business ID format for the imported business entity.
• •When you migrate authorization configurations, ensure that the data access rules contain unique names in the source and target organizations. If the data access rules contain the same name but are associated with different business entities in the source and target organizations, MDM SaaS overwrites the data access rule in the target organization.
For example, you have a data access rule with the name Test Rule 1 to protect the Person business entity in the source organization and a data access rule with the same name Test Rule 1 to protect the Organization business entity in the target organization. If you migrate the authorization configurations, MDM SaaS overwrites the data access rule in the target organization to protect the Person business entity.
Note: Before you migrate authorization configurations, ensure that you first configure all data access rules in the source organization and then import them to the target organization.
• •When you migrate authorization configurations that include draft data access rules in the source organization, ensure that the target organization doesn't contain any active data access rule with the same name.
If the target organization contains an active data access rule with the same name, you can't publish the draft data access rule that's imported. After you import the draft data access rule, MDM SaaS removes the active data access rule but internally stores it. When you delete the imported draft data access rule, MDM SaaS deletes the draft data access rule and displays the active data access rule.
• •When you import the authorization asset, if the data access rule names in the asset from the source organization match the rule names in the target organization, MDM SaaS ignores the maximum limit and overwrites the existing data access rules in the target organization.
If the asset that you import contains new data access rules, MDM SaaS checks the maximum limit for each business entity in the target organization. If the maximum limit exceeds, the import of the asset fails.
• •When you import a business entity with error remediation enabled, the imported business entity includes the error remediation settings only if the business entity is new to the target organization. If the business entity already exists in the target organization without error remediation enabled, the imported business entity doesn't reflect the updated error remediation setting.
• • MDM SaaS restricts asset migration from organizations that haven't migrated their basic, advanced, and DaaS rule associations to use Enrichment and Validation Orchestrator into organizations that have.
However, if you have already migrated these rule associations in your source organization, you can import assets into the target organization even if it hasn't migrated to use Enrichment and Validation Orchestrator.
• •MDM SaaS doesn't support migration of assets between organizations containing basic, advanced, and DaaS rule associations that are partially migrated to use Enrichment and Validation Orchestrator.
For example, if some rule associations fail to migrate, the organization might end up with a partial migration. Rerun the job to resolve the issue. If the issue persists, contact Informatica Global Customer Support.
• •Additionally, ensure that you don't migrate assets and run the migrate rule associations job simultaneously.
For example, if you export assets while the migrate rule associations job is in progress, the exported file doesn't contain rule associations that are created as part of the migration process. If you import the exported file into a target organization that's migrated to use Enrichment and Validation Orchestrator, the import fails. When you import assets into an organization, if you simultaneously run the migrate rule associations job, the migration process doesn't consider the rule associations that are being imported.
• •Before you migrate business events and native workflows, ensure that JSON Web Token (JWT) authorization is enabled in the source and target organizations.
• •Before you export native workflows, publish them. You can't export native workflows that aren't published. When you try to export a draft native workflow that was previously published, the last published version of the workflow is exported.
By default, imported native workflows have the published status in the target organization.
• •You can only import native workflows to target organizations that have the Active, Upgrade Available, or Upgrade Queued status.
• •Before you import business events or native workflows, ensure that the user roles used by the business events are available in the target organization with identical casing. If the user roles don't match, the import operation fails.
For example, if a user role in the source organization is Datasteward and a user role in the target organization is DataSteward, the import operation fails.
• •Before you use imported native workflows that contain Application Integration Process service tasks, ensure that you publish the associated Application Integration processes and their related business events. By default, Application Integration processes and their dependent assets have the draft status in the target organization.