Data Migration Considerations

Data Migration General Considerations and Pricing

In order to determine the price of data migration, we need to understand the structure of your existing data and the number of fields you want to import. Migrating data can be very expensive given the broad nature of what is typically collected. We base our migration cost on several factors:

Number of Fields to be Migrated. The number of actual fields that we have to migrate (as opposed to the number of records) significantly affects the price of migration. Thus, if there are 100 fields , the price will be less than if there are 200 fields. However, it typically doesn't matter how many records we migrate. For instance, if you have 10,000 records to migrate versus 100,000 records, the price is the same. This is because we have to write a (computer) script to move each record from your existing system to our system. So, the most cost effective way to have your data migrated is to figure out which fields are the most important and limit the migration to those fields.
The Underlying Database Currently Storing your Data. A factor in determining the price of data migration is the underlying database used to store your existing data (e.g., SQL DB). For example, while this is less and less a factor, some older versions of databases are not "relational" (see http://en.wikipedia.org/wiki/Relational_database), which can increase the complexity of moving data into LegalServer.
Files. If you are planning to import files and documents into the database, this will make a difference in the amount of time for the import and space your database will use. It also will make a difference as to how you currently store all of the files you intend to import.
The Number of Databases to be Migrated. Typically we will only migrate a single database to LegalServer. This is due to the fact that multiple databases may have conflicting records and undefined relationships, which will cause the migration to fail (or produce bad data). Thus, we typically require that you merge your databases into one single database before sending this to LegalServer.
The Number of Uploads it takes. If you are working with an outside consultant on the data migration to Legal Server, please discuss with your consultant who will be responsible for any additional fees that may incur during the migration process. If the manipulation of the database structure requires a new upload there may be an additional charge incurred.

Steps to Getting a Quote on Data Migration

Tell us what you currently use for your data.
Identify the approximate number of fields you intend to import. We price in multiples of 25 fields.
Identify the amount of documents you want to import LegalServer itself in terms of number or total size in GB.
Reach out to us for a quote with the details above for a flat fee quote.

Frequently Asked Questions About Data Migration

What is a field?

When we refer to a field, we mean a specific piece of data in your system. Think of this as a column in a database table or excel file. When you think of a name, that's not often a field all by itself. Names are often at least 4 fields -- First Name, Middle Name, Last Name, Suffix, Maiden Name, Second Last Name, Title, etc. Each of those items is a separate field, even if you normally use them together to form the name. Another example is phone numbers. Some databases have phone numbers split up into area codes and 7 digit numbers, others will have them as 10 digit numbers. The number of fields isn't based on the number of fields you are importing into, but the number of fields you are importing from.

Is anything not considered a field when we're migrating?

When you are working with an onboarder, they'll mark some fields to import even if you aren't planning to import those fields. These are typically primary key fields on tables (meaning that they are the unique row identifier on that table) or they are Foreign Keys linking one table with another. For example, that's necessary to link a client with a case and won't necessarily be used or seen otherwise. Primary Keys and linking Foreign Keys are typically not counted against your field limit. Where that Foreign Key is a link to a lookup/picklist/dropdown in your existing system, we'll count the field on the table where the data is displayed. We'll also have to mark the table holding the lookup values (the code and description typically) for import, but those won't count towards your field limit.

Can you migrate records from a certain date forward?

The answer to this question is yes, however, it too will increase the price since we have to write code to first determine whether the record can be migrated (e.g., within the specified date range), in addition to the code to migrate the data. This is not recommended. However, feel free to update your database to delete the records you want removed for the purposes of migration prior to uploading your sample database to us.

Does the number of records affect price?

The answer is typically no, the number of records will not affect price in most circumstances. We have to write computer code for each field to be migrated. The computer will run that computer code as many times as it needs to get each record, but there is very little difference in terms of our time and materials if the computer runs that code 10,000 times or 100,000 times. Therefore, we base pricing on the number of fields as opposed to the number of records.

Why do you limit the number of databases that can be migrated?

We limit the number databases that can be migrated to one since combining data from multiple databases can be tricky and often produces invalid results. If two databases are used to maintain your records, you can merge the databases prior to giving us the sample copy on which we will base your data migrations.

Why does the database have to be the exact copy of what the final version will be?

The reason we require you to upload an exact copy of the database that will ultimately be migrated (upon final migration) is because we have to write computer code to move each piece of data from your existing system to our new system. If the structure of your database changes, then the code we write will no longer work when you upload your final data to us.

How can I lower the cost to migrate our data to LegalServer?

The easiest way to reduce the cost of migrating data is to select only the fields that are absolutely essential to bring over from your current system (as opposed to bringing everything over). For example, it might make sense to bring over data that could be used to determine conflicts of interests in previous cases, but not bring over everything that was done in those cases. This is especially true if you will continue to have access to your old system for reference.

We need to import more fields than we contracted for, can we do that?

Once you start the onboarding process, a LegalServer staff member will work closely with you to identify the fields you want to migrate. If you've identified 100 fields, but your contract is for 75 fields, there are two options. 1) LegalServer will let you identify the fields you do not intend to import, or 2) the Onboarder you are working with will issue a change order on your contract to increase the number of fields. Once that is signed and returned, you'll get an invoice for the increase in price and the data import will proceed.

We're already live, can we migrate some additional sources or import via CSV?

You can propose this with our onboarding or support team, but if your data migration has already been completed, merging an additional full database will not likely be feasible. If an additional import is agreed to, this is a separate project that will require a change order for a new data migration analysis. If it is then deemed feasible, there would be a second change order for the data import itself.

Manipulating Data: Our data doesn't fit neatly in LegalServer, what can we do about that?

While LegalServer can import data into system and custom fields, occasionally we are asked to split data from one field in the source database across multiple fields in LegalServer, combine two fields in the source database into one field in LegalServer, or set values for various fields in LegalServer based on the values of one or more field in the source database. We can accommodate a very limited number of these requests in any one data migration, and the best thing is to have data as clean as is possible before providing it LegalServer. For example - Names should be in three to four fields first, middle, last and suffix/second last name, rather than asking LegalServer to split these out of one field. If during data mapping, import or testing it is discovered that data manipulation is required, we generally wait until all such requests are submitted, and decide together what can and cannot be accomplished under the agreed upon data migration plan.

Our upload is missing tables or fields, can we do a second/third/fourth upload of our data as part of our Onboarding before our GoLive?

Data migration is an art. LegalServer understands that getting a handle on your data is difficult. LegalServer will allow a second upload of your data to be used to migrate into your Demo site and build the initial import scripts if there are issues with your data set. Please note that this may result in having to remap your data, redesign import scripts, and revalidate imported data. This could also result in some delays with your GoLive. If there are issues with your data in the second data upload and we have do a third data upload to re-populate the migrate module, there is typically a change order and a cost associated with it given the additional resources needed to process the data again. This is the case whether LegalServer is replacing everything in the migrate module or just adding a few tables to the data already present.

Do you already know my database structure?

LegalServer has migrated clients from a wide array of existing databases. If your data is currently stored with any of the following sources, we can give you a simple quote:

Abacus
Clio
DefenderData
Disability Advocacy Database (DAD)
Excel
Journal eDefender
Journal Justware
Kemps Case Works
Innovation Law Lab
Lotus Notes
Microsoft SQL Database (not otherwise mentioned)
Pika
Postgres Database (not otherwise mentioned)
PDCMS
Practice Manager
ProLaw
Salesforce
TIME
TimeMatters/Lexis Nexis

If you have a different datasource, please let us know and we will ask for more details before quoting a price.

Data Migration Process

See our Onboarding Documentation for a detailed description.

Importing from a Spreadsheet? Things to Know!

Each tab in your spreadsheet is considered its own table, with its own fields. We count each field (column) in each sheet.
- Example: You have a tab called “2024” with client first name, middle name, last name. You have a different tab called “2023” with client first name, middle name, last name.
- Field Count: 6 (3 fields for client name on the 2024 tab, 3 fields for the client name on the 2023 tab).
- Import Rule: The number of fields isn't based on the number of fields you are importing into (the LegalServer destination), but the number of fields you are importing from (the spreadsheet).
- Solution: Give us one tab with all your data. Even if not all records (rows) have every field (column) filled in, that’s fine. In the example above, if there is one tab “All Cases” with client first name, middle name, last name, it would only count as 3 fields, as it only appears once.

What we don’t count: We don’t count unique identifiers that are used to link two tables together (Foreign Keys).

Example: One tab has cases with a unique case number. A second tab has case notes that use the same case number field to identify which case the notes are tied to. We only count the case number on the cases tab.

All spreadsheets must be provided as a CSV file. This speeds up our internal conversion and avoids any row or column limitations (for example, Microsoft Excel limits the number of rows to 1,048,576 and columns to 16,384) . If you need help exporting your Excel or Google Sheet file as a CSV, feel free to let us know.