This brings up a really interesting point about migrations and metadata.
As it stands today, electronic archive migrations are expensive, time consuming, and fraught with lots of glitches. Regardless of what the vendors may say, most of the ECM systems have never been designed to have large quantities of data extracted and moved to a new system. (Why bother with this functionality since it would only help your competitors.) This is especially true of systems that have relied on WORM technology. In most cases companies will trade maintaining the metadata and records information for a cheaper migration. Not ideal from an RM perspective
As we move forward during the next few of years, we will start experiencing a whole new level of pain related to trying to migrate records management systems to new platforms. I see two general problem cases:
- Migrating an existing archive to a new platform where documents have been declared records. How do we preserve the record information when we are performing an Extract/Transform/Load operation using a tool that is not records aware?
- Migrating an existing records management system to a new records management platform. So we bought this cool records management system a few years ago and it does not meet our needs anymore and there is a new product from this other vendor that has some neat features we absolutely must have, but how do I migrate the RM system?
It points to fundamental flaws in how current electronic records management systems are designed. Since there are no real standards on interoperability, how can we move record pointers around as we move data between systems?
Tom Utiger
Data Empowerment Group
-----Original Message-----
From: Records Management Program [mailto:[log in to unmask]] On Behalf Of Mimi Dionne
Sent: Friday, February 27, 2009 5:14 PM
To: [log in to unmask]
Subject: Re: Metadata in the courts
Hi Peter,
Sure: as we migrated a record from the old system of record to the new, we were migrating in batches. In this particular case study, we lost the event/chron date + retention period. It ended up being a move into the the new system that did not have the...sophistication (ie. script)...to accomodate the original event/chron date plus the retention period at the object level from the former system. In essence, in the new system, it became a newly declared record. The old declaration time stamp was lost.
Mimi Dionne.
--- On Fri, 2/27/09, Peter Kurilecz <[log in to unmask]> wrote:
From: Peter Kurilecz <[log in to unmask]>
Subject: Re: [RM] Metadata in the courts
To: [log in to unmask]
Date: Friday, February 27, 2009, 7:06 PM
On Fri, Feb 27, 2009 at 7:48 PM, Mimi Dionne <[log in to unmask]>
wrote:
> For example, one of the issues I made management aware of was that the
> retention period started over after the migration successfully took.
Could you expand upon the above?
--
Peter Kurilecz CRM CA
[log in to unmask]
Richmond, Va
Information not relevant for my reply has been deleted to reduce the
electronic footprint and to save the sanity of digest subscribers
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present,
place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]
|
