Contract Management Blog

Contract Managers and IT Need to Ask: Should I Migrate Existing Content into MY New System?

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. The purpose of this post is to frame out the points that should be considered when deciding if you should migrate anything and what migration strategies you might use.

Migration Considerations

Do you have experts on staff?
You should really think about the expertise of your staff. To successfully pull off 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.

What is the budget and timeframe for the migration?
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 are going to 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.

contract managers should consider for legacy data migration

How will you get the data/documents out of existing system?
Depending on the 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.

Will the information architecture/data structure change from the old to the new system?
When a new 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 typically means that the data that was captured in the old system does not always line up with the data in the new system. So if you migrate the old data to new, how will you deal with this mismatch?  Is it possible to map old values to new?

Do you need to migrate all of the content or just some of it?
Unless you have been using retention schedules in your existing 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 storage. Obviously this is also a good time to consider retention schedules for your new system.

Migrations Strategies

Now that you have spent some time thinking about some of the migration considerations, what types of migration strategies might you use?

Day Forward Strategy
In a day forward strategy, you leave the old content in the old 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 in which, 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 type of 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 that is worthy of consideration.

Full “Big Bang" Migration
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 system to understand if a full migration is truly needed.

Migrate Only Active Content
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 how to move the content; however it prevents the new system from being populated with invalid/unused content.

Migrate into a “Legacy" Area
If the information architecture/data structures between the old and new system 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 made 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 certain date may be found in the legacy area.

Hire a Temp Agency to Manually Migrate
This approach may sound crazy, but the reality is that migrations are hard. During your investigation, always consider that 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 setup explicit rules that the temp agency can follow.

Conclusion

The main point of this post is that 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 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?

Speak with Sales

Our Contract Management Specialists have no less than 10 years' experience helping clients address their contract related challenges. We'd love to help you, too! Get Started