When using the Universal Migrator to perform a data migration, there are three distinct steps to a migration.
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.
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:
- SELECT
- *
- FROM
- __M_Matters
- WHERE
- 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).
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:
- UPDATE __M_DocumentFiles SET Final_Matter_Id = '781301' WHERE Original_Matter_Id = '<Missing1>
- UPDATE __M_DocumentFiles SET Final_Matter_Id = '781302' WHERE Original_Matter_Id = '<Missing2>
- UPDATE __M_DocumentFiles SET Final_Matter_Id = '781303' WHERE Original_Matter_Id = '<Missing3>
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.
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.
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:
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.