4.2 - Migration Philosophy: Standard Migrations

4.2 - Migration Philosophy: Standard Migrations

 When using the Universal Migrator to perform a data migration, there are three distinct steps to a migration. 

Data Backup

With a Data Backup, you are using the Universal Migrator to pull data out of a legacy system.  When this happens, the data is pulled out as-is and little/no adjustments are made to it.

In modern systems that preserve record integrity, this will generally result in a pristine data set, however, with some legacy systems, this can mean you/your client may need to clean up data.

For example, in Time Matters, if you delete Contact #23, the client is removed from the database, but all artifacts that reference it are left in-tact.  This means that when Universal Migrator exports matters, it will export matters that indicate that Contact #23 is their client, even though no matching record is found in the database.

Data Validation

During this step, you should thoroughly review the integrity of the records and that all records you intend to import have all their necessary requirements met.  To do this, you will write queries such as:

  1. SELECT
  2. *
  3. FROM
  4. __M_Matters
  5. WHERE
  6. Final_ClientContact_Id not in (Select Id from __M_Contacts)

The above query would indicate all matters that are linked to contacts that no longer exist.  In the situation above, you should resolve the issue in one of two ways:

1.  Write a SQL script to point the matter at a new client (Not Recommended)

2.  Provide the list of invalid matters to your client and ask them to resolve the issue (Recommended).

Data Validation: Advice

When correcting data validation issues, there are a few suggestions we hope you will take under advisement.

 

Your Customer (not you!) is the best person to correct issues

Your customer knows their data inside-and-out, but you do not.  If there are multiple people named "John Smith" in your customer's database, your customer will know whether they are the same or not.

We have seen consultants who try to clean up their customer's data and it often turns into an extremely long project with a customer who is ultimately frustrated and unsatisfied with their consultant.

 

Don't Care About Cleanup More than your Customer

Clean data is the best but sometimes you'll encounter the Law of Diminishing Returns.  We have seen consultants inadvertently convince customers to terminate a migration because the consultant wanted everything to be 1,000% clean before the migration.  It is good to have things clean, but you don't want to fatigue the client.

Don't Co-Mingle Data

Sometimes consultants will choose to co-mingle bad/orphaned/invalid data with the idea that the customer can sort it out later.  For example, a consultant might say: "We have identified 100 documents belonging to 10 matters that no longer exist.  We are going to import all of those documents into a single "Documents without a Matter" matter.

Do Not Co-Mingle Missing Data

Imagine if someone gave you 100 random documents and it was your job to look through each of them and place it into one of 10 categories.  That would be a terrible, time-consuming job.

Instead, create 10 brand new "Missing Matter" matters and assign each document to its designated missing matter.  For example:

  1. UPDATE __M_DocumentFiles SET Final_Matter_Id = '781301' WHERE Original_Matter_Id = '<Missing1>
  2. UPDATE __M_DocumentFiles SET Final_Matter_Id = '781302' WHERE Original_Matter_Id = '<Missing2>
  3. UPDATE __M_DocumentFiles SET Final_Matter_Id = '781303' WHERE Original_Matter_Id = '<Missing3>

  

Data Restore: Do it Right or Not At All

When Universal Migrator is restoring a record, it will strive to restore the record properly or not at all.  For example, if you try to restore a matter that is attached to Contact #23 but Contact #23 does not exist, Universal Migrator will preemptively fail the restore of that record.  In this way, you can be confident that any data Universal Migrator transfers, it does correctly, and any items not transferred, need your intervention.

 

Data Restore: Heuristics and Minor Automated Adjustments

When restoring into some platforms, Universal Migrator may use heuristics or make slight adjustments to comply with data validation or requirements in the destination system.  For example, if you are migrating into a system that allows a single "Home Address" and a single "Work Address", but you have a contact with three addresses, Universal Migrator will use advanced heuristics to obtain a "best fit" for the data.

 

Data Restore: Direct Migrations Only

When transferring data between systems, you should only perform direct migrations.  For example, if you want to back up data from System 1 and restore to System 2, you should use the Universal Migrator as so:

Direct Migration Example (Do This)

System 1 > UM > System 2

 

You should never use the Universal Migrator to facilitate a "Bunny Hop" into another system or platform that you intend to immediately migrate a customer out of.

Bunny-Hop Migrations Examples (Do Not Do This)

System 1 > UM > File Server > System 2

System 1 > UM > System 2 > System 3

System 1 > UM > System 2 > UM > System 3

 

Because UM may make minor data adjustments to facilitate a seamless data transfer, when you try bunny-hop between systems, this can have unanticipated effects.  While the above may seem like an obviously bad idea, occasionally we see consultants who want to use the "Export to File System" capability to facilitate an import into another system.  In this specific example, this is bad because the following can happen:

  • The customer may be using a legacy system that allows special characters such as % < & * and ? in Client, Matter, and Folder names and descriptions.
  • When doing a backup from this system, UM properly records the special characters in their specified location.
  • When restoring into a file system, the special characters are adjusted so that the data can be delivered to the file system.
  • When taking the output of the file system restore and attempting to push it into a new system, the data will likely not exactly line up because of the automated adjustments that were made.  This will cause a significant amount of additional work as you'll have to code around the adjustments that were made.

In the event that you need to backup or restore data to or from a platform that is not currently connected to UM, please contact us.  Often times we build additional connectors at no additional cost.

 


    • Related Articles

    • Migration Type: Delta Migrations

      A "Delta" migration is necessary when you migrate some data now and some data later. To do a Delta migration, please follow the steps below after you have complete the initial backup and restore. 1. Create the "Phase 2" Backup Using Universal ...
    • 01 - Configuring a Migration Workstation

      Location Matters Please refer to this article for information on where a migration workstation should be provisioned. Best Practice: Choosing the Right Location for a Migration Workstation For Multiple Concurrent Migrations If you intend to do lots ...
    • 01 - Creating a Migration Workspace

      Prior to scoping a migration, you should create a migration workspace for the prospective project on your migration workstation. This folder structure will contain notes and important information about the project that you will add to as you discuss ...
    • 03 - Configuring a Migration Workstation (for Multiple Concurrent Migrations)

      Recommended Location A migration workstation configured this way should be located: in your office or your data center Recommended Specs Before we get started, you should have a modern PC with the following specs or better. Recommended Hardware ...
    • 02 - Configuring a Migration Workstation (For One Concurrent Migration)

      Recommended Location A migration workstation configured this way can be located in any of the following locations: in your office in your data center on the same network as the customer's server (if they are moving from an on-premise application) ...