Lessons Learned from Software Migrations

Here are a few lessons I have learned from supporting and supervising about a dozen software migrations, both from legacy tools to new product data management applications and upgrading software applications to new versions.

When you migrate data, either put it in a completed state or the start of the workflow. If you put it in middle of the workflow, the workflow may not progress properly to completion. Ensure that objects migrate and remain in the correct life cycle state, and that they can progress through the lifecycle after migration.

Map out your data lifecycle states. If items migrate and there is no destination lifecycle state, it may migrate but become impossible to find. Where possible, ask users to move their items through the workflow to a workflow state that exists on the new database.

First and foremost in user training, teach people how to find the data they will be searching for. This is more important than teaching them how to upload new files or modify existing data, because even engineers and configuration managers have to find the files they will be updating.

First and foremost in software migrations, make sure all the data migrates and can be found when you search for it. Projects may not migrate because of problems with naming conventions. Files may migrate but their references are lost.

When you migrate items to a new database, a common result is that the default dates for the workflows is the date of the migration. For example, the completion date for all the workflows is the date of the migration. This can confuse customers and throw off reports for months.

Format and cleanse all of your data prior to the migration, even what you may put in archive. After all, the archived data might have to be moved to the new system at some point.

Make sure your data models and test plans include every system with which the new application will interface. Assume that it will interface with everything the old system interfaced with unless those systems are rendered obsolete by the migration.

Access controls matter. If access is wide open, guests could gain access that only privileged users should see. If access controls are too tight, employees can’t access files they need to do their jobs. Access controls based on agreement objects can take helpdesk staff an hour to troubleshoot with Venn diagrams. Access control via agreement objects that give contractors and special access exceptions to specific documents and projects are time consuming to create and maintain.

Access controls need to balance integrity with availability. In the desire to prevent someone from changing something that they shouldn’t, valid users may be unable to update drawings or approve change notices. Access control objects that automatically expire simply maintenance tasks unless users routinely see their contracts extended.

Check for the files that should have followed the metadata. Sometimes the metadata migrates beautifully, populating every field perfectly, creating a properly filled out library card for which there is no corresponding book (file) in the database.
Check for secondary files as well as primary files when you migrate the data. While testers know to look for the drawing associated with a drawing number, they may not bother checking the scanned engineering change notice, signature forms or SDRL forms.

Always test your migration in a test system or “sandbox” before you try it with production data. Verify that user access roles migrate along with the data. A record that migrates but locks out viewers is utterly useless.