The following rules define best practices for migration.
If a piece of metadata must be propagated to a downstream environment, and Migration Wizard can migrate it, then Migrate Wizard should migrate it.
If Data Mart models are used in portal queries, query views, dashboard parts, or dashboard views, you must first migrate the Data Mart models into the downstream environment.
Direct changes should not be made to migratable metadata in downstream environments.
Perform 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 instructions that feeds the second or inbound phase, which you run in the target environment.
To perform outbound migration:
From any Eagle window, click the Eagle Navigator button to access the Eagle Navigator.
Enter Portal Administration in the Start Search text box.
Click the Portal Administration (Reporting Center) link to access Portal Administration.
You see the Portal Administration window.Click Yes in the Do you see the Eagle logo here? dialog box.
You see the Portal Query Explorer window as the default.Click Migration.
From the Migration Process drop down menu, select Migrate out of current environment.
You see the Migration Wizard - Step 1 of 4 dialog box.In the File section, select the output format for building the migration file.
Click the ellipsis icon next to the dropdown. Assign a name and directory location to your built outbound file.
Click Next.
You see the Migration Wizard - Step 2 of 4 dialog box. The upper-left panel displays the Queries, Dashboards, and Parts, including parts that you can drilldown into, with the currently selected component highlighted.Click on any component to begin migration. Since Queries are the building block for Dashboards and Parts, selecting only Dashboards or Parts will also migrate the underlying Query into the destination. To remove any component in the lower pane, highlight the selected item and right click.
Click Next to continue.
You see the Migration Wizard - Step 3 of 4 dialog box.Set up a series of default values to be presented to the user who runs the inbound migration in the target environment. Set up the defaults that you want to be used on the inbound side.
These defaults reflect how the system should handle duplicate meta data in the target environment, how to identify duplication and what to do when duplication is identified. Best practice is to adopt the values shown in this dialog box. Any such set of values is known as a Migration rule. You can save such rules using the Save As button in the upper right of the grid, and then reuse saved rules by selecting them from the dropdown in subsequent migrations.Click Next to continue.
You see the Migration Wizard – Step 4 of 4 dialog box.Click Start to begin building the .EGL or .ZGL file.
You see the Migration Process Completed when the process is done.Click View Results to see a message confirming that your file was created in the selected directory. If you have enabled Migration Wizard logging, you can view the log file online using View Results.
Perform Inbound Migration
The second phase of migration, inbound migration, takes place in the target environment. The user performing the inbound migration of Queries, Dashboards, and Parts becomes the owner of the migrated queries, query view, dashboard parts, and dashboard views after inbound migration.
After completing inbound migration, it is this user's responsibility to reassign them to the appropriate users or business groups.
To perform inbound migration:
From any Eagle window, click the Eagle Navigator button to access the Eagle Navigator.
Enter Portal Administration in the Start Search text box.
Click the Portal Administration (Reporting Center) link to access Portal Administration.
You see the Portal Administration window.Click Yes in the Do you see the Eagle logo here? dialog box.
You see the Portal Query Explorer window as the default.Click Migration.
From the Migration Process dropdown, select Migrate into current environment.
You see the Migration Wizard - Step 1 of 3 dialog box.From the File section, click the ellipsis button and select the file to use as the input file.
Click Next to continue.
You see the Inbound Migration Wizard Step - 2 of 3 dialog box.
You can accept or overwrite the settings on this dialog box. Best practice is to accept the previously defined defaults.Click Next to continue.
You see the Migration Wizard - Step 3 of 3 dialog box.Click Start to start the inbound migration.
In the Inbound Migration Wizard - Step 2 of 3 dialog box, you may see Stored Procedures listed in the Migration Item column if you are migrating in a component that is built upon the query type ACCESS SQL QUERY, which uses a stored procedure, as shown in the following figure.
Migration Wizard does not migrate in a stored procedure, but it gives you the ability to copy it into a clipboard for use later.
Once you copy it to your clipboard, you can insert the stored procedure into the target environment's database. If your target environment's database is SQL but the source environment's database is Oracle, you have to modify the stored procedure you copied to clipboard before inserting it into the SQL database. The reverse is also true.After you have completed the inbound migration and inserted the stored procedure into the database, go to the Portal Query Explorer and populate the Procedure field in the Query Settings dialog box with the exact name of the stored procedure.
Additional Information for Migration Wizard
In the Step 2 of 4 dialog box in outbound migration, queries, parts, and dashboards are available in the upper-left panel. The following sections contain additional information about what they are and how Migration Wizard handles them.
Queries
These are the report queries that are configured in the Portal Query Explorer. Only the internal query type (Type = Internal) queries cannot be migrated by Migration Wizard.
All elements configured for a query in the Query Explorer are migrated. All the views created for a query are migrated. The default view if defined for a query is migrated. The criteria if defined in a query view are migrated.
Parts and Dashboards
Parts refer to dashboard parts that are built upon queries. Dashboards refer to dashboard views that are built using multiple dashboard parts.
The following configuration items in a dashboard part are migrated:
Part name
Category
Part type such as data, chart, or both
Selected fields and in the order as defined in the dashboard part
Column options such as group by, and calculation if any
Dates such as date rule as defined in the dashboard part
Results such as sort by, ascending or descending, show all results, or show first n results
Transform if used in dashboard part
All the dashboard parts contained in a dashboard view are migrated.
The location of the dashboard parts contained in a dashboard view are migrated and retained.
If the dashboard view uses a template that does not exist in a target environment, it is migrated.
The default view, if defined for a dashboard view, does not migrate since there is only one default view in the Dashboards window.
The criteria if defined in a dashboard view are migrated.
If a public dashboard view is selected in an outbound migration, the public dashboard view becomes a private dashboard view and the user who performed the inbound migration becomes the owner of it. It is then up to the user to re-publish the view as a public view and re-assign it to different users or business groups.