Over the last 10 years, TSG has been helping clients migrate away from old, legacy FileNet systems. We started blogging back in 2010 and included updates in 2016, as well as our more recent success with over 4 billion documents in 2020. While TSG has always believed that there will never be an easy button for migrations, for this post we wanted to offer insights to show how migrating away from FileNet is not as hard as it might appear.
What makes FileNet migrations (and any migrations) difficult?
In our 10 Reasons there will never be an “Easy Button” for migrations post, we highlighted the following issues with most major migrations:
- If it ain’t broke…finding a compelling reason to move
- User Requirements and User Acceptance
- Migration Exceptions and Bad Data
- Integrations and Data Lookups
- Migration Resources
- Migration Content Updates/Changes
- Change Management for New System
- Migration AND Testing
- Differences in ECM Capabilities
- Audit Trail and Compliance
For this post, we will examine each of the reasons above and, while not finding an “Easy” button, will look for logical reasons to reduce the costs, stress, and concern about migrating from FileNet to a more modern repository.
If FileNet isn’t broke…don’t fix it – finding a compelling reason to move
Finding a compelling reason to migrate can be easier based on these significant arguments:
- IBM/FileNet Support is Expensive – While we have had some FileNet customers that no longer pay for support, those that do and/or are contractually required to have support for all software typically receive large bills from IBM. TSG had one client that had nearly a 1 year payback for the cost of the migration by eliminating IBM support. See our related post, FileNet – what is the business case to replace it?
- FileNet Support is Difficult – As we highlighted in our last article on FileNet support, both internal resources as well as resources from IBM/Filenet are hard to find and retain. The risk of being unsupported is a compelling reason to move.
- Old Platforms/Hardware/Software/Formats – Old technology brings old platforms and formats that are difficult to support or are subject to network security audits. These risks provide a compelling reason to move to modern systems rather than attempting to run old software on new platforms.
- User Efficiency – Older systems are not always built for how newer clients want to work. Justification can include increased user efficiency as TSG has demonstrated for claims processing.
When all the reasons above are considered, finding a compelling reason to move away from FileNet is not as hard as you might think.
User Requirements and User Acceptance
Legacy ECM systems that have been in production 10+ years typically fulfill a variety of different user requirements and have customizations that have evolved with the system over time. Functionality is often introduced as a major feature of the old system that doesn’t easily translate to the new system. Documenting and including all of the different user requirements from the old system can be a difficult and time consuming process.
One easier than expected surprise with FileNet migrations that TSG has observed is that most times 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 be noticed by the end-user. Those that have chosen to use FileNet “out of the box” will have an easier time building user requirements and user acceptance with new, modern, and user focused applications.
Migration Exceptions and Bad Data
Old systems typically have older documents. In running our large migrations for clients we have found:
- Bad File Pointers – content missing in source system
- Duplicate Data
- Corrupt Content
- Invalid File Names
- Missing Metadata
- Unknown File Types
To simplify FileNet Migrations, OpenMigrate has built in error correction and exception queues. When OpenMigrate encounters a bad data exception, the bad document is logged as an error, but the migration continues, rather than halting the entire process. For many simple FileNet migrations, we have been able to reduce the amount of data issues.
Integrations and Data Lookups
One of the reasons old ECM systems tend to stick around is that, over time, they have been integrated with a variety of different business processes. In order to “lift and shift” to a new system, all of the integrations need to be moved as well. Oftentimes the integrations were developed by resources that are no longer with the company and were poorly documented and maintained. One of TSG’s clients had over 60 integrations to their custom ECM system that had been developed over 20+ years.
TSG has multiple ways to simplify integrations and data lookups for FileNet including:
- Rolling Migration – many times we will simply migrate through FileNet to get the users on the new system to allow for additional time to migrate integrations to the new repository. See our related post on Reducing Risk, Stress and Cost with a Rolling Migration.
- OpenMigrate – OpenMigrate can process both bulk migrations and ongoing ingestion with the same level of consistency. Once the target system is configured for the new repository, OpenMigrate can be leveraged by a variety of integrations, providing a standard pattern for ingestion and data lookups for both bulk migration and integrations.
Migration Resources
To conduct a successful migration, resources need to be familiar with
- The old ECM system and data
- The new ECM system and data
- The migration tool
Too often, clients will look to leverage their existing resources familiar with the old system to both develop the new ECM system, as well as understand the migration tool. Typically these are resources that are still required to maintain the old ECM system. Internal resources often lack the experience in both the new system and migration tool to fully understand the complexity of a large migration.
For FileNet, we typically will recommend a combination of the existing FileNet support resources as well as dedicated TSG migration specialists familiar with FileNet, the new repository, and OpenMigrate.
Migration Content Updates/Changes
When moving content from one repository to a new repository, often the content needs to be updated. For example, many old FileNet systems stored multiple page documents as single page TIFFs to improve viewing performance given old network speeds. Typically a migration will involve combining the single page TIFFs into one multi-page PDF along with annotations, and is not as simple as just moving the files from one system to another. FileNet also has a proprietary COLD format that many clients have leveraged that requires special knowledge and tools to convert to non-proprietary formats.
For FileNet, OpenMigrate offers code and methods to move FileNet TIFF and COLD to PDF. For COLD, we discussed our approach in July of 2019 how to simplify the content migration.
Change Management for New System
Introducing a new ECM system will typically include a new interface and training for the users. Change management is critical for successful user adoption. Innovative clients have used focus groups and promotional campaigns to introduce the new system and celebrate the improvements to successfully avoid any issues with user acceptance and adoption.
TSG would recommend multiple methods for addressing Change Management when moving away from FileNet.
- Consider Pilot with Rolling Migration – One of the benefits of OpenMigrate’s rolling migration capabilities with FileNet is to not have to move all documents or users at once. Gradually rolling out the system can address the user adoption issues with smaller groups before rolling out to larger groups.
- Change Agent – Key to successful FileNet migrations has been a Change Agent focused on user adoption. Typically an internal resource pushing for better systems, the Change Agent is responsible for promoting the new system and the improvements it offers.
Migration AND Testing
Too often, migration efforts will shortcut testing of the migration approach, as well as the new ECM system.
TSG recommends parallel system efforts with FileNet to provide users with an environment to fully test out the new system with the migrated content. If content errors are found, the news system can be wiped and the migration (or parts of it) refreshed with a new migration. Testing should include both a sampling as well as a test scenarios for a wide range of different documents and content types. This approach is also compatible with a rolling migration approach where users can test with live data but the documents are not in the system of record yet.
Differences in ECM Capabilities
We often see that migrations are over-simplified down to just moving files and metadata. While most modern ECM systems can “check the box” for having all the different required functions available, most ECM systems implement those functions in different ways. Different components that might be very different between ECM systems include:
- Renditions
- Overlays and Annotations
- Security
- Versioning
- Object Model
- Folder Structure
- Lifecycle
- Workflow
- Audit Trail
- Relationships
Being an older system, typical FileNet systems do not have all of the complexity of more modern ECM systems like Documentum or Alfresco. FileNet P8 is more advanced than FileNet Image Services, but we have found that many clients, particularly financial services clients, have not used these more advanced features.
Regardless of complexity, OpenMigrate includes the ability to migrate renditions, overlays, Daeja Annotations, security, versioning, and complex object models. Typical FileNet systems do not include lifecycle, folder structure, audit trail, relationships or workflow.
Audit Trail and Compliance
When moving the documents, the compliance components of the new system need to be considered as well. One common example is the document create date. When created in the old system, the document create date was system generated.
With FileNet, when moving documents to the new system, the new system might automatically generate the create date as the date of migration. Typically TSG will recommend moving away from relying on system generated values to make migration easier and store and maintain create date in a non-system generated field maintained by the application.
Summary
While migrations will never be easy, the typical way that FileNet is being used at most clients simplifies the migration process. TSG can bring our experienced resources and a proven migration product, OpenMigrate, to address the many reasons that migrations are often not easy. (See our related post on Why do migrations fail – 12 Worst Practices).
With the right approach, software, and resources, moving away from FileNet can be easier than most FileNet customers would expect. See our related posts including:
- FileNet – How to retire in weeks rather than months
- FileNet – What is the business case to replace it?
- FileNet – Migrating from FileNet in 6 Weeks
Let us know your thoughts below
Leave a Reply