Understand the Migration Wizard Workflow

Owned by Pamela Totas (Deactivated)
Last updated: May 25, 2023
2 min read
Migration Wizard workflow

In the Migration Export process, the client request is parsed to the Appserver via TPE with the list of selected migratable components. The Migration Manager understands the request and respective business object is then communicated to obtain the details of the selected component(s) from the database. All the metadata information is collected by the Appserver and then the .EGL /.ZGL is generated and transferred back to the requested client.

In the Migration Import process, the client request is parsed to the Appserver via TPE with the list of selected migratable components. The Migration Manager understands the request and then the respective business object is communicated to perform the appropriate Inserts/Updates based on the Migration Rule set for each component. Alos, DML actions are the triggered for the respective component in the database tables.

Migration Export Workflow

When you export a metadata component from the source environment, the Migration Wizard reads the metadata component and automatically detects and includes all underlying metadata of the migrated component.

The following is an example of a sample component (Report Profile) with its underlying components.

Sample Component - Report File

Migration Import Workflow

When you import a .EGL file into the target environment, the Migration Wizard first checks whether the incoming component already exists in the target environment. Next, it compares the name and definition of the incoming and existing component.

Case 1: If the name and definition of the incoming and existing component are same:

  • User intervention is not required. You can use the existing component.

  • You can choose a different existing component (if the rule is enabled during export).

Case 2: If the definition of the Incoming and Existing Component are different:

  • User intervention is required. 

  • You can choose a different existing component.

  • Rename the incoming component to something different.

  • You can override the Existing Components definition with Incoming
    Components Definition.

Case 3: If the name of the Incoming Component does not exist in the target environment:

  • The Migration Wizard creates a new component and user intervention is not required.

  • You can choose a different existing component ( if the rule is enabled during export).

Â