Most of the configuration settings within EnterWorks can be migrated from one environment to another. For non-migratable objects, updates to a target environment from a source environment must be done through the UI.
Examples of non-migratable objects include:
- Server Properties
- Logging level settings
- Publication Manager objects
- Configuration repositories, for example: DAMConfig, DAMVariants, Scheduled Exports, Scheduled Imports, Promotions, CN_Registry.
The migratable objects that can be selected directly by the migration tool include:
- Association Groups – must be migrated prior to or in conjunction with the Profiles that reference them.
- Attribute Industries – not used.
- Attribute Security Filters – must be migrated prior to or in conjunction with any repository security assigned with them.
- Code Sets – must be migrated prior to or in conjunction with any profile where they are assigned to attributes. When a code set is migrated, the entire code set is migrated to the target, including deleting codes that no longer exist in the source migration. Unlike when code set codes are changed through the UI where effected records are updated to contain the new value, the migration of a changed code set will be treated as a delete/add. Any references to the old code value must be manually updated post-migration.
- Data Sources – are rarely migrated as the majority of the imports do not access a JDBC data source.
- Export Templates – must be migrated after or in conjunction with the repositories, link relationships, and attributed they reference.
- File Definitions – While it is possible that file definitions exist, it is not often they need to be migrated. Any definition having a name of "FileDef_" should not need to be migrated as they reflect temporary file definitions that did not get cleaned up automatically. The only time a File Definition needs to be migrated is if there is one associated to a Repository View Mapping but this functionality has been largely supplanted using Import Templates.
- Groups – migrating in Groups with the Overwrite option set will replace the user assignments in the target with the ones defined in the source environment (providing the target environment has the same user). It is not recommended to overwrite the Groups since the user assignments in each environment is likely to be very different.
- Hierarchies – need to be migrated before or in conjunction to any other object that references them.
- Home Page Configurations – include references to actual object IDs that are likely not migratable. Without being updated, the object IDs will be incorrect and unexpected behavior may result. Depending upon the type of widget and its settings, it may be necessary to manually migrate changes via the UI.
- Import Templates – need to be migrated after or in conjunction with the repositories and attributes they reference.
- Profiles – attributes removed from a profile in the source environment will not be deleted from the target. The Migration log file will warn that the attribute exists in the target but not the migration. This provides the opportunity to export that data and import it (after possible transformation) before deleting the attributes from the profile. By the end, the attributes have to be manually deleted. Profiles have the option to migrate individual attributes instead of the entire profile. For each attribute, it can be set to be added if not present or overwritten if it exists. Profiles containing reference to a category attribute association object (for Taxonomy attributes) will also migrate the Category Attribute Association object.
- Record Security Filters – need to be migrated after or in conjunction with the Profiles they reference and before or in conjunction with any repository and group to which they are assigned.
- Repositories – includes the Attribute Properties settings (such as snapshot, index, default value, and JSP pop-up, link-relationship). Must be migrated in with the Overwrite option in order for any link relationship associated with the repository to be migrated. The option to select individual link relationships for migration is non-functional at the time of this writing.
- Repository Folders – must be explicitly migrated prior to or in conjunction with the repositories they contain.
- Sequences – should generally not be overwritten (only added if not present), unless the data in the associated repository is also being migrated. Otherwise the sequence number could end up being reset to a lower number and sequences on new records may collide with existing records.
- Style Maps – need to be migrated before or in conjunction with the Publication or Syndication Templates that reference them.
- Taxonomies – need to be migrated before or in conjunction with the Profiles that reference them.
- Transmission Options – need to be migrated before or in conjunction with any repository that references them.
- Users – generally not migrated from one environment to another. But if they are, they need to be migrated before or in conjunction with any Groups that are migrated.
- Security – the attempt is made to migrate the security settings with each securable object. These settings are subject to the differences in user/group assignments between the source and target environments. It may be necessary to include manual steps in the deployment procedure to ensure the security is properly set in the target. This need should be minimized if security is managed at the group level only. When migrating link relationships, the associated repositories must be migrated (at least one of the two being referenced by the link relationship, and the Migrate In must be set to Overwrite for that repository.
There are some migratable objects that cannot be selected directly, but get migrated when other objects are selected. These include:
- Category Attribute Associations (included when assigned Profiles are migrated)
- Link Relationships (included when Repositories are migrated)
- Object Security (included when associated objects are migrated)
- User Preferences (included when Repositories are migrated)
- CodeSet, Taxonomy, and Hierarchy folders (selected alongside the corresponding objects)
- Validation Rules (included when Profiles are migrated)