After a break for the Easter holiday I got back into the groove today with the DDM->Docova migration and made some good headway.
Serendipity:
The day started of with a good omen. An invitation to an IBM sponsored webinar hosted by Dan Lieber ( @danlieber ) and Matt Mangels of IIUI on the new 8.5 version of the Domino Document Manager Migrator.
Matt and Dan went through the features in the new version along with a demonstration of the tool and coverage of some common trouble points.
Some of the key things I learned this morning about the new 8.5 DDM Migrator.
Requires Notes/Domino 8.5 if migrating to Quickr, but if migrating to alternate sources such as DOCOVA Notes/Domino 7.x can be used (this is good because the server I am migrating from is version 7).
Running a notes client at the server is supported provided it is a separate client install and not the nlnotes.exe basic client installed with the server (using nlnotes at the server will result in API/process contention and can result in instability).
New version of the Migrator supports folder level security (includes color coding to show binder security).
Improved support for long file names in the new version.
Modified XML output format in the new version.
Support for migrating bookmarks in the new version.
When migrating DDM, you can migrate to a single working database, but multiple dbs are recommended to improve testing and allow for staged migrations.
Close working db window tabs when finished working with them before going back to the migration profile. Otherwise “things get funky” according to Dan.
The issue with having to select a Quickr host url when trying to export to XML instead of XML has been corrected.
I am making a lot of references to the IIUI migrator in my posts, and with good reason, this tool is really invaluable for anyone looking to migrate from DDM.
Striking While the Iron is Hot:
I had some additional good news waiting for me in my inbox this morning. The client had been able to provide access to run a Notes client on the server through remote desktop rather than running it from my machine over VPN.
So, following the morning webinar I logged in to the remote server and loaded up the Notes client on the server and got busy with where I had left off from last week.
Returning to the IIUI Migrator I opened the migration profile and ran the “Create Document Profiles” step which reads the individual DDM document entries and exports them to the working database and extracts the file attachments to a local file system location. The extract of the File Cabinet document (1300 documents) meta-data and file attachments (9GB) completed in less than an hour this time. Much nicer.
There were a few rain clouds however to mar the start of a sunny day (figuratively sunny, it was actually raining today). The export process had generated errors.
Specifically it had flagged 5 items that could not be exported. Examining some of the details recorded in the error log showed details like those in the following image.
Not very descriptive. “Unidentified problem” However it did provide a UNID for the document located in the DDM File Cabinet.
Using the UNID listed in each log entry I was able to open the all documents by unid view in the File Cabinet and perform a search to find the matching source records.
At first I thought the issue was with documents being checked out, as the first few documents I examined in DDM showed as being checked out by a user. But a test of this theory by checking a document back in and then trying to export the binder (I targeted a specific binder so as to not have to re-extract the entire cabinet) again still gave the same error.
That led me to make use of the diagnostic feature in the IIUI Migrator. The diagnostic feature is enabled in the migration profile through the action menu. It is normally disabled for performance reasons as it can generate a large number of additional log entries. I again ran the export for a particular binder containing problem documents and went back to examine the logs. The log entry just before the error showed that a file system path was being built using the binder category and binder title. The revealing thing was that the path showed an extra space at the end of the binder title. This resulted in a file path being generated in a form like “D:\DDMMigration\Engineering\Mechanical\Drawings \drawingxyz.pdf”. This was leading to an invalid file path that was causing problems for the extract. An examination of the other 4 documents throwing errors showed the same pattern. An extra space at the end of the binder name.
One option available to me was to correct the binder names in DDM to remove the trailing spaces. However, I remembered that the new version of the IIUI Migrator had changes relating to folder paths and so decided to give the new version a try first to see if it handled the extra space issue any better. I uploaded the new version to the server and re-ran the export on a problem binder. Voia, no error. When I examined the output directory, the previously ignored file attachments had been extracted successfully.
I cleaned out my working database, deleted the extracted local files (if you don’t delete the prior run data files get duplicated) and ran the export again, but this time on the complete File Cabinet. Again, no errors logged for any documents.
So the rain cloud threatening my sunny day was a fleeting one.
Now For the Fun Stuff:
What, haven’t we been having fun already? Of course we have, but now it just gets more fun!
The next step is to take the extracted DDM data and move it into its final home in DOCOVA.
To do this I make use of the “DOCOVA Migration Module” database.
This database essentially does a reversal of what the IIUI Migrator does, but instead of taking data out of DDM into a secondary source, it takes the data from the secondary source and puts it into DOCOVA.
The DOCOVA Migration Module re-creates the folder structure and Taxonomy based on the data extracted from DDM. As well, it imports the associated DDM documents and files and sets all of the required security and status information.
Before initiating the DOCOVA Migration Module import process you must first have a DOCOVA Library set up and configured. I had already set up a library for Sales and Marketing and used this for my import.
You also need to set up an import mapping. I will go into more details on this step in a later post.
The resulting import into DOCOVA took just over an hour. So the timing to extract and to import appears to be roughly the same.
No errors generated during the import. Good stuff.
I logged into the DOCOVA web interface to view my handiwork.
Drum roll please….
And, there was my library, with a perfect folder structure/taxonomy based on the DDM extract.
There are a couple of things to note about the way that DOCOVA handles DDM binders/categories. First, as I mentioned in a previous post, the folder structure is created based on the binder category and binder names contained within DDM.
The second is that any entries that do not have a category assigned appear under the “(Not Categorized)” folder which is created to hold them.
In DOCOVA documents always belong to a folder/taxonomy.
Next, I expanded a particular folder and examined the documents contained.
Each of the documents from the original DDM binder were present in their released state, along with any prior unreleased versions.
So, my first DDM->DOCOVA Library migrated!
All and all a very sunny day. Now if only the weather would cooperate 
Next Steps:
My next steps will be to do a bit of additional validation to ensure that all of the DDM documents were transferred properly and with the correct settings.
Following that I am going to migrate the remaining Filing Cabinets.
Stay tuned.
