Dieser Blogbeitrag ist nur in englischer Sprache verfügbar. | This blog post is only available in English.
IBM Notes has been around for so many years – yet still many companies use it. Some are heavily relying on it as it supports many different processes – it can be used as an email tool for communication, as a database with or without any kind of documents and even as a feature rich application for (critical) business processes and workflows.
Notes is flexible and supports all kinds of different and custom scenarios.
However, there are several reasons to replace it with other platforms, especially when it comes down to document management. I do not want to talk about them in detail because you might know those already and therefore are reading this right now.
I want to talk about the solution to move to other platforms and I want to clear up doubts about the possibility to lose any information during the migration.
First off: many companies want to get rid of IBM Notes but there are not many tools out there.
WE HAVE THAT TOOL
Years ago, we started a partnership with a Notes expert to build a migration-center scanner for IBM Notes, which is flexible enough to be able to migrate any kind of Notes application, any type of document and any kind of database. Migration means to extract all those information and transform it into new business objects suitable for another platform, while not losing any information – be it rich text fields, attachments, versions, links or any attribute value.
Our whitepaper about this topic contains even more information:
Whitepaper | IBM Domino Application Migration and Decommissioning
Let us have a closer look. Following we have the scanner configuration in migration-center 3.x.
The first four parameters “dominoServer”, “dominoDatabase”, “idFilename” and “password” are clear. We can enter a server url to directly scan notes items from the server or – as shown above – we have a local NSF-file to scan. A typical idFile and a password are being used to authenticate.
Then it is getting interesting: “primaryDocumentFormat” and “secondaryDocumentFormats” configure the output format for the files being extracted. That means that the document can be formatted into DXL, HTML, EML and even PDF (all generations). This is extremely useful if you want to get rid of Notes and cannot furthermore use DXL-files. It is also practical for archiving and having a general format, which is also readable in years to come.
Additionally to the primary output, you can even have multiple additional formats, e.g. DXT, HTML and PDF.
Next, we have the “exportCompositeItems”. This can be even more useful if you want to have certain elements not only within a document but also or instead as an extra document. The best example is an email body: you can create a document for the email body only while using all the email attributes (to, cc, bcc, from etc.) as attributes. With this, you can get entirely rid of the original document, which might be an un-editable, legacy format but still keep all information in the new system. This way, you can edit and work on the document in the new DMS, create versions and so on.
Finally and not to forget, we have attachment handling. The scanner can export all kinds of attachments of an email or any other document. They can be handled as separate documents (with the same metadata of the related notes objects) or as embedded objects in a PDF. That means you can create a PDF document with all information, all attachments and even links and URL inside.
After we have scanned all documents and extracted them to the “exportLocation” we have all documents and attachments extracted on that given files hare. Now we can transform all information to a new level and create completely free and flexible new document structures, folder structures and a complete new metadata structure.
PRACTICAL EXAMPLE / USE CASE
Imagine there are many Notes Applications, an email application and other business applications for instance. We want to migrate all documents but not all into the same repository or platform. Emails must be archived (e.g. for legal reasons). Other documents shall be imported into a DMS but only the ones that are still being edited. Older documents that have not changed in the last five years may go on into another system, maybe an OTCS or even a simple file share.
An easy task for migration-center: For the emails we want to archive, we scan the emails notes databases with a distinct scanner and put them into one migset. In this case, it can make sense to generate PDFs and embed all attachments into it.
We create the transformation rules as needed and simply migrate all documents as PDFs to InfoArchive as an example. Therefore, we are done with the email archiving and consider the other documents.
Then we go for the documents inside one or several notes applications and scan those into the migration-center. Here we create two migsets, one for the old (static) content and one for the “new” documents.
We configure the migset for the “new” documents with “Advanced Filters” so that documents that have not been touched for the last five years will be excluded.
We will then end up having only the documents left, which need to be worked on in a new DMS.
Again, we create individual transformation rules to get a metadata set for the DMS. After import, those documents will be normal documents in the DMS similar to those, which have been and will be created in the DMS. You can now go on working on them (like in the old Notes application).
The last task is to create a new migset for the documents, which have not been changed for the last five years, with other words: which are left in the migration-center because we have excluded them through a filter. To do this, just create a new migst and select all available documents (which we have excluded before).
Once selected, you may create different transformation rules, different attribute mapping and set the desired document format to fit into another place. It may be another DMS, an archive system or just another cabinet, workspace or folder.
What I have briefly descripted is a common task in companies nowadays with all the (changing) regulations, different requirements (for the different departments) and even more with mergers and acquisitions.
With that approach, we migrated emails with attachments (as PDF) to an archive system and migrated documents, which are of high interest in the daily work to a new DMS. We even migrated older documents, which are still important but not necessarily needed in the daily work.
With the migration-center mechanics you can do all kinds of things in terms of target, attribute mapping, document format and timeline.
Finally, it is up to you in which way and what time plan you migrate documents.