Oracle Essbase & Cloud EPM Migration

Can I migrate an existing Oracle Essbase application to Casabase Cube?

Yes.

Casabase Cube can create a multidimensional model from the native Essbase artifacts of an existing Oracle Essbase application.

A typical migration uses:

• The native Essbase outline (.otl)
• A native level-0 export of the cube data

The outline provides the multidimensional metadata, while the native level-0 export provides the detailed data used by Casabase Cube for dynamic aggregation and calculation.

See Migrating from Oracle Essbase.

Can I migrate an Oracle Cloud EPM application?

Yes.

Oracle Cloud EPM plan types use Essbase as their multidimensional storage engine, and Casabase Cube can migrate the corresponding plan type using its native Essbase artifacts.

The migration similarly uses:

• The plan type’s native Essbase outline (.otl)
• A native level-0 export of the plan type data

See Migrating from Oracle Cloud EPM.

What artifacts do I need for a migration?

For either Oracle Essbase or Oracle Cloud EPM, the two primary migration artifacts are:

Native Essbase Outline
        .otl
         │
         ├──────────────┐
         │              │
         ▼              ▼
   Cube Metadata     Native Level-0
                      Data Export
         │              │
         └──────┬───────┘
                ▼
          Casabase Cube

The .otl file supplies the multidimensional structure.

The native level-0 export supplies the detailed stored data.

Does Casabase Cube use native Essbase outline (.otl) exports?

No.

The current migration process uses the native Essbase outline file:

.otl

native Essbase outline (.otl) exports are not required by the current migration workflow.

If older Casabase Cube documentation refers to an Essbase native Essbase outline (.otl) export, use the current .otl-based migration documentation instead.

Why does Casabase Cube use the native OTL file?

The native Essbase outline contains the multidimensional metadata that defines the cube.

Depending on the source application and supported metadata, this can include:

• Dimensions
• Hierarchies
• Members
• Parent-child relationships
• Aggregation operators
• Aliases
• Shared members
• Member properties
• Formulas
• Time Balance properties
• User Defined Attributes (UDAs)
• Solve order and other calculation metadata

Casabase Cube imports supported metadata from the outline and converts it into the structures used by its Snowflake-native multidimensional engine.

What happens when the OTL file is imported?

Casabase Cube imports the outline using:

CUBE.IMPORT_ESSBASE_OTL

The import creates the metadata needed to define the cube and creates dimension definition tables for the imported dimensions.

Tables created from an Essbase outline use the naming convention:

<CUBE_NAME>_<DIMENSION_NAME>_OTL

For example:

FINANCE_ACCOUNT_OTL
FINANCE_ENTITY_OTL
FINANCE_PERIOD_OTL
FINANCE_SCENARIO_OTL

These tables are created within:

CASABASE_CUBE.SHARED_DATA

The resulting definition tables are then used to build the active hierarchy structures.

Does importing the OTL automatically build all hierarchies?

The outline import creates the source metadata used by Casabase Cube.

Hierarchies must then be built from that metadata.

For an initial migration, this can be performed with:

CALL CUBE.REBUILD_AUTO_HIERARCHIES(
    'FINANCE',
    TRUE,
    TRUE,
    TRUE
);

If Rebuild hierarchies after import is selected during an interactive outline import, the rebuild can be performed as part of that workflow.

See Rebuilding Dimensions.

What data export should I use?

Use a native level-0 export.

The level-0 export contains the detailed stored values that form the data foundation of the migrated cube.

Do not migrate pre-aggregated parent values as though they were stored base data.

Casabase Cube dynamically calculates higher-level values using the imported hierarchy and aggregation metadata.

Why is only level-0 data needed?

Casabase Cube performs aggregation dynamically at query time.

Conceptually:

Native Level-0 Data
        │
        ▼
Imported Hierarchies
        +
Aggregation Rules
        +
Formulas
        │
        ▼
Dynamic Query-Time
Aggregation & Calculation
        │
        ▼
Requested Result

Because higher-level values can be calculated from the detailed data and multidimensional metadata, Casabase Cube does not need an Essbase-style collection of precomputed aggregate values.

How is the native level-0 data imported?

Use:

CUBE.IMPORT_ESSBASE_EXPORT

The procedure reads native Essbase level-0 export files from a Snowflake stage and imports the data into the target cube.

For example:

CALL CUBE.IMPORT_ESSBASE_EXPORT(
    '@MY_DB.MIGRATION.EPM_STAGE/Finance/Plan1/data/',
    'FINANCE',
    FALSE
);

The stage path identifies the directory containing the native level-0 export files.

What native export file formats are supported?

The migration workflow supports native level-0 export files in:

Format	Description
.txt	Uncompressed native Essbase level-0 export
.gz	Gzip-compressed native Essbase level-0 export

A stage directory can contain one or more export files.

Can I import multiple native level-0 files?

Yes.

IMPORT_ESSBASE_EXPORT receives the stage directory containing the export files rather than requiring a single data filename.

For example:

data/
├── data1.gz
├── data2.gz
└── data3.gz

can be supplied through the directory path:

@MY_DB.MIGRATION.EPM_STAGE/Finance/Plan1/data/

What is the difference between IMPORT_ESSBASE_OTL and IMPORT_ESSBASE_EXPORT?

They import different parts of the source application.

Procedure	Purpose
IMPORT_ESSBASE_OTL	Imports the native .otl metadata used to define the multidimensional model.
IMPORT_ESSBASE_EXPORT	Imports the native level-0 data into the cube.

Conceptually:

.otl
 │
 ▼
IMPORT_ESSBASE_OTL
 │
 ▼
Cube Metadata


Native Level-0 Export
 │
 ▼
IMPORT_ESSBASE_EXPORT
 │
 ▼
Cube Data

Both are required for a typical complete migration.

Do the OTL file and data files have to be placed in a Snowflake stage?

For the SQL-based migration workflow, yes.

Casabase Cube must be able to read the migration artifacts from an accessible Snowflake stage.

A useful directory structure is:

EPM_STAGE/
└── <Application>/
    └── <Cube or Plan Type>/
        ├── metadata_otl/
        │   └── <Outline>.otl
        └── data/
            ├── data1.gz
            └── data2.gz

This keeps metadata and data artifacts clearly separated and makes automated refresh workflows easier to manage.

Can I upload an OTL through the Casabase Cube interface?

Yes.

For an initial migration, testing, or ad hoc administration, the .otl file can be uploaded through the Casabase Cube interface.

The interactive workflow allows you to:

• Specify the cube name
• Select the .otl file
• Choose a stage when applicable
• Optionally rebuild hierarchies after import
• Upload and import the outline

For repeatable production migrations and refreshes, the SQL and stage-based workflow is generally more appropriate.

What Snowflake permissions are required for a customer-owned migration stage?

When Casabase Cube reads artifacts from a customer-owned Snowflake stage, the Native App must be granted the appropriate access to the containing database, schema, and stage.

A typical pattern is:

GRANT USAGE ON DATABASE MY_DB
  TO APPLICATION CASABASE_CUBE;

GRANT USAGE ON SCHEMA MY_DB.MIGRATION
  TO APPLICATION CASABASE_CUBE;

GRANT READ ON STAGE MY_DB.MIGRATION.EPM_STAGE
  TO APPLICATION CASABASE_CUBE;

Use the actual application name and stage objects for your environment.

How do I obtain the OTL from Oracle Essbase?

Obtain the native .otl file for the Essbase database being migrated.

The exact extraction procedure depends on the Oracle Essbase version, deployment model, and administrative tooling available in your environment.

The required artifact for Casabase Cube is the native outline file itself, not an XML conversion of the outline.

See Migrating from Oracle Essbase for the current workflow.

How do I obtain the OTL from Oracle Cloud EPM?

For Oracle Cloud EPM, obtain the native .otl for the plan type from the application’s migration snapshot/artifacts.

The .otl is part of the Essbase artifacts contained in the Cloud EPM application snapshot.

Extract the .otl for the specific plan type being migrated rather than attempting to reconstruct the outline from dimension CSV exports.

See Migrating from Oracle Cloud EPM for the detailed artifact workflow.

Do I need to export every Cloud EPM dimension as CSV?

No.

The current Casabase Cube migration workflow uses the native Essbase .otl as the source of multidimensional metadata.

You do not need to rebuild the cube by separately exporting every Cloud EPM dimension to CSV.

Older documentation that describes a CSV-per-dimension migration workflow does not reflect the current .otl-based migration process.

How do I export Cloud EPM data?

Create a native Essbase data export for the plan type.

EPM Automate can be used to export and download native Essbase data from Cloud EPM.

For example, the source workflow can use:

epmautomate exportEssbaseData <PlanType> <ExportFileName>.zip
epmautomate downloadFile outbox/<ExportFileName>.zip

The resulting native level-0 export files can then be staged in Snowflake and imported with IMPORT_ESSBASE_EXPORT.

Refer to Oracle’s current EPM Automate documentation for the exact commands and authentication requirements applicable to your Cloud EPM environment.

Do I migrate one Cloud EPM application or one plan type at a time?

A Casabase Cube corresponds to a multidimensional cube.

In Cloud EPM, the relevant migration unit is therefore the plan type whose Essbase outline and data are being migrated.

If a Cloud EPM application contains multiple plan types, treat each required plan type as a separate source cube and evaluate how those models should be represented in Casabase Cube.

Are BSO and ASO sources supported?

Casabase Cube’s migration workflow supports native Essbase artifacts from both BSO and ASO source applications where the corresponding structures and metadata are supported.

The source storage type does not change Casabase Cube into a BSO or ASO database.

After migration, the model executes using the Casabase Cube Snowflake-native architecture.

Does Casabase Cube recreate the Essbase storage engine in Snowflake?

No.

The objective is to preserve the useful multidimensional model and business logic, not to reproduce Essbase’s physical storage architecture.

After migration:

Oracle Essbase Model
        │
        ├── Dimensions
        ├── Hierarchies
        ├── Aggregation Rules
        ├── Formulas
        └── Level-0 Data
                │
                ▼
         Casabase Cube
                │
                ▼
       Snowflake-Native
    Multidimensional Engine

Casabase Cube performs aggregation and supported calculation dynamically using Snowflake compute.

Are Essbase aggregate blocks migrated?

No.

Casabase Cube does not need Essbase aggregate blocks or a pre-aggregated cube database.

The native level-0 data is imported, and higher-level results are calculated dynamically using the migrated hierarchy and calculation metadata.

Do I need to run an Essbase-style calculation or aggregation after loading data?

No traditional Essbase aggregation process is required.

After the hierarchy structures are built and native level-0 data is loaded, Casabase Cube can dynamically aggregate the data when queried.

Formula behavior is also evaluated dynamically according to the supported Casabase Cube calculation model.

Are member formulas migrated?

Supported member formulas contained in the native .otl can be imported as part of the multidimensional model.

You do not need to manually recreate every supported source formula.

However, formulas should be validated after migration, particularly when the source application contains complex Essbase-specific calculation behavior.

See Formula Validation.

Are all Essbase formulas guaranteed to work without changes?

No.

Essbase supports a broad calculation language and application patterns that may not map directly to Casabase Cube’s member-formula model.

Casabase Cube imports and evaluates supported formula constructs.

Unsupported or incompatible constructs should be identified during validation and rewritten where necessary.

Casabase Cube favors refusing unsupported calculation semantics rather than silently approximating a result.

Are shared members supported during migration?

Yes.

Shared-member metadata can be imported from supported Essbase outline structures and represented in the Casabase Cube hierarchy model.

Shared members should be included in post-migration validation because they can affect hierarchy navigation, aggregation paths, and reporting behavior.

Are aliases migrated?

Supported alias metadata can be imported from the native outline.

After migration, validate important alias tables and member aliases used by reports, integrations, or business users.

Are Time Balance properties migrated?

Supported Time Balance metadata can be represented in Casabase Cube and participates in multidimensional calculation behavior.

This includes supported Time Balance types and skip behavior.

Time-related calculations should be specifically tested during migration validation because their results depend on both hierarchy structure and member properties.

Are UDAs migrated?

Supported User Defined Attributes (UDAs) can be imported as member metadata.

UDAs can also participate in supported formula logic, such as UDA-aware calculations.

Validate UDA-dependent formulas and business logic after migration.

Is two-pass calculation supported?

Casabase Cube can preserve relevant imported calculation metadata where supported, including two-pass-related member properties.

The resulting calculation behavior should be validated against representative source results because Casabase Cube uses its own Snowflake-native calculation engine rather than reproducing the Essbase execution engine internally.

What happens to solve order?

Solve order is part of Casabase Cube’s calculation model and can be imported where supported.

It controls calculation precedence when calculated members or multidimensional interactions require explicit ordering.

Validate important calculations whose source behavior depends on solve order.

Does migrating a cube also migrate Essbase security?

Do not assume that source Essbase or Cloud EPM security automatically becomes the final Casabase Cube access model.

Casabase Cube access is based on Snowflake application roles and Casabase Cube row-level security.

After migration, administrators should explicitly review and configure:

• Snowflake access to the Native App
• CUBE_PUBLIC and CUBE_ADMIN grants
• Dimensions that require row-level security
• User security rules
• Effective user access

See Access Control and Roles and Privileges.

Does migrating the OTL automatically enable row-level security?

No.

Imported hierarchy metadata and access-control configuration are separate concerns.

A migrated dimension does not become secured simply because it came from an Essbase or Cloud EPM outline.

Administrators must configure the required Casabase Cube security model after migration.

What happens to data after it is imported?

The imported bottom-level data is stored within the Casabase Cube Native Application database in the customer’s Snowflake account.

It is not transferred to or stored in Casabase Software infrastructure.

Casabase Cube then uses that data with the imported hierarchy and calculation metadata to execute multidimensional queries within Snowflake.

How should I validate a migrated cube?

Validation should include both structural and business-result checks.

Start with:

CALL CUBE.HEALTH_CHECK('FINANCE');

Then compare the migrated cube with the source application.

Useful validation areas include:

• Dimension counts
• Member counts
• Hierarchy structures
• Parent-child relationships
• Shared members
• Aliases
• Aggregation operators
• Member properties
• Formulas
• Native level-0 data totals
• Key business calculations
• Representative query results

A technically successful import is not the same as a completed migration. Important business results should be reconciled against the source system.

Should I validate level-0 data separately from calculated results?

Yes.

Separating the two is useful when troubleshooting migration differences.

A good sequence is:

Validate Structure
       │
       ▼
Validate Level-0 Data
       │
       ▼
Validate Aggregations
       │
       ▼
Validate Formulas
       │
       ▼
Validate Representative Reports

If level-0 data does not reconcile, investigate the data export or import before troubleshooting higher-level calculations.

If level-0 data reconciles but parent values differ, investigate hierarchy and aggregation metadata.

If stored and aggregated values reconcile but calculated members differ, investigate formulas and calculation behavior.

What happens if the data export contains an unknown member?

IMPORT_ESSBASE_EXPORT provides an option controlling how unknown members are handled.

For migration validation, using strict behavior is often preferable so unexpected members are not silently discarded.

For example:

CALL CUBE.IMPORT_ESSBASE_EXPORT(
    '@MY_DB.MIGRATION.EPM_STAGE/Finance/Plan1/data/',
    'FINANCE',
    FALSE
);

With unknown-member ignoring disabled, mismatches between the data export and imported hierarchy can be identified and corrected.

Should I drop and recreate the cube every time metadata changes?

No.

DROP_CUBE is a destructive lifecycle operation and should not be part of a routine production refresh simply because source metadata changed.

Casabase Cube supports reimport and rebuild workflows for maintaining an existing migrated cube.

See Rebuilding Dimensions and Operational Tasks.

Can I refresh a migrated cube after the initial migration?

Yes.

The initial migration and ongoing production refresh can use related workflows.

Depending on what changed, a refresh can involve:

• Exporting an updated .otl
• Exporting updated native level-0 data
• Updating the artifacts in the Snowflake stage
• Reimporting source metadata
• Rebuilding affected hierarchy structures
• Importing refreshed data
• Validating the cube

Casabase Cube also provides:

REIMPORT_CUBE_SOURCE

for reimporting a cube from its configured source definition, with optional rebuild behavior.

Do I need to reimport the OTL every time data changes?

No.

If only fact data changed and the multidimensional metadata is unchanged, there is no reason to reimport the outline solely because new data is available.

Conceptually:

Data Changed Only
      │
      ▼
Refresh Data


Metadata Changed
      │
      ▼
Reimport / Rebuild
      │
      ▼
Refresh Data as Needed

The refresh workflow should reflect what actually changed in the source system.

Do I need to reload fact data every time a formula changes?

No.

Formula metadata and fact data are separate.

A formula or hierarchy metadata change can require rebuilding the affected dimension structures, but the fact table does not need to be reloaded solely because a formula changed.

Can the migration process be automated?

Yes.

The SQL-based workflow is suitable for repeatable automation.

A production process can:

1. Export updated Oracle artifacts.
2. Place them in the configured Snowflake stage.
3. Execute the applicable Casabase Cube import or reimport procedures.
4. Rebuild affected hierarchies.
5. Import refreshed native level-0 data when required.
6. Run health checks and validation.
7. Monitor the workflow for errors.

The exact orchestration mechanism is up to the organization.

Can I keep using the same Snowflake stage for ongoing refreshes?

Yes, provided the stage remains accessible to the Casabase Cube Native App and the artifact layout is managed consistently.

Using predictable directories for each source application and cube or plan type can simplify automated refreshes.

For example:

EPM_STAGE/
├── Finance/
│   └── Plan1/
│       ├── metadata_otl/
│       └── data/
└── Workforce/
    └── OEP_WFP/
        ├── metadata_otl/
        └── data/

Can I migrate first and optimize later?

Yes.

The first priority should be correctness:

Import
  │
  ▼
Build
  │
  ▼
Load
  │
  ▼
Validate
  │
  ▼
Reconcile
  │
  ▼
Optimize

After the migrated cube is functionally correct, use Casabase Cube’s performance diagnostics and Snowflake workload information to determine whether warehouse sizing, clustering, Search Optimization, query changes, or materialization are appropriate.

See Performance & Scalability.

Will existing Essbase reports work unchanged?

Not necessarily.

Casabase Cube preserves the multidimensional model where supported, but it does not expose an Essbase server or require Essbase client protocols.

Queries are executed through Casabase Cube interfaces such as:

• Query Builder
• CUBE.QUERY_CUBE
• Snowflake SQL
• Snowflake-supported APIs, drivers, and connectors

Existing reports or integrations that depend specifically on Essbase connectivity, MDX, report scripts, or other Essbase-specific interfaces may need to be repointed or redesigned for Snowflake/Casabase Cube access.

Does Casabase Cube require MDX after migration?

No.

Casabase Cube’s primary programmatic query interface is Snowflake SQL through:

CUBE.QUERY_CUBE

Users can also build multidimensional queries through Query Builder.

There is no requirement to use MDX to query a migrated cube.

Do I still need Essbase after the migration?

Once the Casabase Cube implementation has been fully validated and dependent reporting, integration, security, and operational workflows have been transitioned, the organization can determine whether the source Essbase or Cloud EPM environment is still required.

Decommissioning should occur only after the organization’s migration acceptance, reconciliation, retention, and rollback requirements have been satisfied.

What is the recommended migration sequence?

For a typical Essbase or Cloud EPM cube:

Obtain Native .OTL
        │
        ▼
Create Native Level-0 Export
        │
        ▼
Stage Migration Artifacts
        │
        ▼
Import .OTL
        │
        ▼
Build Hierarchies
        │
        ▼
Import Level-0 Data
        │
        ▼
Run Health Check
        │
        ▼
Reconcile with Source
        │
        ▼
Configure Security
        │
        ▼
Validate Queries & Integrations
        │
        ▼
Production Cutover

The detailed steps differ slightly depending on whether the source is Oracle Essbase or Oracle Cloud EPM.

Where should I start?

Use the migration guide for the source platform:

• Migrating from Oracle Essbase
• Migrating from Oracle Cloud EPM

For related topics, see:

• Creating a Cube
• Rebuilding Dimensions
• Formula Validation
• Access Control
• Health and Diagnostics
• Performance & Scalability