Migrating Electronic Records: More than Just a Data-Mapping Exercise

Over the last couple of years I’ve been helping with the implementation of a variety of tools meant to support various aspects of the information governance process, most especially migrating document / records repositories from one system to another. This includes implementing electronic records management (ERM) systems, document repositories that are used as research resources, physical records management tracking and e-mail archives, just to name a few.

What I have found to be unnerving in almost all these cases is the lack of advanced planning for the actual implementation on the part of the user organization.  They requested and put out an RFP for a tool to help them support a list of functional and technical requirements so the tools they end up implementing are in the realm of what they asked for and for the price they expected to pay.  Except they didn’t plan for the changes that would need to be made in the organization of their documents / records in order for the tool(s) to work effectively. Retention plans weren’t optimized to use the new system. Classifications and taxonomies weren’t sorted out to prevent confusion and redundancy within the system. They just made the assumption that they would migrate their previous repositories in whatever state they were in right into the new system.

It doesn’t work that way folks. Yes, data mapping is required but that just one aspect of the project process. If this just happened once I would dismiss it as a one-off occurrence. Unfortunately, I’ve seen many situations like this and they aren’t pretty. In fact, it results in the user paying licensing fees for software they won’t truly be able to use for several months to several years down the road. Not a wise use of funds.

It’s akin to moving from one house to another without taking account the new floor plan, the square footage of the new abode and the neighborhood you are moving into.

  • Taking all your belongings into a downsized residence doesn’t make sense.  Do you really need to migrate with every book you’ve owned since college? Maybe, but highly doubtful.
    • Get rid of the Redundant, Outdated and the Trash, i.e. ROT, and redefine your retention plan, if necessary.
  • If you move to a warmer climate, do you still plan to use your cross-country skis every week? Again, highly doubtful.
    • Are you still using records procedures developed for manual systems in an electronic world? Update procedures to use the new system effectively and get rid of archaic language.
  • When you pack you winnow down what you have, and you categorize what you are packing by room and by object type so you can eventually find it at your new destination.
    • Having folders with the exact same names that mean two different things will cause confusion. Sort out file plans and naming conventions before hand.
  • When you make the actual move you are provided a bill of lading after everything is put on the truck so that you can track what is being moved and make sure it all gets to the final destination in the same way.
    • Yes data mapping is still required so having an old schema is as important as creating a new one.

Of course, organizations shouldn’t even be thinking of migrations unless they have thoroughly prioritized their information governance efforts and assessed their present program’s health.  Doing an info gov benchmark generally costs less money than a migration and can help identify whether that migration project is really the priority you think it is and, if so, what you need to do beforehand to prepare for a cost-effective implementation.