Because Content Migration to a Document Management system usually involves a blizzard of details, it’s important to set your targets firmly and keep on track to producing usable requirements. An Environment Baseline represents a thorough, accurate description of the original content – both its structure and file distributions throughout the structure. By analyzing that baseline and characterizing its structure with the right amount of metadata, you define how to import that content, what meta data to associate, and where to store it.
- Target ROI for imported metadata.
- The import’s designer is “the customer” for requirements.
- Choose a simple, complete set of patterns.
These Requirements Guidelines are specific to a Content Migration project – for example to iManage WorkSite from PST files, or shared network folders. My notes on best practices for Requirements Collection are posted separately, but should be read side-by-side with this and the Environment Baseline post.
Target ROI for imported metadata.
Involve Stakeholders. Make sure that business needs guide the decisions of what to import, and what metadata and folder structures to retain. Ensure that all of the stakeholders are consulted in the discussion and are given the right weight in the decisions. What metadata is required to meet the business needs? Records Management is an important stakeholder, for both risk management and records disposal reasons. Before the content is retired by Records Management, who else will have an ongoing use for it?
How do these stakeholders find content today – ensure they can find it appropriately after import. Are they dependent on a folder structure, Windows Shortcuts, or search? Can newly-added metadata be used to find the content more effectively after it is imported?
Use ‘last edited’ and ‘last accessed’ information to validate who uses the content in its current location, and how recently. If the content is archival rather than active, it is probably less crucial to annotate it with detailed metadata.
Establish a data quality target – there can be a serious cost to building an import process that achieves 100% data accuracy. On the other side, don’t back down too easily: import is a one-shot opportunity to provide certain types of metadata in an automated way – there may never be an opportunity to retrofit metadata onto this content after the system goes live.
Do you really need the import to capture everything with precise metadata? Don’t go overboard collecting information that has no foreseeable use.
Do you really need the import to retain the exact prior folder structure? Don’t drown in a sea of details by trying to replicate something of no interest to anyone.
The import’s technical designer is “the audience” for requirements.
Discuss the format of the requirements deliverable with the developer, with an eye specifically to meeting the developer’s needs. There might be some easy changes to make during analysis and write-up that will greatly simplify the developer’s effort, and save on time, improve quality, or both.
Choose a simple, complete set of patterns.
As you analyze the environment baseline data, decide on the patterns to use for metadata descriptions. Your goal in defining the metadata descriptions is to describe the import data as efficiently and accurately as possible with a reasonable amount of effort. An import project will likely use a mixture of these as the scenarios warrant.
Your goal during the upcoming functional analysis and design is to
- determine what metadata to capture
- analyze the raw data enough to determine which of the import design patterns is appropriate.
Completing and verifying the list of rules or mappings is a design task.
This article is part of a series discussing many aspects of content migration from an unstructured storage system to a document management system.
The next article in this Content Migration Series discusses the import design patterns we have developed based on our experience.
The overview page is here: Content Migration to a DMS – Articles.