If you have been in the legal technology business for a while, chances are you have been involved in at least one document management system migration or upgrade. My first was in 1996, helping to move a firm from Soft Solutions to DocsOpen. Twenty-something years and at least a dozen projects later, I’m here to share some lesson learned in the trenches from countless projects by ILTA members.
User Involvement and Training is Key
There are few projects where user buy-in is more important than a DMS migration. “Make sure you take the time to do a pilot!” says Jim Struve of Belin McCormick, P.C. “Up-front involvement in configuration, and buy-in from pilot participants will help smooth the inevitable ‘why can't I do [blank] like I used to?’ complaints.”
It can be difficult to budget the time and effort required for pre-migration testing by users, but the payoff is well worth it. The folks who will use your DMS to its fullest, like paralegals, secretaries and associates, will find things in their testing that the technologists will never see. Their input is invaluable both for finding problems and for identifying areas where extra training or configuration may be needed to make the system more user friendly for the rest of the firm. As a bonus, any group that you involve in the initial design and testing phases can become champions of your project around the firm. Once people have had a hand in designing and planning, they then have a vested interest in seeing the project succeed. This will pave the way toward a successful migration and help take the edge off the inevitable bumps and problems you will encounter along the way.
In my firm’s migration from iManage to NetDocuments, we assembled a group of volunteers to help us design the layout of matter workspaces. They really helped us understand how folks interact with the DMS and what they need out of it. At the same time this group got advanced training on workspace design and content searching. By the time we actually cut the firm over to NetDocuments, every workspace for active matters had been customized so that everyone would have the documents they needed at their fingertips on day one. We invested a lot of time in this effort, but our project may not have succeeded without it.
Once the migration is complete, the job is far from done. “Immediately follow up … with open houses or workshops,” says Gordon Katz of Porter Wright Morris & Arthur LLP. “These open houses and workshops are necessary to fill in the blanks from training.” Be sure to offer follow-up advanced training to existing users and get new users up to speed as they join the firm.
Watch Those Subtle Differences
John Kuttler of Finnegan, Henderson, Farabow, Garrett & Dunner, LLP recommends taking a close look at how your new DMS handles document security, inheritance and foldering. Look particularly at how the new system might be different from the old, as this may trip up users and IT staff. “Thought check your security,” John advises. Know how security will be applied to documents well enough to explain it to others. You don’t want the inner workings of your DMS to be mysterious or people will lose faith that it works the way it is supposed to.
Document versioning may also be different from one DMS to another, and this can cause headaches in some situations. For example, while iManage allows you to give each version of a document different metadata, NetDocuments does not. Workflows may need to be changed to accommodate differences such as this. That user who kept every monthly financial report as a version of the same document may have to adjust to using separate documents. Knowing about these potential issues in advance will save you heartache and buy good will among your user population. The folks at Finnegan figured out how to create a script to identify problem document versions, pull version data out of iManage and use NetDocuments API calls to translate versions into new documents.
Try to make yourself aware of this type of unusual circumstance prior to your migration, when you have time to proactively fix them. There’s no better way to do this than to involve as many people as possible in your pre-migration testing. And remember to promote and train on any features that are new to your firm. We held advanced training classes on NetDocuments’ faceted search functions that helped people find the most difficult to find documents. People considered these kinds of new features as a good tradeoff for having to learn a new system.
Test, Test Again, then Test Some More
We all like to have that warm, fuzzy feeling that comes from knowing that everything will proceed according to plan with such a high impact project. That feeling comes from thoroughly testing every step in your migration or upgrade plan again and again, until you feel certain every step works and you have uncovered as many potential “gotchas” as possible.
Back in my first job as a consultant I completed many DOCS Open upgrades and I made sure I tested, timed and documented each step. Upgrades had to happen in the middle of the night on weekends, data moved slowly, and there usually were not any support resources to help me if something went wrong. Migrations needed to be carefully planned out so that they could be completed in the allotted downtime window. I didn’t want to be scrambling on no sleep to complete the job by Monday morning. I wanted to know exactly how each step would play out. In a typical upgrade project I would test the complete process at least three full times. By the end of that process I would know exactly how long each step would take. Every potential snag, problem document and bit of bad data was identified and fixed prior to the final migration.
I also ensured I had a workable roll-back plan if something went wrong. Though you never want to use it, a workable “abort” button is important insurance. Of course the hardest part of the process to test is the stress on the new system once the user population starts using it the first day and you are too far along to abort. Testing with a few people is one thing. Hundreds of users at once can be quite another. Matt Kramer of Bernstein Shur learned this lesson in his recent migration from iManage FileSite to Work 10.1. He and his project team had carefully tested the migration process in a lab environment. Matt’s thorough testing ensured that everything went as planned on migration day. But a few hours after his firm started using the system, help desk phones started to light up.
Matt and his team didn’t panic. He and his team worked methodically to track down and solve the problem. It turned out that the structure of iManage’s Quick_Retrieve table had changed, and the migration process missed the setting of a key registry entry that went along with that change. When a user started a mass document export operation on Monday morning, the number of operations on the Quick_Retrieve table went through the roof, dropping system performance for everyone to unusable levels. Make sure you have the appropriate support available, as Matt did, to get the project back on the rails if the unexpected happens.
Sell, Sell, Sell!
Throughout a migration process, we should never forget that part of our job is to sell our vision and let the firm know that the juice is worth the squeeze. Seize on any opportunity you have to promote the benefits people will see when the project is complete. Be honest about the road ahead. Let people know they will need to invest some time to learn something new in order to see the benefits, but also let them know you will be there with training and support to ensure that they get there. Listen to your users and put a lot of effort into understanding and addressing their needs.
DMS projects can be risky propositions, but with proper planning, testing and training, the risks can be kept low and the rewards can be sweet.