Migration Project

ODI 12c migration document
I. Executive Summary
- Brief overview of the migration project
- Goals and objectives
II. Migration Scope

- Source ODI version: 12c
- Target ODI version: [new version]
- Ensure the on premise ODI 12c repository is up-to-date and backed up.
- Objects to be migrated: scenarios, packages, interfaces, data models, topology
III. Pre-Migration Steps

1. Backup the repository: Backup the entire ODI repository, including all projects, models,
mappings, scenarios, and load plans.
2. Document the current environment: Document the current ODI environment, including:
- ODI version and patch level

- Database connections and credentials
- File paths and directories
- Scheduling and automation settings
- Security settings and user roles
1. Identify customizations and dependencies: Identify any customizations, such as:
- Custom KMs (Knowledge Modules)

- Custom ODI plugins
- Dependencies on external systems or applications
1. Assess compatibility: Assess compatibility between the source and target ODI versions,
including:
- Checking the ODI version compatibility matrix

- Identifying potential issues with customizations or dependencies
1. Plan for data consistency: Plan for data consistency during the migration, including:
- Ensuring data integrity and accuracy

- Handling data inconsistencies or errors
1. Test the migration: Test the migration in a non-production environment, including:
- Exporting and importing a small subset of data

- Verifying data consistency and accuracy
- Identifying and addressing any issues or errors
1. Update environment-specific settings: Update environment-specific settings, such as:
- Database connections and credentials

- File paths and directories
- Scheduling and automation settings
- Security settings and user roles
1. Communicate with stakeholders: Communicate with stakeholders, including:
- Informing them of the migration plan and timeline

- Ensuring they are aware of any potential impacts or downtime
IV. Migration Steps

1. Backup source repository and databases:
- Use ODI's built-in backup feature or third-party tools to create a backup of the source
repository and databases.
- Verify the backup for completeness and integrity.
2. Ensure compatibility between source and target ODI versions:
- Check the ODI version compatibility matrix to ensure the target version supports the
features and functionalities used in the source environment.
- Address any compatibility issues before proceeding with the migration.
3. Review and update environment-specific settings:
- Identify environment-specific settings, such as database connections, file paths, and
scheduling parameters.
- Update these settings to reflect the target environment.
Export Steps
1. Export repositories (Master and Work):

- Use ODI Studio or the CLI command "odiExport" to export the Master and Work
repositories.
- Choose the appropriate export format (e.g., XML) and specify the export file location.
2. Export projects:
- Use ODI Studio or the CLI command "odiExportProject" to export individual projects or the
entire repository.
3. Export models:
- Use ODI Studio or the CLI command "odiExportModel" to export individual models or the
entire repository.
4. Export mappings:
- Use ODI Studio or the CLI command "odiExportMapping" to export individual mappings or
the entire repository.
5. Export scenarios:
- Use ODI Studio or the CLI command "odiExportScenario" to export individual scenarios or
6. Export load plans:
- Use ODI Studio or the CLI command "odiExportLoadPlan" to export individual load plans or
Import Steps
1. Import repositories (Master and Work):

- Use ODI Studio or the CLI command "odiImport" to import the Master and Work
repositories.
- Choose the appropriate import format (e.g., XML) and specify the import file location.
2. Import projects:
- Use ODI Studio or the CLI command "odiImportProject" to import individual projects or the
entire repository.
3. Import models:
- Use ODI Studio or the CLI command "odiImportModel" to import individual models or the
entire repository.
4. Import mappings:
- Use ODI Studio or the CLI command "odiImportMapping" to import individual mappings or
5. Import scenarios:
- Use ODI Studio or the CLI command "odiImportScenario" to import individual scenarios or
6. Import load plans:
- Use ODI Studio or the CLI command "odiImportLoadPlan" to import individual load plans or
- Choose the appropriate import format (e.g., XML) and specify the import file location. -Use
the ODI Export Repository feature to export the on premise repository to a file.
- Reconfiguration of topology and data models
-Use the ODI Import Repository feature to import the exported file into the cloud-based ODI
12c repository.
V. Post-Migration Steps
1. Verify imported data for accuracy and completeness:
- Check the imported data for any errors or inconsistencies.
- Verify that all objects (projects, models, mappings, scenarios, load plans) have been
imported correctly.
2. Update environment-specific settings:
- Update any environment-specific settings, such as database connections, file paths, and
scheduling parameters.
3. Test imported scenarios and load plans:
- Run the imported scenarios and load plans to ensure they execute correctly in the target
environment.
-Verify the migration by testing scenarios, interfaces, and packages in the cloud repository.
- If other systems interact with the ODI repository, update their connections to point to the
cloud-based repository.
VI. Issues and Solutions

- Common issues and solutions:
- Error messages and resolutions
- Data inconsistencies and fixes
- ODI version compatibility issues:
- Document any issues encountered during migration
- Solutions implemented to resolve issues
VII. Lessons Learned

- Best practices and recommendations for future migrations
VIII. Appendices
- Screenshots of migration process
- Error logs and troubleshooting notes

- Migration scripts and code snippets
IX. Estimation hours
Estimation of the approximate hours required to migrate an ODI 12c repository to the cloud.
Please note that this is a rough estimate, and actual time may vary depending on the
complexity of your environment, repository size, and the number of objects to be migrated.
Here's a breakdown of estimated hours:
1. Preparation and planning: 4-8 hours

2. Setting up cloud infrastructure: 8-16 hours
3. Installing ODI 12c on the cloud: 4-8 hours
4. Exporting the repository: 2-4 hours
5. Importing the repository: 2-4 hours
6. Configuring cloud-specific settings: 8-16 hours
7. Testing and validation: 16-32 hours
8. Updating dependent systems: 4-8 hours
Based on these estimates, the total approximate hours required to migrate an ODI 12c
repository to the cloud can range from:
- 48 hours (best-case scenario, small repository)

- 128 hours (medium-sized repository)
- 256 hours (large, complex repository)

Migration Project

Uploaded by

Copyright:

Available Formats

Migration Project

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Migration Project

Uploaded by

Copyright:

Available Formats

ODI 12c migration document

II. Migration Scope

III. Pre-Migration Steps

- ODI version and patch level

- Custom KMs (Knowledge Modules)

- Checking the ODI version compatibility matrix

- Ensuring data integrity and accuracy

1. Test the migration: Test the migration in a non-production environment, including:

- Exporting and importing a small subset of data

1. Update environment-specific settings: Update environment-specific settings, such as:

- Database connections and credentials

1. Communicate with stakeholders: Communicate with stakeholders, including:

- Informing them of the migration plan and timeline

IV. Migration Steps

1. Export repositories (Master and Work):

1. Import repositories (Master and Work):

VI. Issues and Solutions

VII. Lessons Learned

- Error logs and troubleshooting notes

Here's a breakdown of estimated hours:

1. Preparation and planning: 4-8 hours

- 48 hours (best-case scenario, small repository)

You might also like