Okay so I read this and the statement below gave me cold chills....

Also, a good IT group will have a disaster recovery process which will
> include daily backups over the past several months, plus monthly backups
> which are likely retained for much longer. The end result - the Groupwise
> files, at a minimum, will be available until those backups are destroyed.


Is there something I'm missing here?  WHY would a "good IT group" or anyone
else be maintaining backups for disaster recovery for "the past several
months, plus monthly backups which are likely retained for much longer"?
If they're for disaster recovery, each monthly backup should be replaced
when a new one is generated, unless these represent incremental backups.
Also, why is is likely these would be retained much longer?  Disaster
recovery backups are to be retained specifically for that purpose, once the
information is no longer pertinent, the backups should be recycled or
destroyed.

The recent threads on changes to the FRCP and e-discovery should be making
it extremely clear to organizations that the decision to maintain
information longer than necessary and especially having documented practices
identifying that you do this as a routine "practice"are just begging for
trouble.

Second, from a digital preservation perspective - the data format will
> obsolesce over time. Because it is proprietary, the data format will
> probably obsolesce faster than the media or the technical environment. This
> will force an organization to make an archival/record management choice:
> does one preserve the bitstream until access is requested, possibly decades
> down the road; does one preserve the whole technical environment along with
> the original data format; or does one migrate from one data format to
> another so long as its authentic characteristics are maintained? The answer
> will be driven in large part by the digital preservation strategy and
> principles your organization has.


A second choice here, from a records maangeemnt perspective, is to identify
which e-mail records have extended retention requirements (typically, it's a
VERY SMALL percentage that are required for "decades") and migrate those to
some application neutral format, including all header information alnng with
any attachments, etc. to meet retention requirements.   Depending on the
environment you work in, you may be required to do this anyway (as an
example, 36CFR requires all Federal Agencies and their Contractors to move
any e-mail that is declared a record OUT OF the native e-mail application
and into an ERMS for retention).  By making this choice, you may limit the
volume of e-mail you need to convert/migrate.

Third, though I'm not qualified to respond from this perspective, software
> system replacement is a fact of life for large organizations today. The
> courts don't seem to consider email that's been migrated from one system to
> the next as corrupted or no longer authentic. Those migrated emails are
> still viewed to be discoverable and authentic. Now if the migration modified
> the content of those records or failed to migrate all of the records,
> whether by accident or deliberately, that would be a different story.
>

Which is why you must document any changes that could potentially alter
information, especially the metadata, when they occur.  This may not serve
as a "justification" to the courts, but it will satisfy the need to provide
evidence as to what happened and that it occurred in the normal course of
business.

Larry

-- 
Larry Medina
Danville, CA
RIM Professional since 1972

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance