1,126
edits
Difference between revisions of "Migrating From Filenet to Content Manager OnDemand"
Migrating From Filenet to Content Manager OnDemand (view source)
Revision as of 10:44, 30 October 2015
, 10:44, 30 October 2015Added empty directories bit.
m (Minor tweak.) |
m (Added empty directories bit.) |
||
| Line 26: | Line 26: | ||
== Considerations == | == Considerations == | ||
Consider the following items before starting your migration. Getting it right at this stage will mean a faster, easier, cheaper transition to CMOD at the end of the day. | |||
=== Converting Document Classes === | === Converting Document Classes === | ||
| Line 32: | Line 32: | ||
Content Manager OnDemand ("CMOD") has an entirely different architecture than the Filenet products. In CMOD vernacular, an 'Application' is analogous to an individual report. But in CMOD, the top of the hierarchy is the 'Application Group' -- a grouping of Applications (aka 'reports') where the index fields, storage, and retention requirements are all the same. Properly defined Application Groups can have multiple Applications (again, 'reports') that belong to it. The most rational way to design Application Groups is to combine reports together that fulfill a specific business need. Human Resources reports shouldn't intermingle with Accounts Payable (even if they have the same index fields), and are kept logically separate by keeping their reports in separate Application Groups. | Content Manager OnDemand ("CMOD") has an entirely different architecture than the Filenet products. In CMOD vernacular, an 'Application' is analogous to an individual report. But in CMOD, the top of the hierarchy is the 'Application Group' -- a grouping of Applications (aka 'reports') where the index fields, storage, and retention requirements are all the same. Properly defined Application Groups can have multiple Applications (again, 'reports') that belong to it. The most rational way to design Application Groups is to combine reports together that fulfill a specific business need. Human Resources reports shouldn't intermingle with Accounts Payable (even if they have the same index fields), and are kept logically separate by keeping their reports in separate Application Groups. | ||
=== Quantify index usage === | |||
OnDemand doesn't like to have indexes defined in the Application Group without a corresponding value appearing in the reports it processes -- it also wastes space inside the database. It seems common in the Filenet world to assign a report to a Document Class that has indexes configured that simply don't exist anywhere in the report. Yes, you can assign default values to the empty fields to get ACIF to stop complaining, but if you want to do this right, you'll want to look into your index usage. Not just which fields you're populating most often, but also which fields your end users are searching on. Eliminating unused fields from Application Group definitions will streamline indexing, reduce storage costs, and reduce complaints from end users at the end of the day. | OnDemand doesn't like to have indexes defined in the Application Group without a corresponding value appearing in the reports it processes -- it also wastes space inside the database. It seems common in the Filenet world to assign a report to a Document Class that has indexes configured that simply don't exist anywhere in the report. Yes, you can assign default values to the empty fields to get ACIF to stop complaining, but if you want to do this right, you'll want to look into your index usage. Not just which fields you're populating most often, but also which fields your end users are searching on. Eliminating unused fields from Application Group definitions will streamline indexing, reduce storage costs, and reduce complaints from end users at the end of the day. | ||
| Line 58: | Line 58: | ||
=== Reconciliation === | === Reconciliation === | ||
In order to reconcile the documents after the migration is complete, you'll want to have a unique identifier for each document that needs to be moved out of FileNet and into CMOD. Thankfully, FileNet provides a unique 'Document Indentifier' or "DocID" -- which can be loaded into CMOD by adding a corresponding field in the Application Group definition. The DocID field doesn't need to be added to CMOD folders, so it can remain invisible to end users, or exposed to a different folder to be used with existing tools that use them. | In order to reconcile the documents after the migration is complete, you'll want to have a unique identifier for each document that needs to be moved out of FileNet and into CMOD. Thankfully, FileNet provides a unique 'Document Indentifier' or "DocID" -- which can be loaded into CMOD by adding a corresponding field in the Application Group definition. The DocID field doesn't need to be added to CMOD folders, so it can remain invisible to end users, or exposed to a different folder to be used with existing tools that use them. | ||
=== Don't create unnecessary directories === | |||
When exporting data from Filenet, don't create a directory unless it's absolutely necessary. A number of empty directories will slowly drive you mad, as you try to determine if the directories are **supposed** to be empty, or if some data was lost, or if they were missed during a file copy or move operation. | |||
== Differences in Functionality == | == Differences in Functionality == | ||