The main purpose of a change package is to transfer configurations between systems or to a version control system. Once a change package has been sealed and exported from a source system, it is expected that it will then be imported to a target system. Upon import, the change package can be analyzed against the target system data set, and subsequently installed if desired.
Automated System to System Integration
To automate the integration, sealing a change package on the source system triggers an event, which can be linked to automated import on a target system using REST services for delivery and receiver methods. This eliminates the need for a user to export, download, name, and import a file, and to migrate it to the next system in a chain of IEPs across various STEP systems that are part of a Development, Testing, Acceptance, and Production (DTAP) environment. Additionally, or instead of direct system to system integration, change packages can automatically be exported to a version control system, like GitHub, GitLab or Bitbucket. For details on configuration for integration endpoints, refer to the OIEP for VCS Integration with Change Packages topic and the Change Package Git Delivery Method in OIEP section of the Integration Endpoint Options for VCS Integration topic.
Importing a Change Package
Change packages are exported as encoded STEPXML files and are imported using the Import Manager or an IIEP with the REST Receiver, both are defined in the Data Exchange documentation.
Note: You must create the setup group for change packages manually on the target system before you can import a change package. For more on creating the setup group, refer to the Initial Setup for Change Packages topic. After initial setup, if child setup groups are desired below the Change Packages top node, move these setup groups to target systems using a change package or recreate them manually with the same ID before transferring a new change package to the target systems.
Upon import, the new change package is found in the same location on the System Setup tab as it existed on the source system. Imported change packages have a status of 'Dormant' and a gray icon: 
At this point, the contents of the change package have not yet been applied. Only the change package itself has been imported. No system configurations will be updated, and the status remains dormant until the change package is installed.
Analyzing a Change Package
Once a change package has been imported, you can run an impact report. The impact report provides the user with information they can use to assess if the change package should be installed, and what the system impacts are likely to be upon installation.
To run an impact report, right-click on the Change Package and select Start Impact Report.
The impact report runs as a background process, which is then accessible on the BG Processes tab under Analyze Change Package. A link to the background process is also provided on the change package object.
The contents of the report can be viewed directly in the execution report.
The impact report can also be downloaded via the Download Impact Report button for viewing offline (e.g., in Excel).
Analyze the impact report to determine if the change package should be installed and if any changes should be made on the target system prior to installation. If system changes occur, it may be useful to re-run the impact report.
Note: Not all objects are supported in the impact report. Refer to the Change Package Object Support topic for details.
Using the default ‘Analysis Only’ Handling option prevents objects in the Items Required for Transfer list and the Possibly Impacted Items list used in the impact report from being installed. When the impact report identifies a missing object that is relevant to the feature being migrated, it is recommended to re-open the change package on the source system and either promote the item or add a necessary item that has not been identified, like a referenced business rule or workflow on an IEP or in a Web UI. If system changes occur, it may be useful to run the impact report again after it is re-imported.
If the change package should not be installed, right-click on the change package and select Delete to completely remove it from the system, without the option for restoration.
Note: A deleted change package can only be accessed by importing the package again.
Installing a Change Package Manually
Installation of the change package means that all objects within the change package in the Primary and Secondary flippers are added to the system, while the installation of items in the Items Required for Transfer list depend on the Handling option used for the item. Possibly Impacted Items are only analyzed, not installed, unless promoted to the Primary flipper, which removes the item from the Possibly Impacted Items list. If objects in the change package existed previously on the system, they are updated to reflect the contents of the package.
Refer to the Change Package Object Support topic for considerations when installing a change package.
When the impact report has been reviewed and the change package is determined acceptable, import it on the target system. Select the imported change package, right-click, and select Install Package Contents. Review the execution report for potential warnings or errors.
