This blog post is part of a series to support those moving to Intelligent Advisor Cloud ahead of Premier support for Intelligent Advisor on-premises, formerly known as Oracle Policy Automation, ending in September 2025.
This post specifically explains how to use the migration tool in Oracle Policy Modeling.
What is the OPM v12 migration tool?
The OPM migration tool is used to migrate a v10.4 Policy Modeling project (rule documents, screens, test cases, and so on) in to a v12 project. This tool does a first pass upgrading the project and addresses most of the out-of-the-box functionality from Oracle Policy Automation. (Customizations and integrations need to be addressed separately.) It generates a migration log that can be used to help you understand what was and wasn’t migrated.
There are two ways you can use the tool:
- By opening a v10.4 project in OPM v12. This will trigger the migration process. This blog post will explain this approach in further detail.
- From the command line. For more information, see Migrate a Version 10.4 Project From the Command Line.
Start migrating a project
To start a migration:
- Ensure that any pre-migration steps have been performed.
- Close Microsoft Word and Microsoft Excel.
- Open the current version (12.x) of Oracle Policy Modeling.
- Use the Open Project button to find the v10.4 project that you want to migrate. You will be warned that the project needs to be migrated before it can be used in this version of Policy Modeling. Click OK to continue.
- In the Migrate Project dialog, specify a name for the new (migrated) project (it defaults to the existing project name) and select its location. You also have the option here to select that Excel cell values are rewritten for maximum compatibility. Hover over the tooltip to find out more and decide if this option is best for your rules.
- Click Start. The bar at the bottom of the dialog box shows the progress of the migration, and indicates when the migration is complete and if there are any warnings.
Use the migration log to understand what was and what was not migrated
If the migration completed, there will be a migration.log file in your migrated project. You can access this from the Migrate Project dialog by clicking View log. The log opens in Notepad.
For example:
The log shows you:
- what was migrated
- the warnings about components that have been ignored or are not supported or have had changes made.
You need to pay particular attention to the warnings.
Non-migrated components
The following components will not be migrated:
- Modules
- Flows
- Data review screens
- Captions on goal controls
- External (XML) lists
- CSS class or style properties
- Some custom properties
- Configuration-styled rule loops
- Base Value parameter for entity collects
- Visualization files
- Properties files
Changed components
The following components are changed during migration:
- Goals – these will be imported as explanations
- Landscape-styled entity collects – these will be imported as Portrait-styled entity collects
- Heading levels 7 and 8 in labels – these are no longer supported and will be imported as Normal-styled labels instead
- Summary screen folder controls with relationships – these will be upgraded to entity container controls where the relationship becomes the filter. Folder controls without a relationship will upgrade to normal containers.
- Structural elements in rules – these are changed into comments
- Lists of values for input controls – these are converted into value lists. The data type of the collected attribute will be updated to use that value list and any visibility attributes defined for individual options will be migrated.
- Test scripts – each 10.4 test script (.tsc) will be migrated to a new testing document (.xlsx) and will use the test script name
- What-If Analysis – these documents are migrated to testing documents
- Translations – a new translations workbook is created based on the hidden language code in an Excel style with prefix “OPM – Translation” in the old translation workbook. If there are 2 or more workbooks that have the same language code, only the first workbook encountered will be used, and the others will be included in the v12 project folder ‘Others’.
TIP! Any rules that operate differently in v12 from v10.4 will be identified in Policy Modeling v12 in the Upgrade Issues window on the Rules tab.
Added components
The following components are added during migration:
- Identifying attributes – if an entity in v10.4 does not have an identifying attribute and there is not an existing attribute with text that is the same as the entity text, then a new identifying attribute will be created in v12 with text equal to the entity text. (If an entity does not have an identifying attribute and an attribute exists with text that is the same as the entity text, then this attribute will be set as the identifying attribute.)
- Relationship names – if a relationship does not have a name, then the old relationship ID will be set as the name
Migrated but ignored components
The following components are migrated but are ignored:
- Commentary files – these will be stored in the v12 project folder ‘interview-theme\resources\commentary\<locale code>’. There is no equivalent of 10.x commentary in 12.x. See Add interview help text for suggestions on how this could be implemented in 12.x.
- Non-rule documents (for example, design documents) – these will be stored in the v12 project folder ‘Others’
- Data model diagrams (.wmf) – these will be stored in the v12 project folder ‘Others’
In addition to the warnings identified in the migration log, there may also be issues and errors in the migrated project that you will need to address.
PRO TIP! If you have a lot of warnings it can be useful to use a generative AI tool to pull the warnings out of the log file into a csv file that you can work with. For example, you could use a prompt like:
I want the format to be:
date and time of task, task, warning
where:
‘task’ is the task that was being performed when the warning occurred (this is the “Migrating” type task that precedes the warning)
‘warning’ is the full warning message
For example:
09-Apr-2025 11:46:47.165, Migrating screen: Other People in Your Home, Warning: The landscape display style not supported for entity collect controls. This control will be migrated using the Portrait display style
There should be 50 rows of data as there are 50 warnings in the log file.
Here is the log file.
<copy in text of log file or attach it as a file>
Troubleshoot using the migration tool
If the Migrate Project dialog reports that the migration has failed, view the log for more information.
- If the log shows a compilation error (for example, “The project can not be migrated because the screen contains a compilation error”), resolve all compilation errors in the v10.4 project and then try migrating the project again.
- If the log shows a ”Unable to cast COM object type’ error, refer to the fix in Fix Commonly Encountered Issues In Policy Modeling topic.
- If the log shows a “Language ‘<locale code>’ is not available, this means that the language is one that is not supported in v12 (Arabic, Czech, Hebrew, Polish or Thai).
If the migration hangs at one point and fails to progress, try repairing your Microsoft Office (same steps as the “Unable to cast COM object type” error above).
If the migration log file is blank, this means that the migration did not complete successfully. Delete the ‘migrated’ OPM project in Windows Explorer and try the migration again, ensuring that Word is closed before commencing the migration.
If attempting to open the migrated project reports the error “invalid custom parse”, manually remove the invalid custom parse from the projectDataModel.xml file in the v12 project.
Access project migration support
If you identify possible enhancements to the migration tool that would make your migration much easier or faster, please raise an Oracle support ticket so that the Intelligent Advisor development team is aware. They may be able to enhance the tool.