TSG is currently working with an insurance client migrating from DocFinity to the Amazon cloud. This post will describe how TSG is assisting the client move to a more modern solution with Amazon Web Services and specifically Amazon S3 leveraging our OpenMigrate migration framework.
DocFinity Background and Architecture
Owned by Optical Image Technology, a name reminiscent of older scanning and imaging technology of the late 80’s and 90’s, DocFinity has evolved over the years but still has some basic old-school components. Like most legacy ECM solutions, DocFinity has a two distinct components for their meta-data and content store. The first component is for meta-data is where attributes, security and data about the document is stored. Like FileNet or other old repositories, the DocFinity database only has one table where our client is currently storing the document with approximately 10 attributes. (DocFinity provides for up to 20 attributes)
For example – Table optimg01 includes
- user_key_1 – client is using this column for claim #
- user _key_2 – client is using this column for policy #
- ….
- user_key_20
- pg_id – unique id of the document
- pg_pgtp_id – Page Type (ex PDF, TIF)
Clients would access the application data as part of searches to return a listing of documents to view. Our client had built a custom web application to search against the (add table) to retrieve the results to their claim management system.
The second component is the storage of the document itself. Within the Application Data, DocFinity will store hash reference of the document id to give a pointer to the folder that stores the document itself. The name of the document is the pg_id + any extension from the pg_pgtp_id – (PDF, PNG…..)
From the client’s claim management system, if a user wanted to view a document, the system would query the database to return a list of documents that satisfied that query. Our client did not rely on any viewer but instead would download the document from the file store if selected.
Replacing DocFinity with AWS
TSG has been moving customers from Legacy ECM systems for over 20 years. Typical smaller migration involve moving both the application data and the object at the same time. For large scale migrations particularly to the cloud (this client has over 15 million documents), TSG recommends a two step migration where the documents are moved and later linked to either the new ECM repository or other locations.
For the DocFinity migration, TSG relied on the database mapping portion of OpenMigrate. We are currently retrieving the meta-data to store in Alfresco with the document storage being stored directly in S3. Client is planning on using a combination of either Amazon Snowball and Amazon Direct Connect to move the content.
One interesting newer feature of Amazon S3 is the ability to store information about the object in an S3 bucket. See the complete list of Amazon S3 features on the AWS website as well as specifics on Object Tagging (often called MetaData). For may migrations, TSG advises clients to consider adding both content and meta-data in S3 for both redundancy as well as to allow for access to documents outside of the Alfresco ECM content store.
While the client will be replacing their existing custom integration from DocFinity to leverage a combination of OpenContent as well as the OpenContent Management Suite specifically tailored for Insurance Claim and Policy Case Management.
Summary
For DocFinity or other legacy ECM implementations, Amazon S3 offers basic object storage with attributes along with the benefits of modern document formats and viewers at a cost effective price in the cloud. With an innovative approach, some clients may be able to move quickly with TSG’s OpenMigrate to Amazon cloud based storage and move away from an expensive and legacy on-premise DocFinity installation.
If you are interested in learning more about how to migrate from DocFinity, please contact us at https://tsgrp.wpengine.com/about/contact-us/.
Leave a Reply