For any organization that currently has FDM Classic deployed, an upgrade to FDMEE is an inevitability. FDMEE has vastly improved capabilities and it is the future of data integration in the Oracle EPM suite. I’ve had dozens of conversations with customers facing this change and want to share with you my thoughts and advice on this important topic.
A migration to FDMEE is not something to fear. That said, most upgrades – if done properly – should not be considered a simple task. Let’s assume that you’ve done your homework and you are aware of the FDM to FDMEE migration utility that Oracle has provided. Then your question might be, why do you say it’s not a simple task, there is a utility and that’s a fair question. To that question, this is my response.
The migration utility is the equivalent of the Hyperion Enterprise to HFM or Pillar to Planning utilities that Hyperion developed for those next generation products. They perform a simple lift and shift of the current application and port it into the new technology. In the example of Hyperion Enteprise utility, the elimination entities that were required to exist in the Entity hierarchy are duplicated in HFM even though HFM has a dedicated dimension for intercompany. Will the HFM entity dimension consolidate properly? Yes. Will the application perform as well as it could and use out of the box functionality instead of custom elimination rules? Probably not.
The same applies for a utility based migration from FDM Classic to FDMEE. All of the locations, import formats and other key metadata items will simply be recreated. The mapping tables will be ported as is. At first blush this may seem like it is not a problem. But consider this, most FDM applications have existed for years. There is very likely a lot of superfluous metadata and mapping in the application. Certain elements were built because there was no other option – either in terms of functionality or performance.
A common example of this is import formats that evaluated multiple source fields and created a “mapped” value. This was often done because varValues mapping in FDM Classic could be a significant performance drain. With FDMEE, Multidimesion mapping can replace approach resulting in an application that has more visibility and auditability into the mapping process. Moreover, the mapping process is no longer an administrator task (since scripts usually were not accessible by end users) and instead something that can be maintained by the end-user.
The migration utility does not account for these types of situations. In basic terms, it cannot take an investigative eye to the application and processes. It cannot look for inefficiencies in your application and correct them when migrating to FDMEE. It cannot purge legacy metadata that is no longer in use. So the question you should ask yourself is, does the migration utility provide value to your upgrade?
Before you answer that question, consider a few things. The migration utility does not convert any scripting – including mapping scripts. Even if you make the choice to stay with VBScript as your application scripting language (the topic of my next blog post), the FDMEE API is different from the FDM Classic API so all scripts need to be rewritten. The utility does not convert reports or security either since the mechanism for both of those is changed significantly in FDMEE and as such those items need to be recreated.
Given all of the information I have shared about the utility, I hopefully have convinced you to reconsider your migration approach. But I also understand that you may still be “on the fence” because no one wants to recreate the wheel. The good news is that yes you can leverage your existing application to rebuild FDMEE. You can take extract from your current application – at the database level or the Export to XLS functionality – as a starting point for the new application build. At Ranzal we have developed utilities that enable us to recreate common metadata elements from an Excel interface including mapping. This approach allows us to invest our time not in rebuilding the application but in optimizing it. The result is an application that is poised for growth over the coming years.
I hope this has given you a new perspective on migrating from FDM Classic to FDMEE. If you have any questions or would like to discuss your application in more detail, please contact us using the Contact Us section below.
