Merging two OnBase SQL databases

[Stephen_Beck]

I am working with a customer who currently maintains two separate OnBase systems which are each managed and maintained by separate departments.  An arrangemtn has been worked out with Hyland to merge these two systems into one.  Can someone direct me to some good information (preferably published) with guidelines, recommended prrocedures, best practices, etc. for accomplishing this?  One of the systems (which will be hosting the nerged system) has been upgraded to version 12.  The other system, to be merged with the version 12 system and then shut down, has not been upgraded beyond version 9.x.

Any assistance, advice, etc would be apprecoated.

Steve Beck

[Jay_MacVean · Accepted solution]

I'd start with a Statement of Work that defines what the objective of the merge are.  A total merge of users, permissions, WF, capture processes and queues, scripts and custom queries is probably fairly expensive.  On the other hand, just getting the documents out and back in via Export to DIP is fairly straight forward. As a project manager you'll probably have to put a price tag on each sub-section of what you define as "Merge".    WF export and Import handily gets the document types moved over but not folder creation and permissions or users.  

Its an interesting challenge.

[Nick_McElheny1 · Accepted solution]

If you go the Export to DIP route, and you're exporting multi-page TIFF files, I'd recommend taking a look at the "Export to DIP Imports Multiple Copies of Multi-Page TIFF Files" section of the DIP MRG so you don't inadvertantely end up with a bunch of extra TIFF files filling up the disk group.  Additionally, if I remember correctly, 9.x does not export notes when using export to DIP while 12 does -- so you may want to consider upgrading the other database to 12 before migrating if you're going to be using export to DIP to ensure that the notes are migrated as well.

Take care,

Nick McElheny

Trover Solutions, Inc.

[MichaelBertrand · Accepted solution]

In my eyes I would look at this project as any other conversion project. Unless you are bringing over the all the configurations as-is there will be some adapting to do  This means no changes to document types, keyword types, users, workflow configuration etc. As soon as something in there changes a simple Export-to-DIP will probably not work as well as expected. 

Some questions to ask and answer to help understand ho similar or different the new system will be.

- Are certain document types to be merged in to existing ones? If so are 100% of the keywords identical. 

- Are any shared keywords identical? Remember to verify datatype, length, masking, etc. 

- Are you transferring Notes? Do the note types exist, etc.?

- Do you need to transfer document, workflow history? If so you will (technically) need to engage Hyland Database Services. 

- Will you be extending the basic configuration to allow you to cross-check the import process? Here I would think of adding a new keyword that would hold the old DOCHANDLE, so you could verify that all the old dochandles are in the new system. 

- Do you do scripting or e-forms? Are your keywords referenced by name or by ID? 

As with all document conversion projects I have done, the most important part is the testing and the error recovery process. Because of the way Hyland deals with errors in the DIP files, it is much much much easier to make sure the data is good than to fix and verify errors. 

There are several other articles out there dealing with system conversions and some best practices. A search should give you some more information. 

[Jay_MacVean · Accepted solution]

I'd start with a Statement of Work that defines what the objective of the merge are.  A total merge of users, permissions, WF, capture processes and queues, scripts and custom queries is probably fairly expensive.  On the other hand, just getting the documents out and back in via Export to DIP is fairly straight forward. As a project manager you'll probably have to put a price tag on each sub-section of what you define as "Merge".    WF export and Import handily gets the document types moved over but not folder creation and permissions or users.  

Its an interesting challenge.

[Nick_McElheny1 · Accepted solution]

If you go the Export to DIP route, and you're exporting multi-page TIFF files, I'd recommend taking a look at the "Export to DIP Imports Multiple Copies of Multi-Page TIFF Files" section of the DIP MRG so you don't inadvertantely end up with a bunch of extra TIFF files filling up the disk group.  Additionally, if I remember correctly, 9.x does not export notes when using export to DIP while 12 does -- so you may want to consider upgrading the other database to 12 before migrating if you're going to be using export to DIP to ensure that the notes are migrated as well.

Take care,

Nick McElheny

Trover Solutions, Inc.

[MichaelBertrand · Accepted solution]

In my eyes I would look at this project as any other conversion project. Unless you are bringing over the all the configurations as-is there will be some adapting to do  This means no changes to document types, keyword types, users, workflow configuration etc. As soon as something in there changes a simple Export-to-DIP will probably not work as well as expected. 

Some questions to ask and answer to help understand ho similar or different the new system will be.

- Are certain document types to be merged in to existing ones? If so are 100% of the keywords identical. 

- Are any shared keywords identical? Remember to verify datatype, length, masking, etc. 

- Are you transferring Notes? Do the note types exist, etc.?

- Do you need to transfer document, workflow history? If so you will (technically) need to engage Hyland Database Services. 

- Will you be extending the basic configuration to allow you to cross-check the import process? Here I would think of adding a new keyword that would hold the old DOCHANDLE, so you could verify that all the old dochandles are in the new system. 

- Do you do scripting or e-forms? Are your keywords referenced by name or by ID? 

As with all document conversion projects I have done, the most important part is the testing and the error recovery process. Because of the way Hyland deals with errors in the DIP files, it is much much much easier to make sure the data is good than to fix and verify errors. 

There are several other articles out there dealing with system conversions and some best practices. A search should give you some more information. 

[Jason_King1 · Accepted solution]

Hi Steve,

I have performed this type of engagement quite a few times and each one was very different.  Michael's post is definitely the closest to the approach that I have used, particularly when looking at questions of migrating history etc.....and the issues of consolidation get very tricky!

In all of my consolidation engagements, a combination of custom scripting and OnBase tools were used, and with each engagement hard lessons were learned.  I would recommend contacting Hyland Database Services at the very least for consultation on this type of engagement so that you can sidestep the landmines that may exist.

Take care,

Beeker