US-Amplify Blog
For many years TransVault has offered the ability to perform selective migrations that enable organizations to only move the data that is required to meet business and legislative retention needs.
But more often than not, when emails get migrated, we've noticed the tendency is to move everything. Why?
Fact 1: People don’t like to be responsible for deletion
Although most email archive applications offer lifecycle management, organizations (or rather, individuals in the IT department) are reluctant to ‘press the button’ when emails expire their retention date.
Often the legal department is not properly engaged with the process and does not give a strong enough directive (backing) to the IT department to delete records.
Similarly, although the IT department may have implemented retention periods, when it comes down to pressing the ‘final delete’ button, they err on the side of caution and just keep it anyway.
So the concept of not migrating all your archive (the inference being that you will somehow be getting rid of what is being excluded from the move - see fact 3) will most probably be a non-starter: your organization will most likely want to take everything if/when it migrates….
Fact 2. Culling your data prior to migration based on anything other than headline meta-data, such as date and custodian, is labor-intensive and risky.
Deciding what is ROT (redundant, outdated trivial) and what is not prior to a migration on any other basis than date and other high-level meta data is a job that I certainly wouldn’t want to undertake or defend at a future point in time.
Although it is technically possible to analyze email content to determine its value to the business, unless you have some really well-defined criteria that you can use to defensibly and reliably sift your data, you are entering into a murky world that could:
a) Be a huge time-sink for the legal department (and thus erode any time-benefit gained by performing a selective migration)
b) End up in a big and expensive 'fishing trip' working with an incredibly huge net across a huge body of data
As an aside, the latter is a big ‘no-no’ when it comes to eDiscovery: eDiscovery works on the premise that you cull data according to what is relevant to the specific litigation case in hand – and then drill down into content from there - and the latter is often done by a specialized and privileged review team.
Even if you decide to migrate based on headline data such as 'custodian', there's still 'gotchas'.
For example, if you decide to migrate just the emails belonging to staff in the ‘Investment Advisors’ department, you need to ensure that you move all past departmental staff - not just the current staff members. See our forthcoming blogs on best strategies for migrating leavers and handling the migration of envelope journals.
Fact 3: If you do a selective migration, don’t leave anything behind unless you plan to manage it properly.
If you decide to exclude data from a migration, you need to have a well thought-out game plan for managing its future. Just conveniently forgetting about it is a mistake.
Bear in mind that any data that isn’t migrated (perhaps you decide to put it into PST files and back it up, or keep it in a legacy archive), could be subject to a future eDiscovery exercise, which could prove to be difficult, time-consuming and costly - especially if it isn't readily available.
If you decide to delete this data, think carefully how you will do this (see next point).
Fact 4: Thorough deletion is virtually impossible.
We know through intimate experience that even though organizations might think they have ‘defensibly deleted’ records in their email archive (or purport to have lost them 'in transit') - other copies will often exist elsewhere. And don’t think that the courts are so naïve not to know this.
For example, most organizations backup their archives (onto tapes and other removable media). These backups may have not been properly rotated, and there may well be at least a window of 1 month where deleted data may still be recoverable, or an off-site copy that has been overlooked.
Also, backups of the archive server itself may have been created for testing and/or failover purposes and could still be lurking. This is not uncommon where the staff involved in setting this up have left the organization.
Another fact is that users may have created their own copies of emails and stored them in PSTs. PSTs are notoriously difficult to track and especially difficult to search at a content level, so an organization will not know whether there centralized deletion policy marries up with distributed data repositories.
See tip below,
In summary our advice is:
- Storage is cheap, migration technology is getting faster and lower cost
- Ensure you maintain chain-of-custody and get an audit - especially if you migrate to the cloud – you may need to be able to prove you have a full set of data in the event of an eDiscovery
- If you do a selective migration in a bid to reduce future eDiscovery times/costs, be aware that whatever is left behind may also be discoverable (and if it is in a last generation archive, it may be more difficult and costly to discover against). There will inevitably be costs involved in managing the data that is left behind.
- PST contents are becoming more easily discoverable and should also be considered in your migration/cleanup exercise
- Don’t assume that data deleted from your legacy archive is no longer discoverable.
And one final tip:
Technically speaking, the optimum strategy for defensible deletion is date-based. Although you may be able to delete archived records based on a range of criteria, the simplest and most effective way to properly delete your data is based on date. Why? Often archives store emails in date-based container files, so in the event that these files become disassociated with the archive (see earlier point on backups), or the archive server is no longer functional, you have a good indicator as to which container files you need to manually delete.
Originally Posted By Barney Haye, blogs.TransVault.com
