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.
Sometimes not the leading edge technologies are causing you headaches, but also solid requirements like synchronizing your Document object’s attributes with SAP.
In this blog post I will explain the differences and purposes of the OpenText Documentum Archive Services for SAP and OpenText Documentum Content Services for SAP as well as the challenge to synchronize only modified SAP data into OpenText Documentum.
OpenText Documentum Archive Services for SAP
The main purpose of the OpenText Documentum Archive Services for SAP (ASSAP) is to accept content (e.g. the printable bill) delivered by SAP. For this, the ASSAP exposes as ArchiveLink server. With the ArchiveLink protocol, SAP is not only able to archive content but also able to retrieve that content for display purposes. Such content can be for example billing documents. So the active part is SAP. OpenText Documentum is the passive part. The ASSAP will create the link information with SAP archive maintenance data.
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.
Despite the ongoing discussion about the prospects of new web technologies, progressive clients or even the need of an unmitigated new user experience, many enterprises are still using the “good old Documentum Webtop” quite contentedly. In general, Webtop applications integrate smoothly with other systems that have spawned over time such as Jive, Jira, CRM and others.
Nevertheless, let’s be honest. There have been some flaws and one of them has always been the content transfer mechanism UCF which can be hard to maintain especially in complex network settings and which causes an annoying dependency on the client’s Java Runtime Environment. With modern browser vendors reducing plugin support and the decision of Oracle to deprecate the Java browser plugin in Java 9, a new content transfer mechanism was long overdue.
Today we are back with a new issue of our blogseries on the development of our product migration-center 4. In this post I would like to focus on the “Analyze” part and show you again some screenshots of our new migration-center client.
As I have described in the first article of this series, the new user interface emphasizes our step-by-step migration approach of Analyze, Organize, Transform and Validate, and finally Import:
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.