How to Use Migration Workbench

Migration Workbench enables a revolutionary new approach to performing content migrations called Agile Migrations. This short guide explains how to use the power of Incremental Migrations, Rules Based Attribute Mapping and Dynamic Cutover to complete your migration in record time, with less effort from your content owners and fewer content errors.

Step 1 - Gather Requirements

The first step in your migration is understanding the migration requirements. You'll want to meet with your business users and find out what documents need to be migrated and how they will be filed in the new repository. Pay special attention to the metadata - how will the existing metadata map to the object model in the target repository? Are there attributes in the target system that don't exist in the source system? Is there metadata that needs to be transformed, such as converting "Smith, John" to "John Smith?” Are there some documents that are more critical than others?

As you review the existing documents with your business users, you'll start to uncover exception cases. There may be documents that were misfiled or misclassified in the source system or files that are owned by users who no longer work at the company. Don't panic - Migration Workbench was designed to handle these exception cases. Whenever you find an exception case, document it using an "If/Then" syntax - this will make it easy to create a migration rule later. For example, if you discover some documents that are owned by a user that no longer works for the company, document how you want them to be treated by writing "IF a document is owned by Fred Smith THEN change its owner to Sally Jones".

Step 2 - Configure Migration Workbench

After you have done some initial requirements gathering, you'll want to configure Migration Workbench. Workbench performs migrations in "batches" - large collections of documents that are migrated together.

To configure a batch, you'll specify the source repository and login credentials, and you'll select the documents to be migrated in that batch. You will also specify the target repository and set any advanced import preferences. For example, if you want Migration Workbench to automatically create folders when they don't already exist, you'll specify that when you configure the batch.

Step 3 - Write Migration Rules

Now it's time to start implementing your migration requirements by writing migration rules. Migration rules do the heavy lifting, mapping metadata from the source repository to the target object model and transforming it along the way whenever necessary.

Some migration rules will apply to all the documents being migrated, while other rules may apply only to certain exception cases. Migration rules are easy to write, and can even be written by business users and content owners. A detailed tutorial with lots of sample migration rules is included in our Migration Workbench Evaluation Kit.

Step 4 - Start Incremental Migrations

Once you have written some migration rules, you'll want to see them in action by executing your first migration batch. After Migration Workbench extracts, processes, and imports the documents in your batch, you can inspect the results in the target repository. Our reporting dashboard will tell you which documents were migrated successfully and which ones have issues that need your attention.

Step 5 - Fix Data Issues

After executing your migration batch for the first time, it's highly likely that your business users will discover some documents that need special handling. Don't beat yourself up over this - keep in mind that it's almost impossible to gather all of the migration requirements correctly prior to the first batch execution. Your business users don't know their data as well as they think they do - some of their documents haven't been touched in years. But after you run the initial migration, they will see how their documents look in the target repository, and they will discover many more exception cases.

Some data issues can be fixed by updating the document in the source repository. Others will require a complex transformation. At this point, you will follow a simple process to resolve these issues. First, update your requirements document so that each exception case is well documented. Then update your migration rules. Finally, rerun your migration batch. Workbench will apply the new rules and update the target repository as appropriate. Only the updates will be migrated, so these incremental executions of your batch will happen very quickly.

Step 6 - Cutover Critical Documents

Working with your business users to resolve their data issues may take a while. After all, these people have their normal responsibilities and can't spend all of their time tending to the migration. But at some point, their most important documents will be free of errors and ready for the new system. At this time, you will run Migration Workbench's Dynamic Cutover feature.

Dynamic Cutover will activate the documents in the target repository, unhiding them so that they can be accessed and updated. It will also hide or make read-only the documents in the source repository so that they are not mistakenly updated. The magic of Dynamic Cutover is that documents can be cut over in waves, with the most critical documents being cut over first while data issues with the less important documents continue to be worked on by the business users.

Step 7 - Iterate Until Done

The migration proceeds in this manner until all of the data issues have been resolved by the business users and all of the documents have been cut over to the new system. With Migration Workbench, your migration will complete in record time, with less effort from your business users and fewer errors.

Happy Migrating!