Lotus Traveler supports Nokia S60, Windows Mobile and iPhone devices
Migration - Just how do you get off Dom.doc?
June 2011
Loyal Lotus Domino Document Manager (LDDM or Dom.doc) users are coming to a critical decision point. The product formally falls out of IBM support in September next year (View IBM Article Here), and most organisations simply rely too much on the environment to be able to remain on the platform under these circumstances.
Time Technology has been been involved in multiple migrations from Dom.doc over the past 12-18 months. We have helped business migrate to Documentum, Quickr and DOCOVA (www.Docova.com). These migrations have had their challenges, and some are still underway as I write this article. We have more than 10 opportunities for further migrations from this “love it or hate it” platform in our system today (almost all for DOCOVA, incidentally). As such, I felt it might be an interesting time to document our experiences to date and recommendations for those of you looking to migrate.
Below I have laid out the key steps in a migration along with a few of our own experiences.
- Understand and analyse the LDDM environment for existing customisation, workflow and security, and also the topology and size of the environment
- We have our own Migration Analyser to help us with this step. This gives us an indication of the scale of the migration but also determines if there are large usage areas within LDDM. The tool will also give an early indication of problematic documents (bad characters in filename, filenames too long etc).This tool can take a long time to complete on large environments, but is definitely worth it as it gives an order of magnitude to the size and extent of the migration.
- LDDM and the business: the role that LDDM has held in support of the business; addressing the business goals which may have changed since LDDM was brought in to the business and new IT direction may require new functionality. Discussing the use of customisation within LDDM and how the user interacts with LDDM
- Sounds basic, but the reality is that this is sometimes forgotten. Assumptions are made about the use of the system and the needs of the users, and consequently, a migration may be technically correct, but end up missing the mark with regards to the user needs.
- Consideration of key differences between LDDM and the new system. This will include security models, database structure, document spread i.e how documents are allocated across databases, document model, document functionality / workflow (versioning, check-in/out, lifecycle, metadata, searching) and interfaces.
- Key back end work as this will determine whether everything has been captured to ensure a successful migration. No two systems are the same and the differences need to be made clear. This will clarify what is being migrated and where it will end up once migrated, along with any compromises that might need to be made. Security and workflow in the new environment are also defined here along with customization required to achieve appropriate functionality.
- Review, and agree, the proposed mapping, functionality and security coming out of the previous step. This should take the form of a customer workshop.
- This is critical as all interest parties must understand exactly what they are going to end up with post-migration. End users should be involved in this workshop.
- Preparing for migration; data mapping, customisation, document types, workflow and security. Creation of test data and testing.
- This will include the creation of the new environment and any background tasks that need to be performed. It will also include the setting up of the migration tools being used (different vendor tools depending on receiving platform).
- Test migration of data. Initially this will be one or two cabinets into the new platform. This will allow for testing and confirmation from the customer that everything is as expected.
- This will prove the plan and show any performance issues of the migration (network deficiencies etc that could slow the migration down).
- Training and education using the new system.
- This is best performed once some real data has been migrated as per the previous test step. This gives users a much better sense of how the system will work with their documents.
- Full migration. This will often take a number of days to complete.
- Our experience is that difficulties will be encountered as documents are migrated. As such, this process needs to be monitored continually so that issues can be addressed quickly.
So, the underlying lesson is that one cannot take short cuts. Taking a disciplined approach where assumptions are minimised and users are involved will have a significant impact on the success of the migration.
For more information:
Call us on 01483 863000
E-mail us on sales@time-technology.co.uk
