Large scale enterprise content management (ECM) system migrations have typically been accomplished using a combination of import software, support utilities, fix-it scripts, database scripts, and expertise on the internal workings of both ends of the process. Make a mistake? Run some SQL statements and clean it up. Not fast enough? Write document files directly to the file system. While migration methods and best practices are abundant, typical on-premise migration engagements are usually services-heavy.
Cloud migrations require a very different approach than on-premise conversions. Just about everything is done through an API, so visibility and control of the migration process must be handled by a product through robust user interfaces and reporting services. Error detection and resolution must again be done through migration product interfaces, and not through side doors like database queries. If things don’t go right, unwanted data must be rolled back through a straightforward user interface, and then reprocessed. In general, the architecture and user interfaces of the migration product become key.
Let’s get back to some cloud migration basics. There are usually two and only two interactions with the repository: A user application(s) and an API. Storage isn’t something tangible like a file system, and there is no accessible database. The entire migration process has to be done accessing document management entities and features abstracted through an API.
Since the API is THE migration interface, there are usually several requirements that go far beyond the usual API used to develop a client application. For one, there are always a set of “system” fields that are usually set by the DMS, but during a migration need to be settable. For example, the “created by user and date”, and the “modified by user and date” must be the same as the source. It’s usually important to be able to set the history for documents, even though the history occurred in a different system. Even some user-preference items like a favorites list should be migrated when possible so users can pick up where they left off with the new system. In the cloud migration model, all of these are only possible if the API supports it. Therefore, one important element of the evaluation of a cloud-based DM system should be whether or not the service’s API is robust enough to handle all of these scenarios.
Migrations seems to never be fast enough, whether it’s on-premise or cloud. When a migration is so dependent on the cloud service’s API, robust parallelism, running the data simultaneously on multiple processors, is vital to reduce processing time. Generally, cloud systems are designed from the outset to handle a large number of remote requests at the same time, so a solid multi-threaded architecture in the migration product is very effective.
In surprisingly few cases, a migration to the cloud is as easy as “lifting” the database from a source system and “shifting” to the cloud and a new platform, leaving in place all the old structures like workspaces, folders, lookup lists, etc. More often than not, customers use the migration “opportunity” to re-think their content. This is especially true when moving to the cloud since the features available for data organization are somewhat new. In legal for example, if the original ECM system was not set up to be matter-centric, the migration is an ideal time to change that.
Most of the cloud migrations to date have focused on moving from an on-premise system to the cloud. In fact, the trend of “going cloud” is picking up momentum every day. According to a recent DMS Implementation Survey by InsideLegal, within the last 12 months, 95% of surveyed DMS experts have worked on cloud-based DMS implementations followed by 71% involved with on-premise DMS to cloud DMS upgrades versus 57% busy with on-premise implementations. The bottom-line ... law firms of all shapes and sizes are embracing the cloud, especially when it comes to DMS.
To that end, as the legal cloud market continues to mature, and more options become available, cloud to cloud migrations are more common. When two firms merge, for example, they may require their multiple existing cloud repositories to be consolidated into one unified system. Or, a firm may choose to move to a different cloud provider. The factors for cloud migrations mentioned here are doubly important for cloud to cloud. In addition to an API-centric approach for the target, the same holds for the source. Data must be extracted through an API and acceptable performance can be achieved through an easily configurable, robust threading architecture.
As the legal sector, from top to bottom, continues to embrace the benefits of cloud technology content migration tools need to keep pace with client demands and their complex content challenges.
Copyright © 2018 Legal IT Professionals. All Rights Reserved.