A typical decision point when implementing any new document management system revolves around what to do with the documents and content from the previous system. In a perfect world, all of the old content comes along for the ride and works perfectly in the new system with little to no effort. However, let’s talk about the reality of migrations and leave “perfect" out of this discussion. This post aims to frame out the points that should be considered when deciding if you should migrate anything and what migration strategies you might use.
You should think about the expertise of your staff. To successfully implement a migration, you need experts that know both the old system and the new system and will be able to overcome the obstacles that they will inevitably run into.
In many cases, there are deadlines for when content must be moved due to software licensing/expirations, budgetary reasons, or other factors. If you face time constraints, be forewarned that until you get to the stage where you are running trial migrations, it is very difficult to know what gotchas will spin your estimate out of control. If you have the budget, it may be wise to hire an outside consultant/expert who can lessen the risk of these gotchas.
Depending on the software system previously used, you might have an API available that you can utilize in an export script, or the system might have some kind of “export" functionality that dumps documents to the file system and metadata to a flat file. You might even have some software tools that allow you to retrieve this data. As you evaluate your options, consider purchasing a tool to assist in the migration, but be aware that no tool will do everything; you either have to live with that or be willing to write scripts to make up the difference.
When a new software system is implemented, typically, it is your opportunity to change things to reflect new capabilities of the system and to reflect changes in your business process. This often means that the data captured in the old system does not always align with the data in the new system. So if you migrate the old data to the new, how will you deal with this mismatch? Is it possible to map old values to new ones?
Unless you have been using retention schedules in your existing software system the chances are good that there may be a lot of old/archived content that is not worth moving. You must consider whether this content can remain in the old system or if it can be exported to some offline type of storage. Obviously, this is also a good time to consider retention schedules for your new system.
Now that you have spent some time thinking about some of the migration considerations, what types of migration strategies might you use?
In a day-forward strategy, you leave the old content in the old software system and start using the new system for any new content starting on the day it launches. Typically you would put the old system into a “read-only" mode. You could implement a procedure where, if old content needs to be worked on, the user will pull it out of the old system and manually put it in the new system. This strategy is good when the content is cyclical with some renewal activity that happens on a periodic basis. Over time the content will be manually moved over. Additionally, you might be able to allow searching the old system from the new system to lessen the burden of retaining both systems. While this is obviously not a migration, it can be a time- and money-saving approach worthy of consideration.
A full migration, as the name implies, is where you move everything. This is the approach that most business people assume will happen when they start talking about the new system. It is important to understand the considerations outlined above and have dialogs with the users of the software system to understand if a full migration is genuinely needed.
By migrating only the active content you are lessening the volume of data that will populate the new system. This approach does not necessarily make the migration easier since you still have to deal with moving the content; however, it prevents the new system from being populated with invalid/unused content.
If the information architecture/data structures between the old and new systems are very different one approach is to create a “Legacy" area within the new system. In this approach, your new system would have an area or library setup that contains a structure that mimics the metadata and values of the old system. This makes the migration easier because you don’t have to have complex mapping rules between the old and new. This legacy area would be read-only and any new content would go into a new structure. This approach allows the old system to be taken offline but users still need to think about the fact that content created before a specific date may be found in the legacy area.
This approach may sound crazy, but the reality is that migrations are complex. During your investigation, always consider the fact that all of the work you put into automating the migration is typically a one-shot effort that is not used after the migration is done. You might consider automating part of the migration that is easy, but then having lower-cost labor handle some of the data population. This approach works well when you can set up explicit rules that the temp agency can follow.
The main point of this post is that software migrations are not easy. They are full of gotchas that can blow your time estimates out of the water. As I said previously, no migration is perfect, so be willing to deal with some compromises. Where possible, try to simplify your approach and educate the users on how the migration might work. In most cases, the users are willing to work with you on creative solutions you might have as long as you are not increasing the effort required to perform their daily duties. Finally, as you design your new software system, spend some time thinking about the fact that eventually, it will be replaced, and you will yet again have to consider your migration options. Is there anything you can do now to make your next migration easier?
At Contracts 365, we focus on providing easy and seamless integration for our Microsoft 365 clients. By leveraging your Microsoft investment, you can enjoy an unprecedented level of security while retaining complete control of your documents and data. We would love to show you a demo of how we deliver the most flexible, secure, and easy-to-use CLM software on the market today.