We are currently engaged with multiple clients to migrate content from aging systems built on the UCM / Stellent platform. This post will share our experience and our approach to mapping all the existing content to its destination system.
History of Stellent / UCM
Stellent was a leading ECM offering in the early 2000’s with offerings focused on Document Management, Web Content Management, Records and Retention, and Business Process Management. The platform was adopted by over 4,000 customers across multiple industries including many Fortune 500 companies. In December of 2006, Oracle saw the opportunity to improve it’s stance in ECM through the acquisition of Stellent and purchased them for $440M.
Over the years since the acquisition, Oracle did not substantially invest in Stellant and was eventually dropped from the Gartner list in 2019. From 2019 Gartner magic quadrant:
This vendor is redeveloping its strategy for the CSP market. Its focus is the Content and Experience Cloud, a product primarily aimed at B2C use cases and most typically associated with web content management technology. Oracle is not actively promoting WebCenter Content, its on-premises CSP, to new clients.
With better options available from modern vendors like Alfresco, many clients are considering upgrading from old Stellant repositories to modern platforms.
Stellant / UCM Migrations – Not as hard as you might think
At its core, Stellant / UCM systems are relational databases with pointers to content stored on a server or network drive. As in any migration, the key activity is to gather requirements so that it is documented, what content and corresponding metadata needs to be extracted from UCM and how is that going to map into the object model of the target ECM.
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. Once the requirements are defined, we can configure OpenMigrate with a database / file system source and the desired target system. OpenMigate supports the following target systems, but due to the modular architecture new targets can be developed with relative ease:
- Filesystem
- Documentum
- Alfresco
- AWS/S3 and AWS/DynamoDB
- Azure/HDInsight
- Google/BigTable
- Hbase/Hadoop
- Solr
- Elasticsearch
- Veeva
The majority of the effort for this particular migration that we are currently engaged in is the mapping. When it comes to the metadata mapping, we are leveraging a wide array of mapping capabilities that OpenMigate offers including lookup tables, combining multiple source attributes into one target attribute, date modifications, and hard-coding values.
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 Stellant / UCM, a combination of the existing Stellant / UCM support resources as well as dedicated TSG migration specialists familiar with the Stellant / UCM architecture, the new repository, and OpenMigrate has proven successful.
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 – or content-less objects pointing to other records
- Corrupt Content
- Invalid File Names
- Missing Metadata
- Unknown File Types
To simplify Stellant / UCM 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.
There is one other unique challenge that this migration has provided which is documents in UCM which act as pointers or links to other content containing unique metadata, but share the same content. This approach was adopted may years ago as a hard disk saving architecture, but given the cost of a terabyte of storage today, the approach causes more headaches than the savings are worth. Our approach for these linked records is to migrate a copy of the content to the target system so that all records will have their own content and can be versioned without consequence.
Another example of bad data from this migration is that some date attributes were stored as text (not date objects) and in a variety of different formats. Through OpenMigrate configuration, we were able to convert these date strings to date values in the target systems.
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 Stellant / UCM, 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.
Conclusion
A lot of companies are looking to the future of ECM whether that is SAAS, Cloud, NoSQL, or simply a more modern and capable system. Leveraging OpenMigrate as a migration utility can ease this transition by minimizing impact to users, speed migrations through multi-threading, and complete migrations in one step directly from the source to the target.
Leave a Reply