Not a lot has happened the last few days regarding the migration of the remaining DDM Libraries. Partly because of some other projects I have been involved with, but also due to the fact that I have been struggling with getting one of the File Rooms to extract using the DDM Migrator from IIUI. I have been working with Matt Mangels at IIUI to try and resolve the problem. I’ll post more details on this next week.
Given that I am on hold at the moment to migrate my second DDM library, I thought I would take the opportunity today to upgrade the client’s version of DOCOVA given that a new version was available today. Why not? It should be good experience, as I have never upgraded a DOCOVA instance before (well, maybe once about 4 years ago 
.
As John Ryan (@_John_Ryan_) posted today in his blog entry, there is a new version of DOCOVA that has just been cut in preparation for general release.
I was eagerly awaiting this 2.6.5 release for use in my migration as it contains a number of features that are really important to a Domino.doc (DDM) migration to DOCOVA.
Communities and Realms:
The first new feature that is available in DOCOVA 2.6.5 is the aspect of Communities and Realms.
As John references in his post, in Domino.doc File Cabinets are grouped into File Rooms which are then grouped into Libraries.
With version 2.6.5 DOCOVA allows for the mapping of Libraries into Realms which are grouped into Communities. This ability allows clients to easily mirror their DDM environment in a migrated DOCOVA environment.
The following image shows a sample Domino.doc (DDM) hierarchy.
One thing to note is that the levels labelled “Binder Category” are simulated by DDM using a delimited category entry (eg. Manufacturing\Current). This makes it difficult to maintain consistency. DOCOVA on the other hand has the ability to create multiple folder levels.
The following image shows the same sample hierarchy as it can be configured in DOCOVA using the Communities and Realms feature.
Libraries are mapped to Communities.
File Rooms are mapped to Realms.
File Cabinets are mapped to Libraries.
Binder Categories and Binders are mapped to Folders.
Documents are mapped to Documents.
The nice thing is that DOCOVA doesn’t enforce the use of Communities and Realms, unlike DDM which required Library and File Rooms which in many cases made for an overly complex taxonomy for many companies.
One of the key items of interest to customers migrating from DDM to DOCOVA is the ability to streamline and simplify their taxonomies. DOCOVA allows for the migration of the DDM data without loosing any fidelity but allows for the easy manipulation and re-organization of information post migration to simplify and improve information classification.
Strict Version Control:
A second, and probably more crucial, feature of 2.6.5 is the inclusion of “strict version control”. One of the features that Domino.doc (DDM) supported was the aspect of strict version control.
One of the aspects of strict version control is that the numbering scheme for versions corresponds to major version numbers (eg. 1.0, 2.0, 3.0 etc) for all released versions of documents.
Minor revision numbers (eg. 1.1.0, 1.1.1, 2.0.1, etc) are reserved for unpublished or draft versions of documents.
Only a single published version of a document can exist at any point in time.
This versioning process better matches the versioning and numbering scheme used by DDM and as such was an important aspect for my DDM migration. My previous Library migration had taken into account the versioning and numbering requirements in an earlier version of DOCOVA, but the use of 2.6.5 ensures that subsequent additions and edits to data will match the versioning scheme used for existing migrated data.
Upgrading DOCOVA:
The upgrade process for DOCOVA turns out to be quite straight forward. It can really be boiled down to a few simple steps.
All in all, the entire process from start to finish took me about 15 minutes (including VPN time lag
For those who are interested, I thought I would jot down the steps involved.
Step 1: Update Design
First, I replaced the design of the three master DOCOVA databases with the 2.6.5 design templates.
These three databases are;
DOCOVA Home
DOCOVA Library Master
DOCOVA Archive Master
Following the replaced designs the databases were signed by a server id (or alternately by an administrator id).
These three master databases then take care of all of the remaining work of upgrading any libraries that may exist.
Step 2: Update Version View Column Configurations
Next, I opened the DOCOVA Home template database and copied the following three configuration records from the View Columns section and pasted them into the upgraded DOCOVA Home database.
The three view columns copied are;
Status No
Strict Versioning
Versioning Enabled
These new columns introduced in 2.6.5 support the use of strict versioning and provide additional data flags that allow DOCOVA to react accordingly to user requests based on whether strict versioning is enabled for a particular document type.
Following the addition of these new columns, the design of the library views were updated using the Update Views option in the View Columns setup area. This process adds the new view columns to any existing libraries.
Step 3: Update Libraries
Next, I opened the DOCOVA Home database to the Libraries view and selected to Update Libraries.
This option refreshes the design of any Library and Archive databases already created with the design of the new master copies.
Step 4: Enable Strict Versioning
Now that the databases and libraries have been updated the final step is to enable strict versioning on those document types that will be used to migration DDM documents.
One of the great features of DOCOVA is the ability to enable strict versioning per document type. For example, strict versioning may not be enabled for “General Files” document types, but is enabled for “Quality Assurance” document types.
Strict version control is enabled by opening the DOCOVA Home database to the Document Types section, editing a document type (eg. Information Control), and enabling the “Enable document versioning” and “Strict Versioning” flags on the Workflow/Lifecycle Settings tab.
Strict versioning can be enabled on as many different Document Types as required.
That was it. Pretty straight forward, even for a newbie.
Next Steps:
Revisit the DDM Migrator error with IIUI to try and identify what in this particular second File Cabinet is causing the initial export process to crash. No useful details in the log to help identify the culprit. Hoping Matt at IIUI can help with some additional debugging info.
I’ll post more on the error that I am running into in my next post.
