MEDIA
HELP
OTHER PRODUCTS
Two essential steps to migrate your legacy document management system
Does anyone still have an old, maybe outdated system, platform, or document management system (DMS) in their IT environment? We do.
In order not to name a specific manufacturer, I call it an exotic system. Why? Because it has been running for a long time and if I ask our apprentices (young people) they won’t even know what it is unless they have to work with it.
With “exotic systems” I also just may refer to the DMS that Gartner doesn’t mention in the Magic Quadrant for Content Services Platforms.
Source: Gartner Magic Quadrant for Content Services Platforms
So, you’re using one of those exotic DMS. And you’re thinking of replacing it but aren’t sure if it’s possible to export and keep your data? Here is an overview of what to consider. If you have any questions while reading, just contact us.
First step: Discover your source system
Discovery is the first step. Sometimes those exotic systems are “forgotten”: they just work but nobody really cares until a certain point in time. That moment could occur due to an IT environment cleanup, legal or end of life reasons.
At this stage, you must discover what you really have and how to deal with it. If the decision is to migrate the documents from the exotic platform to another, newer platform, the question is how to do it. Develop an ETL (extract transform load) tool, use an existing export function (together with an existing import function), or use a migration tool which can do that? In fact, the latter is sometimes a real problem because outdated systems often lack support, even from third party vendors.
Second step: Analyze the DMS more precisely
Analysis of the system capabilities and features is the second step. The first question here is how to technically connect to it. Does it have an export function (with all document features)? Does it have an API? A database?
In addition, the next question deals with the document management system’s features and functions like metadata, versions, relations, audit trails, watermarks, check-in/-out etc. In short: The more features a system has, the more complex a migration can turn out. A decision can be made when those questions have been answered.
3 proven ways how we solved DMS migrations
We conducted several migration projects with exotic systems in the past years and here is what we did:
- In most of the projects, when document features were limited to documents, versions, and their metadata, we used our generic database connector to extract directly from the database layer.
(You don’t know what a database connector is? No worries, learn more about our migration-center database connector here.) - In other projects we just used an export function of the DMS. Sometimes it also supported to save the metadata within an XML file, so we could use our file share source connector to pick it up as well.
- Finally, in two specific projects we had to develop a dedicated new connector. It was needed because there was no reliable export function and the DMS was quite feature-rich, so our database connector was not sophisticated enough.
However, the advantage – compared to building a completely new ETL tool – is that migration-center’s core with its transformation engine and the framework offers a stable foundation. The connector just needs to contain the logic for collecting the documents and metadata.
Roads to success
Now you know that there are different ways to connect even to the most exotic, feature-rich document management systems.
Check out our connector feature matrix for an overview of the migration paths (combination of source and target system) we support right now out-of-the-box and their functionalities.
And remember: customization is possible! Once you’ve built a new connector for an exotic DMS, it won’t feel that exotic anymore. We may also include the connector into our portfolio if we see the opportunity.
For any questions or further information just contact us.
Related blogposts
