Blogs

Three basic content migration strategies are:
 

1. Allow users to move documents on an as needed basis. This allows users to move the documents from their current repository to the new repository when the document(s) are needed. There may not be any other formal migration of content by IT or mass migration of content into the site.
 

2. Work with the users to establish a range of documents to be moved to the new repository – this is typically a date range as in all documents dated from xx to xx, or it could be all content in a current project effort. Users may move other documents left behind on an as needed basis. Depending on the amount of content to be moved, the vendor may need to assist with this effort.
 

3. Migrate complete repositories (file shares or other document management system repositories) prior to the new system going live. As this may involve very large amounts of data, there may be several options for moving the data. While not inclusive, the options are: set up a drag and drop move for a weekend as the move may take 24 to 36 hours; set up an FTP move that allows you to move files to an FTP site and then to the cloud application; send the vendor a backup of the files on a hard drive or the vendor may have its own mass migration service.
 

Ensure that all the content that is needed for day-to-day operations is migrated when the site becomes available. Timing this may require the migration to start days or weeks in advance of the site becoming operational.
 

Some additional notes are:

After migration has started, make the existing file shares (or document management repository) read only so that users are not able to continue to input new documents into the old repository. Make the existing repository available for a limited time (1 year) in order to encourage users to move all of the documents in a timely manner.

When the migration is complete or the old file repository availability time period has been reached, remove the repository from general access and back it up or delete it if legally possible. Check with legal on this for their comments.

As part of the migration process, clean-up of existing repositories should be considered prior to the migration. This will involve identifying and deleting files that are no longer viable documents such as the following:
 

1. Duplicate files that existing in the repository
2. Files that are past their retention period (but not on legal or audit or tax hold)
3. Files that are corrupt or otherwise not viable files (files with extensions that no longer have programs associated with them)
4. Files that have no owner and/or have not been accessed for at least a year (of course subject to any legal review to ensure the documents are not subject to a legal or tax hold)
5. Files that no longer have any business value and are not relevant to the business operation

Many recent studies have shown that at least 50% of all documents in any given repository can be deleted because they are duplicates, outdated, corrupted, no longer have value, no longer have an owner, or are empty files (created but not used). If you choose to migrate complete directories or repositories, consider doing a file cleanup as part of the migration strategy.

Migration may pose records management and/or legal issues that should be considered. In some cases, simply copying files from the owner’s repository to the CIM system may cause the metadata associated with the file to change – such as the owner/creator, date created, etc. From a legal point of view this is not acceptable (because the file’s metadata has changed) and the migration method should be tested and reviewed with legal prior to a migration plan is committed to and used.

Bud is the author of AIIM’s new training courses, “Managing Content in the Cloud”

http://bit.ly/174BAZ