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.
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.
Every document management system’s core is a database.
I do not know if that is true for 100% of all the systems out there but it is definitely true for all DMS I have worked with. Beside, as a content migration consultant, I can tell that nearly every company has data (somewhere) inside a database.
Very often, I face the case that we have to migrate a legacy ECM system (based on a database) for which our product migration-center does not have an out-of-the-box-connector (see our target platforms). Such an OOTB connector is often the best solution for feature rich ECM systems because native connectors are typically able to support the features of an ECM system as best as possible. This applies in particular to features like relations, version, virtual documents, comments, renditions, annotations etc.
The development of migration-center 4 is moving forward. In today’s post I would like to show you two of the new basic configuration screens that we have designed in migration-center 4.
(English version below)
Dies ist der erste Beitrag einer kleinen Artikelserie, die einen Einblick in die Entwicklung der nächsten Hauptversion unseres migration-centers (MC) geben soll. Ab sofort werden wir an dieser Stelle neue Funktionen, Funktionalitäten und Verbesserungen vorstellen, auf die Sie sich freuen können. Im ersten Teil der Serie geht es hier um die neue Benutzeroberfläche.
When introducing new systems or adding new areas to a new system usually data migrations are needed to integrate the data from the old system or other areas into the new system. During such data migrations often a migration tool is used to get the data from the source into the target system. This migration tool transforms the data to be compliant with the new system and imports the data into the system.
In such a scenario generally these questions come up: How to validate the data migration? Do we need to validate the tool itself? Do we need to validate all details of all rules and functionalities that are available in the tool and could be used in theory?
The implementation of a standardized DMS like D2 or the > Dell EMC Documentum Life Sciences Solution Suite requires the migration of documents from the old to the new system or a transforming of the data model within the system in order to work properly with the new application. Often this old data is not fully standardized and structured, but either based on a less controlled system such as Documentum Webtop or on a controlled system with slightly different structures such as CSC FirstDoc or Cara.
Why migration-center 4.0?
The new major version 4 of our proven migration product is currently being developed and will be released in 2017. Version 4 comes with a new and modern user interface, great new user experience and a lot of new functionality that will make your migration team even more productive. The motivation to develop a new major version of migration-center have been the architectural and technical constraints of version 3 that inhibited major improvements in the areas of usability, customization, performance, functionally and custom jobs support (pre & post processing.
New technologies used
The modernized migration-center job server’s architecture will allow multi-threading in all adapters, easier adapter deployment, and the integration of any kind of custom adapters or jobs – so you can expect faster migrations and support for new use cases. The job server and the client will use state-of-the-art REST web services for communication instead of proprietary protocols, making it even easier to implement custom adapters/jobs.
Document management is no longer greenfield terrain. By now many companies have already determined their need for a document management system and understand the benefits it offers them, especially in the Life Sciences. For this reason, nearly every company dealing with mission-critical documents has implemented some sort of solution in recent years.
The question that is now more likely to arise is whether the performance level and user friendliness of today’s system are still adequate, and/or capable of meeting growing requirements. And it could be that other providers have developed a newer, more attractive solution.