To migrate assets between organizations, consider the following rules and guidelines:
•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.
•When you create reference data sets in Business 360 Console, you can't delete them from MDM - Reference 360.
•During migration, the licenses aren't verified. Ensure that you migrate the assets that are licensed in the target organization.
•When you migrate assets, MDM SaaS uses internal IDs to identify MDM SaaS assets and internal ID, aliases, and names to identify Reference 360 assets.
Note: Effective in the April 2025 release, the ability to specify a unique internal ID and alias for a reference data asset is available for preview.
Preview functionality is supported for evaluation purposes but is unwarranted and is not supported in production environments or any environment that you plan to push to production. Informatica intends to include the preview functionality in an upcoming release for production use, but might choose not to in accordance with changing market or technical circumstances. For more information, contact Informatica Global Customer Support.
•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 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 protected 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.
•Before you import business events, 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.