• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
TSB Alfresco Cobrand White tagline

Technology Services Group

  • Home
  • Products
    • Alfresco Enterprise Viewer
    • OpenContent Search
    • OpenContent Case
    • OpenContent Forms
    • OpenMigrate
    • OpenContent Web Services
    • OpenCapture
    • OpenOverlay
  • Solutions
    • Alfresco Content Accelerator for Claims Management
      • Claims Demo Series
    • Alfresco Content Accelerator for Policy & Procedure Management
      • Compliance Demo Series
    • OpenContent Accounts Payable
    • OpenContent Contract Management
    • OpenContent Batch Records
    • OpenContent Government
    • OpenContent Corporate Forms
    • OpenContent Construction Management
    • OpenContent Digital Archive
    • OpenContent Human Resources
    • OpenContent Patient Records
  • Platforms
    • Alfresco Consulting
      • Alfresco Case Study – Canadian Museum of Human Rights
      • Alfresco Case Study – New York Philharmonic
      • Alfresco Case Study – New York Property Insurance Underwriting Association
      • Alfresco Case Study – American Society for Clinical Pathology
      • Alfresco Case Study – American Association of Insurance Services
      • Alfresco Case Study – United Cerebral Palsy
    • HBase
    • DynamoDB
    • OpenText & Documentum Consulting
      • Upgrades – A Well Documented Approach
      • Life Science Solutions
        • Life Sciences Project Sampling
    • Veeva Consulting
    • Ephesoft
    • Workshare
  • Case Studies
    • White Papers
    • 11 Billion Document Migration
    • Learning Zone
    • Digital Asset Collection – Canadian Museum of Human Rights
    • Digital Archive and Retrieval – ASCP
    • Digital Archives – New York Philharmonic
    • Insurance Claim Processing – New York Property Insurance
    • Policy Forms Management with Machine Learning – AAIS
    • Liferay and Alfresco Portal – United Cerebral Palsy of Greater Chicago
  • About
    • Contact Us
  • Blog

FileNet – Migrating to Amazon S3

You are here: Home / Amazon / FileNet – Migrating to Amazon S3

November 10, 2017

We had an interesting call with an insurance client yesterday currently on FileNet but looking for ways to start to move away from FileNet to a more modern solution, preferably in the cloud.  Their existing FileNet implementation was slightly unique in that they didn’t rely on FileNet to store any specific attributes about the document, instead storing all document attributes in their Claim Management system (based on Guidewire) with simple pointers to the FileNet F_DOCNUMBER as the FileNet Image Service unique id.  During our call, we came up with a simple solution to leverage the Amazon Web Services S3 storage to remove FileNet with minimal changes.  This post will describe that approach.

FileNet as an Object Store

Like most image storage systems, FileNet has a two distinct components to their API and content model.  The first component is for application data where attributes, security and data about the document are stored.  Clients will access the application data as part of searches to return a listing of documents to view.

The second component is the storage of the document itself.  Within the Application Data, FileNet will store an F_DOCNUMBER (think if it as an object id) that points to the document.  Growing up in the image world, FileNet built components based on the technology of the time.  For example, older FileNet implementations still store documents as separate page TIFF files (comes from the fax format) with compression and deliver these documents one page at a time.  At the time this approach was developed to reduce network traffic needed to see the first page but required lots of different entries into the database to identify each page.

Our client had only implemented the second FileNet component of the storage of the document itself within FileNet and had stored the F_DOCNUMBER within their own claim management system.  From the claim management system, if a user wanted to view a document, the system would launch the FileNet Viewer with the F_Doc_Number.  The FileNet viewer would view the document as well as allow annotations to be stored in FileNet.  It is important to understand that FileNet doesn’t control security or even know what document type is stored with the F_DOCNUMBER.

Replacing FileNet with AWS Object Store

TSG has been moving customers from FileNet for over 10 years.  Typically we focus on moving both the application data and the object.  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). Leveraging the capability of S3 to provide some basic indexing, the unique components of the FileNet migration include:

  1. Replacement of the multi-page Tiff documents to one PDF document.
  2. Migration of the FileNet annotations to Adobe XFDF annotations
  3. Migration of the new PDF and annotations to Amazon S3 object store with an attribute of the old FileNet F_DOCNUMBER included in the S3 Object Tagging.
  4. Movement of the application data in FileNet to the new ECM system (Alfresco or Documentum) and linking the Amazon S3 to the application data via the old FileNet F_DOCNUMBER or the new S3 object id.

In the case of our specific client, we quickly realized that we didn’t really need to do number 4 from above immediately if the client just wanted to swap out the FileNet object store with an Amazon object store.  In discussions with the client, they are considering moving away from their current claim management system and would look to move document specific attributes while gaining other benefits of a modern ECM system at a later point.

Some specifics on the new access would include:

  • The migration would store the FileNet F_DOCNUMBER as an attribute on S3 for both the document as well as the annotations. AWS S3 allows for up to 2KB of attributes per object.
  • The claim system would launch OpenAnnotate to view the object from S3 rather than the FileNet viewer. Annotations would be stored in S3 with Object ID, Annotation as well as User information.
  • We could consider a “rolling migration” where documents are migrated to S3 from FileNet on demand when accessed.

Summary

For FileNet or other legacy ECM implementations that are just treating the ECM system as a way to store files, 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 to cloud based storage and move away from an expensive on-premise FileNet installation.

Free FileNet Migration Case Study

Filed Under: Amazon, FileNet

Reader Interactions

Trackbacks

  1. Migrating FileNet with Daeja Annotations to AWS S3 says:
    August 8, 2018 at 12:34 pm

    […] is that the migration includes both documents and annotations.  In a previous post, we wrote about migrating from FileNet to AWS S3 and focused on how to move the documents with conversion of proprietary TIFF to PDF.  For this […]

    Reply
  2. FileNet Support to End in 2019 says:
    October 29, 2018 at 7:00 am

    […] of FileNet, there are simple ways to leverage cloud vendors as we mentioned in our article on how FileNet for one customer can be replaced with just AWS S3 while giving the customer all the benefits of a modern browser for viewing and annotation as well […]

    Reply
  3. FileNet Migration to Amazon Web Services – Why now more than ever? says:
    May 7, 2019 at 4:04 pm

    […] our related post as we worked with one client to design how they could move current FileNet content to S3 while continuing to link the content to FileNet.   We also posted on how we could move Deaja Annotations to AWS […]

    Reply
  4. FileNet and Content Manager (CMOD) Migration to Amazon Web Services – Why Now? — Technology Services Group says:
    January 3, 2020 at 10:47 am

    […] FileNet as a object store with all the meta-data stored in their own application. TSG has developed an AWS alternative leveraging our OpenAnnotate viewer to replace FileNet with a simple Amazon Web Services S3 Object […]

    Reply
  5. FileNet Migration – Not as hard as you think? — Technology Services Group says:
    January 23, 2020 at 2:48 pm

    […] the system is used in a “standalone” way that hasn’t evolved over time.  We noted in our FileNet – Migrating to Amazon S3 post in 2017 that, where FileNet is being used simply as an object store, some of the migration might not even […]

    Reply

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Search

Related Posts

  • 11 Billion Documents, 12 Months Later – Thoughts and best practices 1 year after our industry leading document benchmark.
  • FileNet AWS Cloud Native? Thoughts on recent announcement
  • The Deep Analysis Podcast – The 11 Billion File Benchmark
  • FileNet to AWS – An 80 Million Document Case Study
  • Migrating FileNet with Daeja Annotations to AWS S3
  • Alfresco and Amazon Web Services – Disrupting Legacy Content Services – Alfresco Day London – Keynote
  • Alfresco Guest Contributor – Documentum, FileNet & OpenText – should I stay or should I go?
  • ECM Roadmap – Thoughts on Planning for the Future
  • Alfresco – Amazon Web Services or On-Premise?
  • Amazon S3 – Viewing content fast and securely in-browser with the Alfresco Enterprise Viewer

Recent Posts

  • Alfresco Content Accelerator and Alfresco Enterprise Viewer – Improving User Collaboration Efficiency
  • Alfresco Content Accelerator – Document Notification Distribution Lists
  • Alfresco Webinar – Productivity Anywhere: How modern claim and policy document processing can help the new work-from-home normal succeed
  • Alfresco – Viewing Annotations on Versions
  • Alfresco Content Accelerator – Collaboration Enhancements
stacks-of-paper

11 BILLION DOCUMENT
BENCHMARK
OVERVIEW

Learn how TSG was able to leverage DynamoDB, S3, ElasticSearch & AWS to successfully migrate 11 Billion documents.

Download White Paper

Footer

Search

Contact

22 West Washington St
5th Floor
Chicago, IL 60602

inquiry@tsgrp.com

312.372.7777

Copyright © 2022 · Technology Services Group, Inc. · Log in

This website uses cookies to improve your experience. Please accept this site's cookies, but you can opt-out if you wish. Privacy Policy ACCEPT | Cookie settings
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT