Migrating From Filenet to Content Manager OnDemand

Scope

These are some recommendations and tips from my experiences migrating Filenet data to Content Manager OnDemand - since I'm not a Filenet admin, Filenet is outside the scope of this article -- this only deals with the OnDemand-specific tips and tricks to make your migration easier.

Nomenclature

This is the worst part of migrating between Filenet and CMOD, as some terms are used in both systems, but have different contexts and meanings. The process is complex enough without the added headaches of misunderstandings brought about by ambiguous terms.

Filenet Nomenclature

Document Class (aka "DocClass")

Defines the metadata used to find individual reports.

Content Manager OnDemand Nomenclature

Application Group (aka "App Group" or simply "AG")

A way of combining many different reports into a single group of data, organized by business need. Accounting reports for accounting, and operations reports for your operations teams. Reports that are bundled into Application Groups need to have the same index fields, storage hierarchy, and retention (ie, expiration) handling.

Application (aka "App")

Defines the type of document (AFP, Line data, PDF, Image), and how to collect search criteria (aka 'indexes') for storage in the database.

Multiple Applications of any data type (ie, AFP for customer statements, Line data reports generated by a mainframe, special letters or notices in PDF format, and incoming faxes stores as TIFF images).

Folder

The Folder in OnDemand abstracts the internal complexities of Application Groups and Applications, and presents users with the fields that they can search (which were populated into the database by the Application) and sets limits on their queries (maximum number of returned hits, fields required for searches, etc.)

Initial Considerations

These are items that should be given priority. Getting it right at this stage will mean a faster, easier, cheaper transition to CMOD at the end of the day.

Converting Document Classes

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.

Transfer in Original Formats

For some Filenet installations, upstream servers (or intermediate file transfer systems) convert report data (from EBCDIC to ASCII) and change the formatting of the report. Content Manager OnDemand doesn't need any data transformation, and can ingest EBCDIC reports (of fixed record length, stream, or variable record lengths) directly and without conversion. Some conversion tools (I'm looking at you, MQ Series File Transfer Edition) can be configured to change the report so drastically, that CMOD can't properly index it.

Wherever possible, remove any data conversion and deliver report data to OnDemand in its original format.

Image Overlays for Reports

If a report has a graphic "overlay" (like, an image with boxes around columns, or shaded bars, or graphic logos) this should be documented as early in the process as possible. In order for these overlays to be displayed on all platforms, line data reports will need to be converted to AFP. This will require any overlay graphics not in AFP format to be converted -- a process which can take a considerable amount of time to complete, especially if there is not someone available to do the translation 'in-house'.

Review Report Types & Audience

There's no better time to review the contents of reports, and refer with end users to determine which reports should be stored, indexed, managed, and disposed of in the same manner. Put on your Business Analyst cap and strap on your most comfortable telephone headset, because this is the most time consuming and manual part of the whole process.

Order of Operations

In order to find problems with reports as quickly as possible, follow these steps in order:

• Build a test / development Content Manager OnDemand Server
  • Make sure you have some extra temporary storage space to queue up incoming report data

• Begin delivering duplicates of the report data to CMOD, in its original format.
  • Make some test Application Groups and get some practise indexing these reports, and figuring out any strange or non-standard report types.

• Do you research -- everything under 'Initial Considerations'.
• Document your new structure - create new Application Groups, select the reports that will belong to them, and identify your sample data.