Exporting Objects with Import/Export Utility
It is possible to migrate Objects from one instance to another using Import/Export Utility. Once Elements in staging environments are ready for production you can export/import them from the development system to one or more production systems.
Export (dump) procedure exports an Object from a source instance as a .tar.gz file. All export changes are stored in Import/Export History section.
Additionally, Import/Export Utility can work in conjunction with Export Locations allowing for import to and export from a GitHub repository.
The list of Objects supported for migration:
- User Maps
- Portal Pages (including Layouts, Templates, and Assets)
- User Groups
- Business Units
- Privilege Sets
- Custom Fields
- Email Templates
There are some exceptions and limitations for those Objects. For more information refer to this article.
The export procedure can be:
- Custom: Manually choose Objects directly in Export Editor and then export it. This article describes Custom Export.
- Scheduled: Manually select Objects for export and then export it according to shedule. The process is very similar to custom migration. For more information on Scheduled Migration, refer to this article.
2. Select a Metadata Type to Be Exported
This example shows adding a Portal Page, but the process is intuitive and essentially the same for other types.
NOTE: Dependent Portal Page Layouts, Templates, and Assets will be added to Export automatically.
- Select the required data via the corresponding +Add button
- Activate the checkbox near the necessary object
- [Add To List]
Note: Type a comment about the export
- After importing the data, the note is available in the Import/Export History table and is displayed in its full length in the tooltip on hover
- The objects included in the export list will be automatically downloaded as one .tar.gz archive as shown on the screen below
Name Uniqueness for Elements and Portal Pages
The Migration Utility ensures that there are no Elements with identical names and types in the target system after the migration.
Here’s the uniqueness checking algorithm:
- The Utility checks the
source_idof all Elements on the target system
- If there is a match, that means that the Element from the source system was already migrated to the target system once in the past, and it needs to be updated. The Utility will proceed to the next step
- If there’s none, it means the new Element has to be created. The Utility will proceed to the next step
- The Utility checks all existing Elements on the target system to see if there is a match by
- If there’s no match, the Utility updates the Element or creates a new one
- If there is a match in all three parameters, the Element from the source system won’t be migrated and the error message will occur
The Migration Utility also ensures the uniqueness of Portal Pages. It checks
URL of every Portal Page existing on the target system. If all three match, the Portal Page from the source system won’t be migrated and the error message appears.