How to Migrate Your FileNet Documents From an OSAR Jukebox to Magnetic Storage

  • Chris Aitchison
  • ECM

There a probably more than a few organisations around that have their FileNet systems still attached to a ‘Jukebox’. A machine with dozens of oversized optical discs that was best practice for enterprise-grade storage back in the 90s. In the last decade, however, magnetic storage has proven itself to be able to do everything optical storage could, at a fraction of the cost and orders of magnitude faster. A lot of companies are wondering whether they can move their data off of their old ‘Jukeboxes’ in order to save money in maintenance and increase system performance. If you are using FileNet P8, then the answer is ‘Yes!’

‘Yes, but very slowly’ is probably a more accurate answer. Our experience migrating documents from an OSAR tells us that if your documents average 30kb (an A4 B&W scan), then you can expect to be able to migrate at a speed of 200 documents per minute. Do you have more than 1 million documents? Then it is going to take more than a week. Do you have more than 50 million documents? Then the migration will probably take more than one year. I recently did a migration for a customer that took several weeks, so let me share how it worked.

The customer had a P8 4.5 system which used a jukebox as storage via FileNet Content Federation Services. The high-level strategy was to create two P8 File Storage Areas on a server with a high-performance RAID setup and migrate the documents from their existing Fixed Storage Area (the jukebox) using the Content Manager Java API. Before we started the migration, we ensured that the Default Storage Area Policy for all of the document classes the customer used was changed so that they were farmed to one of the new File Storage Areas. Once no new documents were being saved to the jukebox, we began the script.

migrate.java
1
2
3
  for(document:unmigratedDocuments) {
    document.set_StorageArea(fileStorageArea);
  }

The actual code we wrote was not that simple of course, but it is the basic concept. You will want to break the migration into independent batches, and you will want to do a lot of logging (both for compliance and troubleshooting purposes). The customer performing this migration shut down all of their servers each night for a full backup, so the migration script that we wrote had to accommodate that. Of course neither the customer nor me wanted me to be on-site for several weeks to simply supervise an automatic script, so we had to make it dead simple for the customer to start, stop and monitor. We did that by making it executable from the command line and verbosely logging everything it was doing so that it was obvious if it wasn’t working.

Slowly, but surely, more than 20 years of documents were moved from the jukebox to the new magnetic disks without issue. Once the migration was complete, we removed the jukebox as a Fixed Storage Area from the P8 Domain, and that was the last step required to render that amazing piece of 90s tech obsolete.