Page History

...

All Objects associated to Script based or Procedure based processing in the Source Metadata Repository will not be regenerated or recompiled in the Destination Metadata, instead it is assumed that the RED 10 Target Enablement Pack will provide a suitable Action Processing Script template that generates appropriate code to deal with the legacy script output protocols and parameters in procedures.

In RED 10 all Scheduling Actions for an Object are performed through an Action Processing Script which is built for and associated to each table, the RED Migration Tooling will generate this script for each object that requires one, this generation process can take minutes to hours depending on the size of the metadata repository, machine resources and database performance.

Migrated Object Types

Not all object types from earlier versions or RED are available in RED 10 so it is important to understand what will and won't be migrated, refer to the following table for more details:

Object Type(s)	Migrated	Post Migration Notes
Connections		All connections are migrated, MSAS connections should be manually removed after migration.
MSAS, Cubes, Cube Dims, Tabular Cubes		Analysis Services Object Types are not migrated since RED 10 does not support them yet.
Aggregate Dimension Join Table Aggregate Fact Join Table Aggregate Join Table Fact Rollup Fact Work Table Permanent Stage Model View Fact View		These legacy object sub-types are not available in RED 10 and are migrated but assigned an new Object Type in RED 10 of the same name. Objects of these types should be checked carefully in the Destination metadata.
All Other Object Types		All other object types not mentioned in the rows above are migrated as is.
Object Versions		Previous object versions are not migrated. There are a few reasons for this: a). restoring to a version predating the migration would leave your object in an useable state, b). the size of the versioning tables in legacy repositories adds unnecessary delay to the migration, c) it is better to start versioning again from scratch in the migrated repository.
WhereScape Callable Procedures		Since the inbuilt WhereScape Callable Procedures are compiled on either SQL Server, Oracle or Teradata they can not be migrated. Any Procedures/Blocks or Scripts which called these procedures before will continue to work but the outcomes will be applied to the original Source Metadata Repository and depending on the procedure being called will have no effect. Only the WhereScape Parameter Functions will still be of use as is post migration. Target Enablement Packs will handle legacy procedures that include the WhereScape Parameter functions by synchronizing the dss_parameter table in the Target with the same table in the PostgreSQL metadata repository. In this way most procedures will continue to function as is after migration.
Non-Script Based Loads		Non-Script based loads such as: ODBC, DB Link, SSIS and some File Load types are migrated however these load type will require a load script to be generated and therefore these types will need thorough testing post migrations. Any load which was already script-based should function as is provided the appropriate table level Action Processing Script has been generated.

The Migration Tooling requires the following named connections in RED:

...