I had a bit of a hiatus from the Domino.doc (DDM) to DOCOVA migration. Mostly due to a hold up on the client’s end signing the upgraded DOCOVA databases, which stopped me from being able to create the new destination libraries to house the migrated data. The upgraded databases were finally signed last Friday which allowed me to proceed with the next phase of the migration this week.
As I mentioned in my last post, I left off with the successful extract of the Manufacturing File Room using the IIUI DDM Migrator. This tool extracted the document meta-data and file attachments which our DOCOVA Migrator uses to import into the DOCOVA Libraries.
Carrying on to the next phase I began by creating a new Library to house the migrated data. In DOCOVA a Library is the corresponding destination for a DDM File Cabinet. In this case my Library was called Manufacturing to match the File Cabinet name used in DDM.
DOCOVA Migration Manager:
After my library was created I then went to the DOCOVA Migration Manager and set up a new import script to take the data extracted by the IIUI DDM Migrator and transfer it into DOCOVA. I mentioned the DOCOVA DDM Migrator in my earlier post, and promised to get into it in more detail later. There isn’t much to it. The DOCOVA Migration Manager is pretty straight forward.
1. Configure General Settings
The first step in configuring the DOCOVA Migrator is to configure general settings like the Notes server where the Domino.doc and DOCOVA installations reside, the path to the DOCOVA Home database, the path to the IIUI DDM Migrator main database, and the path to the IIUI DDM Migrator Working database.
2. Configure Library Mappings
Following the configuration of the general settings the next step is to configure the library mappings that tell the DOCOVA Migrator what DOCOVA Libraries correspond to each DDM File Cabinet. For example in this instance I was mapping the DDM File Cabinet Manufacturing to the DOCOVA Manufacturing library.
A Library Mapping should exist for each File Cabinet that is being imported, otherwise errors will be generated during the import. Typically a File Cabinet will be mapped to its own individual Library, but it is possible to map multiple File Cabinets to the same DOCOVA Library (in cases where the File Cabinets don’t contain a lot of data and you want to consolidate the information into a common Library).
3. Configure Document Type Mappings
Document Types within DDM are mapped onto corresponding Document Types within DOCOVA. The connection between what Document Types in DDM correspond to what Document Types in DOCOVA is configured in the Document Type Mappings section. For example, in my case I have mapped the DDM “Information Control Document” document type onto a corresponding Document Type of the same name that has been configured in DOCOVA. In addition, custom field mappings were set up to copy specific values from the DDM documents to corresponding fields on the DOCOVA document (eg. Marketing Part Number and Project Number)
4. Importing Data
The last step is to kick off the data import process by doing the following;
Select the Library Mapping record(s) that you want to run the import on
Select Migrate\Folders for Selected Libraries
Followed by Migrate\Documents for Selected Libraries
99.97% Success:
The import process ran for about 3 hours (comparable to the amount of time it took to extract the data initially). Interesting side note is that the time to extract and import is dependent much more on the number of binders and documents than the total size.
At the end of the process all but 2 documents had been migrated from the 6552 documents in the working database.
The DOCOVA Migration Manager logged exceptions for two documents saying that the matching folder in DOCOVA couldn’t be found. But when I looked in DOCOVA it was there. Turns out the problem was with the Binder Name. It contained a newline character at the beginning of the name which was causing the lookup key used to find matching folders in DOCOVA to not match.
Going for 100%:
So, how do I fix this to get a complete transfer? Well, I could manually transfer the two documents, but if I do that I lose all of the great audit history/version history from DDM that DOCOVA migrates for me.
The answer is to fix the data in the IIUI DDM Migrator and then re-import just the binder and the two missing documents. But I don’t want to re-import everything all again, I just want to bring in the two documents on their own.
To do this I used the feature in the IIUI Migrator to target a specific Binder. I created a new migration profile that targeted just the bad DDM binder and extracted the data to a different working database and a different local storage path.
This generated an extract for me that just contained the binder taxonomy and the two documents in the binder.
Now to clean up the data before re-importing it.
I ran an agent against the Binder taxonomy records and the documents to migrate in the working database to trim off any newline characters (@Newline function for Formula language, or chr(13) + chr(10) in LotusScript) from the Binder names.
Next, I deleted the existing folder in DOCOVA (since it had been created from previous ‘bad’ data).
I also deleted the Binder Category records in the working database. I did this because I didn’t want the import to try and re-create those Folders in Docova. The only folder I wanted created was the single one that I had fixed up.
This left me with a working view that contained the File Cabinet taxonomy information and just the single binder with a corrected Binder name.
I modified my DOCOVA Migration Manager setup to point to the new working database containing the binder and two documents, and then re-ran the import to DOCOVA.
Voila! No errors reported, and a new valid folder created containing the two documents skipped on the first pass.
Next Steps:
Now that the DDM data is migrated, the client is spending some time reviewing the results to validate it before we move the DOCOVA instance to the final production server.
