Run Migration Wizard for Data Mart

Outbound Migration

The Migration Wizard is two-phased. Both phases are managed by a multi-step wizard. You conduct the first, or outbound phase, in the source environment. This phase builds a file of migration information that feeds the second, or inbound phase, which you run in the target Mart environment.

Each Outbound migration process identifies the following:

• The migration process defined for it.

• The items which are migrated in the process.

• The migration rule selected for the process.

Define Migration Process

In the Migration Wizard - Step 1 of 4 tab, define the process for the outbound migration, such as the environment details and output format.

To define the migration process:

1. From the Manage Mart window, click the Migration link and select Migrate Now.
   You see the Migration Wizard - Step 1 of 4 dialog box.

2. Click Migration Process and select Migrate out of current environment.

3. In the File section, select an output format. Options include:
   - Create standard EGL file. Select to build a migration file in the default uncompressed format .EGL.
   - Create a compressed .ZGL file. Select to build a compressed .ZGL file.
   - Compress and append to existing .ZGL file. Select to build a migration file and compress it and append to the existing .ZGL file.

4. In Using the ellipsis button, define the output file section, click the ellipsis to assign a name and directory location to your built outbound file.

5. Click Next.
   You see the Migration Wizard dialog box, step 2 of 4.

Select Items for Migration

In the Migration Wizard - Step 2 of 4 tab, select items for the outbound migration.

To select items for migration:

1. You can see all the defined Mart schemas, with the currently selected schema highlighted in the dialog box.
   Since the Migration Wizard works independently of your current choice of schema in the Data Mart Instance dropdown, you can click any Mart instance to migrate models.
   However, you can migrate from only one schema into any single .EGL or .ZGL file. To select a list of models to migrate, double-click each one in the model list that appears in the upper-right panel. Note that in Migration Wizard Dialog Box - Step 3 of 4, the user has renamed all Model IDs from their default values to a set of abbreviations, in both the source and the target.

2. Click Next to continue.
   You see the Migration Wizard dialog box, step 3 of 4.

Select Migration Rule

In the Migration Wizard - Step 3 of 4 tab, select migration rule for the outbound migration.

To select the migration rule:

1. In this dialog box, you set up a series of default values to be presented to the person who runs inbound migration in the target environment.
   Set up the defaults that you want to be used on the inbound side. These defaults pertain to how PACE should handle duplicate meta data in the target environment-both how to identify a duplication and what to do when a duplication is identified. Best practice is to adopt the values shown in Migration Wizard Dialog Box - Step 3 of 4.

2. Any such set of values is known as a Migration Rule. You can save these rules using the Save As button, then reuse saved rules by selecting them from the Migration Rules dropdown.

3. Click Next to continue.
   You see the Migration Wizard dialog box, step 4 of 4.

Start the Migration Process

In the Migration Wizard - Step 4 of 4 tab, start the migration process.

To start the migration process:

1. Click Start to begin building the .EGL or .ZGL file.
   A message, Migration Process Complete, appears, as shown in Migration Process Complete Message.

2. Click View Results to see a message confirming that your .EGL file was created in the selected directory.

3. If you have enabled Migration Wizard logging, you can view the log file online. Click the down arrow opposite the log file name. Information regarding the log file appears.

4. Click the + to the left of a date and time to view a dropdown list of all migration logs generated. Then double-click one of those migration log names to view the log, as shown in the following figure. If there are many logs available, you can filter them by selecting Last Migration, Today's Migration, or Show All.

Inbound Migration

The second phase of migration, inbound migration, takes place in the larger Mart environment.

To perform inbound migration:

1. From the Manage Mart window, click the Migration link and select Migrate Now.
   You see the Migration Wizard dialog box.

2. From the Migration Process dropdown, select Migrate into current environment.

3. Click the ellipsis button in the File section.
   You see the Open dialog box as shown in the following figure.

4. Select an .egl file for inbound migration, then click Add, as shown in the following figure to remove a selected file, click Remove. Click Clear to remove all selections.
   Normally you migrate just a single .egl file.

5. Click OK to continue.
   You see the Inbound Migration Wizard Step 2 dialog box.

6. You can accept or override the settings on this dialog box. Best practice is to accept the previously defined defaults. Click Next to continue.
   A dialog box may appear, indicating that some entities mapped to models in the source environment are not present in the target. This is normal and expected, and you can accept this condition and move on. If no source entities exist in the target, you are asked to select at least one entity from the target for the models migrated. You can remove this entity manually post-migration if you choose.
   Next, you see a Validation dialog box. This dialog box displays two types of message:

   • Informational, such as the message displayed in the following figure.

     Open

     

     
     Error, indicating a conflict between meta data being migrated to the source and meta data already present in the target. For more information on conflicts, refer to Migration Conflicts. If it is possible to correct your error validation by changing some characteristic of source metadata before it is migrated, prompts appear in a lower panel allowing you to do that, as shown in the following figure.

     Open

     

7. On the Inbound Migration dialog box, step 2, click Next to go to Step 3.
   You see the Inbound Migration Wizard, Step 3 dialog box.

8. Click Start to start the inbound migration.
   When inbound migration is completed, you see the Inbound Migration dialog box Step 3 of 4.

9. Click View Results to see the name of the migration file you have processed, and the migration log if you enabled logging.

Migration Conflicts

If you fully observe the best practices described in this section, Data Mart migration should be a trouble-free process. However, the tool is built with rules governing what happens when best practices are violated. Such violations can lead to two types of conflict during migration; duplications and inconsistencies.

Duplications

The most common error is that during migration the target environment is found to contain models, model extensions or fields that resemble models and fields being migrated from the source environment, but with differences in their characteristics that raise questions as to exactly what you intended to migrate. These are known as duplications.

The key to understanding duplications and their resolution is that Mart components-models, extensions, and fields are each identified by their ID. But components have other characteristics besides ID, like the table column name of a field that must be associated with that component and no other. Duplications occur when migration attempts to link certain characteristics to more than one component, usually one component being migrated and another already in the target.

The following table lists the mart components identified by their ID in the first column. In the second column, it lists characteristics for each component type that will result in conflicts if duplicated by other IDs in the target.

Grouping Field Column Names

There is a special requirement for duplication of grouping field column names. In Mart tables, the table column names that you assign to the levels of a grouping hierarchy in a group-level model cannot be duplicated by the column names of regular fields. The reason for this restriction is to avoid the possibility that two columns of a table are assigned the same name. This would make it impossible to save the model that attempts to make such an assignment.
The implication for migration is that as you migrate a regular field to the target, there may be no grouping field that has the same column name.

Inconsistencies

Inconsistencies are conflicts where a migrated component exists in the target and no duplication is present, but the component has one or more different characteristics in the source versus the target. An example is where a Mart field with ID DMD_1234 has column name MARKET_VALUE in the source but MARKET_VALUE_INCOME in the target.

You deal with inconsistencies in your migrations by selecting the Duplicate Handling option in Step 2 of the Migration Wizard. If you select Use the existing item as a duplicate handling policy, then migration resolves any migration inconsistency by preserving the values of all characteristics in the target. The alternative policy of Overwrite the existing item causes the source values of all characteristics to overwrite those in the target. Note that these overwrites apply to all occurrences in the target of migrated fields, both in models that you migrated and in models that you did not migrate.

Conflicts beyond Online Correction

If it is possible for you to correct an inconsistency by altering the value of a migrated component during inbound migration. Migration Wizard gives you the opportunity to do so in a dialog box. However, certain types of conflicts cannot be corrected during migration. An example is the prior use in the target of a particular field attribute (identified by its field identifier) that is associated with a different Data Mart field. When such a conflict is encountered during the Validation phase of in-migration, all validations are displayed, but a dialog box informs you that at least one cannot be corrected. The migration is terminated.