Who hasn’t already made the painful experience of how bad communication has led to additional costs and reduced the quality of a project at the same time? We don’t want that to happen at all and therefore most project leaders today are very aware of the importance of communication within their project.
To help keeping your communication straightforward in a migration project, let’s have a closer look at the mapping specification as a crucial document in migration projects.
This is the fourth post of my series “Insights into the development of migration-center 4”. In the last post I showed you how to configure and run a scanner in order to read all the desired files and their metadata from the source system. In today’s post I will show you how to organize your scan runs into so called migration sets. All further processing in the migration-center, i.e. transformation, validation and import will be based on a migration set. So the definition of a migration set is an important step in the whole migration workflow.
When you press the Organize icon in the main navigation bar, the client shows you the list of existing migration sets. You can use the icons in the command bar above the list to create, edit, copy or delete a migration set.
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.
The typical migration scenario with migration-center is to read – or scan, as we call it – documents and their metadata from the source system (1), do necessary transformations on those documents in order to fit the target system (2), and finally write – or import – them into the target system (3).
Migration is an ongoing IT topic and there are many good reasons for that: Switching platforms or architecture e.g. when changing an operating system or database, virtualization and moving to the cloud are some reasons to be considered. In addition, the integration or merger of systems and applications can make content migration a relevant topic, as cost efficiency is a big deal in these cases.
Are you currently facing a migration project? Especially any Documentum migration task? Have your colleagues given you any serious advice to handle Documentum object IDs very carefully? A common example for that: Published links in intranet or e-mails referencing important documents through object IDs. Have you been asked to keep these documents’ object IDs and all their links working?
In this blog post I want to share some thoughts, experiences and solutions on migration regarding Documentum object ID concerns with you.
I’ve been in the Document Management System (DMS) / Enterprise Content Management System (ECMS) market for more than 20 years. Sometimes very focused on a specific aspect e.g. Technical Documentation, sometimes more general e.g. ECMS platform and sometimes with focus on an industry segment e.g. Life Science. I have seen a lot of vendors, products and technologies coming and going. The latest acquisition and certainly the biggest one was just a week ago. Hopefully, this will not reduce the power of innovation.
Interesting announcement from Alfresco. They started an aggressive > swap out program against Documentum pushing the fear that Documentum is going away or going south soon. First of all, Alfresco is a really good ECM platform – fme has been an Alfresco partner for many years. There might be good reasons for the one or the other company to decide to change their ECM platform within the next weeks or months, but it should have nothing to do with the OpenText acquisition. Fear has always been a bad advisor. Documentum is not going away any time soon, or why do you think OpenText payed 1,6 billion USD? They have to keep up the flow of maintenance money for quite some years to make the deal work.
Pretty much every “ECM expert” is giving us guidance and advice these days on the recent OpenText acquisition. fme group has been working in the ECM industry for roughly 18 years. We do consulting around platforms like Documentum (ECD), SharePoint and Alfresco. I will refer to the “Dell EMC ECD” business as Documentum. I never liked the acronyms that were used for the Documentum brand, anyway ;-). We have been partnering with Documentum for 17 years. Our focus industries are Life Science and Industrial Manufacturing. Across all industries we are well known for our migration expertise. We move content from pretty much every major ECM system to pretty much every other major ECM system, including OpenText and Documentum (> see our products director’s thoughts on this). fme group has seen quite a bit of the ECM universe. Here are my 2 cents on the recent OpenText acquisition – written after a two days and two nights quick assessment – so have mercy on me 😉
Unfortunately, that is reality far too often. The rollout of a new software takes place without integrating those people that should eventual use it effectively– namely the employees. But rollout projects are always change projects because the use of a new application normally is connected with process changes in the functioning of the employees. But why changing well-tried? That is what many users ask themselves and start using the new software with old and familiar processes. It is obvious that this is doomed to failure and the result is rejection and frustration from all sides. The solution: target-group-specific communication starting at an early stage.
There are different ways of how to manage documents using Document Management Systems (DMS). Which one is the best for your company? This blog discusses the question if it makes sense to manage the full document lifecycle in the DMS, or if only the most important document versions should be stored in a DMS, having the other documents created, managed and stored in other places.
I vote for the full approach. Why?
It is the collaboration idea that requires multiple users to work with the same document and have a full version history of information for all previous versions. The benefit of using a transparent chain of document versions is often underestimated. Even SharePoint technology is using this feature.
Document Management Phases
In the creation phase, Document Management Processes have special document access rights, which need to be considered differently, as you do not want to distribute the document to a larger audience, but at the same time you like to collaborate with the group of authors.
At this stage the system must be very flexible and user-centric. The focus here is on user interactions, where you prepare all meta-information in an intuitive way. This changes, when the document itself needs to step into a higher status and when leaving the authoring phase.
Now, it is more important that the document is following a workflow process for reviewing the document using the 4-eyes principle. And last but not least now follows the approval of the document for a designated business reason decided by a group of persons – the Approvers. read more