Strategy and Planning for Migrations

By Carl Weise posted 07-27-2012 15:14

  

The following definition of migration is taken from ISO 15489, the international standard for records management.   It defines migration as the:

 “act of moving records from one system to another, while maintaining the records' authenticity, integrity, reliability and usability”.

So, we are talking about moving electronic records – AND about maintaining their integrity during the move – it is not a data dumb.   If you are moving electronic records to another system or archive institution, they must also remain usable.   Remember that records are still active until they are finally disposed of.   Even archived records can be searched and exploited, especially for historical or evidential purposes.

The migration plan and process consists of 4 key considerations.  Each of which includes one or more steps designed to ensure the migration is successful and is carried out as efficiently as possible.  The four considerations are:

Strategy and objectives

Planning

Preparation

Migration and post-migration

We will discuss the first two.  The strategy should first identify the purpose of the migration.  How the migration will be conducted, what will be migrated, and where it will be migrated to will all depend on the purpose to some degree.  These might include:

  •  A system is becoming obsolete.  Data needs to be migrated from the obsolete system to a current system. 
  •  Standardization.  Data is stored in one or more proprietary hardware or software systems or file formats.  The data is migrated from the proprietary format to a standardized one.  In some cases, the data might be migrated from a proprietary format to another one that has achieved some market dominance and can therefore be considered an ad hoc standard.  For example, data is migrated from 3.5” floppy disks to CDs, or from Wordstar 2000 to Microsoft Office 2010.   The latter remains proprietary to a significant degree, but it dominates the office productivity market and will remain readable for some time.

The next step in the strategy is to identify the stakeholders for the migration and ensure their needs are taken into account.  This will certainly include records management, IT, and legal. 

Now starts the planning process.

Who?  That is the first question on the list.   The Records Management Professional has a critical role in migration.   Although the migration is a ‘team effort’, everyone must look to the Records Management Professional to be in charge.   It is the RM who represents the user requirement, and understands most of the critical issues.

The actual migration is not carried out by one person, but only one person can take responsibility, and have the authority to make the transfer.   As the time approaches to start the migration process, that level of authority will be needed as users seek advice, reassurance and possibly ‘guarantees’ that their valuable information will survive the move.

It is likely that the work required will also rely on a system administrator or technical specialist who understands the electronic records management system.   Migrating records requires the right set of permissions and system privileges to allow the migration to proceed.   The same will apply at the destination system, in other words, make sure you have technical and system administration support on both the export and the import side.

However before migration can just ‘Start’, there should be a review and sign-off process, involving local records administrators and users, to make sure the records you start with are clear, consistent and complete.   If your source data is in order, you will have less to tidy up or remedy after migration.

Ideally, the classes and files to be migrated will be agreed upon and authorized by nominated users, who are responsible for the business information held in those records.   In cases where there is no clear owner of a file or set of records, the corporate records professional, or a nominee, should take responsibility for reviewing records that are due to be transferred.   It should be clear from corporate policy that the records professional has this responsibility, although it may be a similar designated executive such as senior archivist.

The next step is planning and scoping the migration.  This step includes a number of activities including determining the scope of the migration.

Some migrations will involve all of the records in the older system.  This is particularly the case when the system is to be decommissioned or when media or format obsolescence threatens access to the records.  Even in this instance, however, it is generally not necessary to migrate records whose retention period has expired.  These records should be properly disposed of. 

In other cases, it might make more sense to migrate only some of the records.  For example, the system to be migrated from is an old imaging system.  The files are stored as TIFFs, but not all of them are records.  Those that can be identified as records might be migrated to the records management system, while those that are not are simply disposed of with the legacy imaging system.  This decision needs to be made in consultation with legal and also with the other areas of the organization that access the system. 

Remember that any migration must include some or all of the migrated records’ metadata.   Records exported without their metadata would be poor records, indeed – without metadata it is difficult to search for information, for example, and it would be difficult to argue successfully that the records’ integrity and authenticity has been preserved.   When migrating to a new system, you need to reach agreement on what metadata will be transferred.  This is generally done on a case by case basis.   When migrating to an archive, the metadata involved may be negotiated or imposed on you, depending on the situation.   In either case, the way in which metadata is handled needs to be agreed upon.

Lastly, don’t forget the audit trails.   ERM systems do not generally have features for exporting and importing audit trails easily.   Standard specifications have never expressed this requirement because there is no standard format for audit trail data.   Several possibilities exist, including keeping the audit trail as a database off line, and keeping some or all audit trail data as one or several large records.   Remember to consider how you will demonstrate the integrity of the older records if you do not retain the audit trails somehow.

Tell us about your experiences carrying out migrations.

How have you been able to handle the audit trail?

Learn more by reading the AIIM Training Briefing on Electronic Records Management.  Click on the image to download and read.

I will be speaking at the following events:

August 14th – 17th, 2012  AIIM ERM Master class in Chicago, IL

August 21st– 24th, 2012  AIIM ECM Master class in Dallas, TX

September 18th– 21st, 2012  AIIM ECM Master class in Amsterdam

September 25th– 28th, 2012  AIIM ECM Master class in Silver Spring, MD

Click for more information about in-person and online Electronic Records Management Training.



#ElectronicRecordsManagement #ECM #Taxonomy #ERM #metadata
2 comments
252 views

Comments

08-02-2012 16:06

We have migrated content from various Livelink systems to SharePoint. From a practical point of view, it's usually just a small number of people who actually need to be able to view historical audit information. Therefore the cheapest way to migrate audit information is to migrate first of all the unique document ID from the source system with each migrated document and put it in a metadata field in the target system. This ID is also your key to audit records. Second, export all audit data you want to keep to a data warehouse and make it accessible to a small number of users through a search query based on the old document ID.

08-02-2012 16:05

We have migrated content from various Livelink systems to SharePoint. From a practical point of view, it's usually just a small number of people who actually need to be able to view historical audit information. Therefore the cheapest way to migrate audit information is to migrate first of all the unique document ID from the source system with each migrated document and put it in a metadata field in the target system. This ID is also your key to audit records. Second, export all audit data you want to keep to a data warehouse and make it accessible to a small number of users through a search query based on the old document ID.