IBM has announced end of support for Domino Document Manager in September 2012, but the product hasn’t seen an update in more than three years. Customers are faced with a significant document (and system) migration effort. Migrating large numbers of documents can be expensive, risky, and time-consuming. So how can you help drive down expense, time, and risk?

1: Spend time in design

Invest time and effort in defining a document taxonomy that best reflects how your users work. You can still rely on tagging and alternate views to documents, but the taxonomy provides the basis for structured navigation through content. Put thought into document types and field definitions. Again, while these may change over time, it’s much easier to start with a solid foundation. If you are customizing your document management software, take the time to detail requirements, define use cases, and make sure you understand how your customizations affect future product upgrades. The time and effort you put into design will pay for itself many times over during the life of the product.

2: Automate, automate, automate

Automation is the only option for moving content in a structured, repeatable, and measurable way. Ideally, the migration process is profile driven. At a minimum, the profile should define: what gets migrated from where; metadata field mappings; and optionally, any required metadata transformations. Automation makes it easy to have large volume test runs to help identify source data issues (e.g., key metadata fields missing). Automation drives down the cost of migration, the risks of migration, and the time it takes to get to end of job.

3: Strongly consider open source alternatives, but do it for the right reasons

There may be cost savings associated with open source document management solutions, but this shouldn’t be the sole motivator. Just as important, I’m convinced that the value of open source document management software derives from:

  • The community and its ability to guide product direction through requirements and code contributions.
  • The ability to extend and modify the document management platform to meet customers’ unique business requirements.
  • The control you gain from having the full source code.

But be careful. The type of open source license is very important, so do your homework (LGPL, for example, is preferable over GPL) or you may have unintended and unnecessary restrictions placed on your use of the software. It is also essential to select an open source provider that can provide the level of support and maintenance contracts demanded by your business, and one that has a vibrant partner community for local support and implementation.

4: Look for embeddable document management

The product you adopt should have support for REST and Web Services to enable you to integrate document management applications into existing applications and to create new composite applications where document management is one function within a more complex system. Using this approach, enterprise document management capabilities can be stitched into the fabric of every application that needs to store and control document objects and breathe new life into existing software assets.

5: Maintain document security

If you spent time thinking through design, it’s likely you put a fair bit of thought into folder and document security. But even with this effort, there will be times when access rights and roles need to be modified en masse, for example, when companies reorganize or become subject to new compliance regulations. Administrators must be able to make automated (controlled and audited) mass changes to folder and document security. Apart from sparing the time and effort of manual maintenance, automated document security changes can reduce the risk associated with manual changes.

Bruce Grant is partner and president of metaLogic. He leads metaLogic’s open source consulting practice (Nuxeo ECM, Liferay Portal) and the IBM Websphere/ Portal practice.