I'm just back from vacation and noticed the log-awaited migration utility has been already released :-)
I'm sure some of you have already gone through it and have your own feedback. Before I analyze and share mine with you I guess there are many questions on the table...
Is this the most suitable approach for my migration project?
Where can I download it?
Does the migration utility all I need?
Is it easy to use?
Do I need any additional manual step?
Is it a next->next utility?
Is this going to save time in my migration project?
Which is the ROI of this utility?
...
The migration utility has been released as patch 21379349 in MOS:
How will the migration utility executed? the migration process will be executed and monitored with ODI Studio :-)
What can I migrate? setup data (FDM metadata artifacts) and historical data.
All artifacts? NO. We will discuss which ones are included and which are not.
I guess you are thinking now...I don't have any ODI knowledge... then maybe you are not the right person to run the migration :-)
Let's go through the main points about the new migration utility.
Why migration is needed?
As you might know FDM and FDMEE have differences both in technical and functional sides. As migration involves mainly technical artifacts, it is not possible to provide an automated process to upgrade from FDM to FDMEE. That's clear. In deed, as I have already stated in other posts, YOU SHOULD NOT THINK about upgrading but migrating your FDM solution. Why? 90% of the times your application will be a good candidate to be analyzed and reviewed in order to evaluate if a re-design is needed.
What means re-design? To me, it means providing the customer the chance of having a FDMEE application with the best performance, maintenance and scalability balance. How we achieve this? Probably by using new features available (data load rules, multi-dim mappings, SQL mapping scripts, etc.), and of course by being able of detecting "not suitable" decisions made during legacy FDM implementation.
Supported FDM versions for migration
Migrations to FDMEE 11.1.2.3.x are not supported.
The following tables summarized supported versions for both FDM standalone and ERPI-FDM combined implementations:
To be taking into consideration
- In FDM, each application had its own database/schema and shared folder. In FDMEE, all the integration are stored in one database/schema. This unique database stores both FDMEE tables (artifacts, data, maps, etc.) and ODI repository tables (names starting with SNP)
- Oracle suggests to omit very old data to avoid migrating big volumes of data. Bear in mind that is not just a matter of having 5 years data but large number of POV combinations (location, period, and category)
- In terms of import format types, main difference is that FDM supports script and adapter types besides fixed and delimited files. The first two has been replaced in FDMEE with new functionality. They will partially migrated with this utility. With "partially" I mean that the utility will create main objects needed. For example, the import formats will be created. You just need to adjust them later accordingly. Scripting is on your to-do list :-)
- Script import format: in FDM you can import data using an integration script which mainly extracts data from a relational table/view. In FDMEE, this has been replaced with the Open Interface Adapter (11.1.2.3+). The new Universal Adapter for SQL tables and views will be released with 11.1.2.4.100. This new functionality will avoid the additional step of populating the open interface table.
- Adapter import format: they were not very popular due to not being flexible but FDM had some source adapters for EBS and SAP. However, one of the highlighted features of FDMEE is the native integration with ERP Systems. For example, GL balances can be directly imported from E-Business Suite or Fusion GL in a very transparent way. Others like SAP or JDE will do the same by using new functionality called Source Adapter which is basically an integration framework providing customization of the extract process.
- If you use ERP Integrator (ERPI) in combination with FDM you should know that migrating to FDMEE may incur in duplicated artifacts. As you know, ERPI was the little brother of FDMEE and had overlapping functionality with legacy FDM. For example, you could configure periods in both ERPI and FDM.
- If you have a new database platform in your new EPM system, the utility may not work.
How migration works
As stated above, the migration utility is basically an ODI process so the FDM artifacts and data are migrated by executing two ODI scenarios from ODI Studio.
Migrating FDM artifacts
The utility migrates the following legacy FDM objects:
In following posts we will go through manual post-migration actions needed.
Duplicate names
FDMEE does not allow duplicate names for key artifacts. In the case you have multiple FDM applications, the migration utility lets you add a prefix to FDM artifacts. In that way, you will avoid duplication issues during migration.
For example, if you have two FDM applications having location US_West, you can prefix location from each application so in FDMEE you would have Prefix1_US_West and Prefix2_US_West.
File delimiters
FDMEE just supports comma (,), pipe (|), exclamation (!), colon (:), semi-colon (;) and tab.
Any other delimiter used in legacy FDM will be converted to comma (,).
Watch out! this change will imply modifications in source files as well.
Migrating FDM data
You can migrate your historical data from FDM to FDMEE. This is something to be evaluated during migration...do you really need historical data in FDMEE? which POV combinations?
Is there are any other alternative?
Using "Excel Interface" will speed-up your migration process if you decide not to use the utility. With this new functionality you can export artifacts from legacy FDM, slightly adjust the excel generated, and import it into FDMEE.
Here you have the admin guide in case you want to have a look.
In following posts we will go through the installation and utilization of the utility, including manual steps needed :-\
Enjoy!
thanks for sharing such a nice posts.
ReplyDeleteRemo Recover Crack
Very nice post and looking forward to read other parts .Thank you for sharing.
ReplyDeleteHey. I am interested in what you've said about the possibilities for combined implementations of FDM. I am currently administrator for an environment where all products are version 11.1.2.1 and we use Classic FDM with Planning and HFM. We are interested in upgrading to 11.1.2.4, but have been given the impression by our current support provider that migrating FDM to FDMee is not that straightforward. Does what you've said imply we could for example have Classic FDM working with an 11.1.2.4 version of HFM and have 11.1.2.4 FDMee installed simultaneously and thereby gradually replace Classic FDM? Or would we still have to have and 11.1.2.1 version of HFM in order for Classic FDM to work? If so, what use is having combined installations of FDM and FDMee? Our support provider has said that Classic FDM and version 11.1.2.4 are not compatible.
ReplyDeleteHi Vincent,
Deletedid i say coexisting is possible in 11.1.2.4? where? If i did it's a typo but please point me to where you read so i can ammend
unfortunately you cannot have FDM classic and FDMEE coexisting in 11.1.2.4.
The last release you can have that configuration is 11.1.2.3.
So I would say that you have to keep your 11.1.2.1 and have 11.1.2.4 for FDMEE implementation
Thanks for your reply Francisco. Perhaps I simply misunderstood the intention of the tables you show under the Supported FDM versions for migration section. Re-reading those tables I suppose they are saying that migrating to 11.1.2.4 is the only "supported" migration. For some reason on first read, I thought those tables were implying which versions of FDM could co-exist.
ReplyDelete