Agile Migrations - A Revolutionary Approach to Content Migrations

Content migrations take a long time to complete for reasons that have very little to do with the actual act of migrating. In fact, the largest delays tend to come from errors in metadata that must be addressed by the people who own the documents. Business users will make time for their most critical content, but the bulk of the documents only get attention when the content owners can fit this work into their busy schedules. Let's face it - cleaning up the metadata for some obsolete piece of content isn't on anyone's list of favorite things.

At Blue Fish, we've changed all that with a revolutionary approach to migrating content we call Agile Migrations. By leveraging this approach along with Migration Workbench, your migration will be completed faster, with less effort from your business users, fewer errors, and higher confidence in the result.

Incremental Migrations

One of the biggest problems with a migration is that issues with the source data are not discovered until you attempt to migrate that data into the target system. But by then, it's too late. To fix the data issue, the entire migration must be rolled back and retried once the data problem is corrected. This is time consuming and tedious, and some migrations require hundreds of these iterations.

Migration Workbench takes a different approach. In fact, it expects things to go wrong. It anticipates these last-minute data problems and uses a revolutionary method for resolving them called “Incremental Migrations.”

Workbench constantly monitors the source repository, looking for changes. When it detects new, updated, and deleted documents, it migrates them to the target repository. Rather than rolling back the entire migration when a data issue is uncovered, Workbench waits until the issue has been resolved and then migrates any changes. This process can repeat hundreds of times with no significant performance penalty because each time, Workbench only transfers the small number of documents that have changed.

Best of all, there's no need to freeze your repositories or lock users out of their production systems for long periods of time. Migration Workbench can operate on your live production systems, since it isn't bothered by changes users might make during the migration – it will pick up those changes during its next incremental run. And users of the target repository won't even know a migration is taking place. Workbench keeps migrated documents hidden in the target system so that they are not made active until they have been validated and cut over.

Dynamic Cutover

Another big issue with migrations is that they typically use a "big bang," all-or-nothing approach. Your most critical documents may be ready to migrate, but the migration cannot be performed until every last scrap of content has been checked and validated by your business users or quality assurance team. Since a lot of that content hasn't been touched for years, this is a tedious and time consuming process.

Again, Migration Workbench takes a different approach. Its "Dynamic Cutover" feature allows content that has been reviewed and validated to be activated in the target system while issues with the rest of your documents are still being resolved. That same content can be hidden or made read-only in the source system so that users don't mistakenly update it. This allows your users to start reaping the benefits of the new system early, even as the less critical documents continue to slowly trickle in.

Migration Rules

Traditional migration tools follow an antiquated Extract-Transform-Load (ETL) process invented for copying data to and from databases. But content management systems are more complex than simple databases, and an ETL approach is not nearly flexible enough for the complexities of today's content migrations. The problem with ETL tools is that they can't handle exception cases - they expect all of the documents in the source repository to be classified correctly. ETL tools use a single mapping for each attribute, and all documents with that attribute are processed in an identical manner. But due to years of human error, content management systems contain lots of inconsistencies, misfiled documents, and other mistakes. The one-size-fits all approach of ETL tools doesn't work well in the real world.

Migration Workbench makes it easy to handle exception cases. It uses a set of flexible and powerful migration rules that can be configured to process different documents with different metadata transformations. For example, imagine that you had a summer intern named Fred filing documents several years ago. Fred didn't understand the classification system, and he put the title of the document in the subject attribute while entering the subject of the document into the title attribute. With Migration Workbench, you can write a migration rule that treats Fred's documents in a special way, reversing these attributes and fixing the data problem.

Migration rules can also be used to exclude documents that should not be migrated and perform other advanced transformations. They can populate attributes based on a document's naming convention, rearrange folder structures, prune version trees, set attribute values based on lookup tables, and more. And because they are easy for business users to create and understand, they provide complete traceability back to your migration requirements.

Partial Import

If a target repository isn't configured perfectly, it can derail a traditional migration tool. Let's say one of the documents you are migrating is owned by Fred, who never came back to your company after his internship years ago, and therefore doesn't have a user account in the target repository. When you try to migrate Fred's document, the import will fail when it tries to assign the non-existent user as the owner of the document. With traditional tools, the entire migration must be rolled back while the problem is addressed.

Migration Workbench anticipates that this might happen and handles the problem gracefully. If a document is being imported and a related group, user, lifecycle, or ACL does not exist in the target repository, Workbench will still import the document, setting the offending attribute to a temporary value. The document is then marked as having been partially imported, and Workbench will attempt to update the document during its next run. In the mean time, you can reconfigure the target repository or add a migration rule to map the offending attribute to a different value. In the example above, a migration rule could be written to make Sally the owner of documents that were originally filed by Fred. The next time that Workbench is run, the document will be migrated successfully with Sally as the owner.

Increased Efficiency and Ease of Use

While incremental migrations, dynamic cutover, rules-based attribute mapping and partial import each do their part to make your migration more manageable, the true efficiencies come when all of these features work together. The result is a migration virtually free of headaches – one that is useful from the start (even before users are nagged into cleaning their data), one that doesn’t require any inconvenience or delays, one that results in dramatically fewer errors – a seamless migration that nobody is afraid to embark on when your business calls for it.

Migration Workbench and the Agile Migration approach are revolutionizing the way content migrations are performed.