Are you looking to upgrade from legacy FDM to FDMEE? In the current release, 11.1.2.4, Oracle’s included a utility to migrate your existing application to FDMEE. You can read the migration guide here.

Note that migration from FDM 11.1.1.x and 11.1.2.x to FDMEE 11.1.2.4 is supported, except for those of you with FDM/ERPi versions 11.1.1.3 or 11.1.1.4, you are unable to use the utility.

Down to the nitty gritty, what does the migration utility actually migrate?

Screen Shot 2015-11-02 at 3.15.53 PM

Most notability non-migrated artifacts would be the scripts, and any import formats that utilize adapters. Any scripting has to be manually converted over from FDM to FDMEE, either by copying/tweaking the existing VB Scripting, or further converted from VB Scripting to Jython.

If you are ready to take the plunge, you can download the Migration Utility here. You must have an up-and-running FDM environment, as well as FDMEE and ODI Studio (comes with the FDMEE install) installed and configured to run the utility. Remember, just because this is a utility to do a migration doesn’t mean that it will 1) be absolutely seamless and 2) won’t require any additional effort. Judging by the migration utility guide, there are some definite clean-up steps and troubleshooting that need to occur after the utility is run to ensure proper functionality in your new FDMEE application.

Other things to consider:

  • You can configure in ODI Studio which periods/years of data you want to migrate – if you don’t want to migrate super old data, you can cut down on the amount. The migration utility guide has directions on how to configure studio to do this.
  • Data Drill Through needs to be tweaked for target applications after the migration:
    • Essbase – go through EAS and change Drill through Definition settings, import the
      DrillRegionXML.xml, and configure for the data regions applicable.
    • HFM – have to copy over and run a SQL script (aif_fdmee_misc.sql) for level 0 members.
    • Oracle Database – Drilling may not be available anymore.
  • You may have to delete any duplicate artifacts if you did the migration with a FDM/ERPi configuration. Best to migrate them and then delete after the upgrade vs. deleting them before migration.
  • Data files for the Inbox/Outbox do not get copied over. You can manually copy them from the FDM folder structure on the server to the new FDMEE structure. Then ensure any data files that may be automatically copied to the legacy environment now point to the new FDMEE environment (assuming you are continuing to use flat-files instead of FDMEE adapters with source systems).
  • Functional Currency for target applications may need to be edited in FDMEE after migration. Oftentimes the currency defaults to [NONE] instead of the actual currency member.
  • Control Groups and Process Explorer do not get migrated to FDMEE from FDM – but the functionality does not exist in FDMEE but actually in FCM – Oracle Financial Close Management, a totally separate product that requires other licensing and separate configuration.
  • Any “Check Rules” in FDM don’t get migrated over, so anything written in VB in FDM may need to be edited or migrated to Jython in FDMEE.

The migration guide goes into more detail on these points, and other suggested troubleshooting items if you run into issues. Overall, if you have a lot of data and configuration to move into FDMEE, this utility could be very useful. However, if you have a “light” FDM application or are doing a lot of tweaks/development in the upgrade, it may be easiest to just start your FDMEE implementation from scratch to save you from re-work.