Considerations when uploading contract data to Intelligentcontract

When starting a new account with Intelligentcontract (IC) there are decisions to make as to which data from your existing contract management system to migrate to IC. This short article outlines the considerations and options for data migration.

The State of your Current Data

The first exercise that will inform the level of effort required to move your data into IC, is an assessment of where your data currently resides. In additional you will need to consider how easily it can be extracted in readiness for upload to IC. Generally, the less structured your data then the more effort required to import it. Because of the additional effort, decisions can be made to cut down the amount of data that is imported (covered in steps 2 and 3). The level of structure and the associated considerations are discussed below.


If you have an existing “structured” system that holds the indexing data and documents then migrating your contract data will be more straight forward. A structured system may be another contract management solution or an internally developed Access database solution for example. You will still need to determine how to extract from your existing solution into a CSV (or similar spreadsheet based format) and (sometimes trickier) how you are going to get existing documents extracted.


Most organisations that don’t have a formal system fall into this category. You may have your contract indexing data in one or more excel spreadsheets with copies of documents held on a shared drive.  Extracting this information ready for importing to IC involves combining data from multiple sources into a single CSV and a potentially pulling together a set of files (the contract documents) into a single location. It may also involve generating data where data is incomplete. This additional date will facilitate improved searching and reporting.


If you have your contract data without structure then there will be more work to import it to IC. You may have copies of documents in multiple email inboxes, information in many people’s “heads” or located on pen drives or PC hard drives. You may have no indexing data at all and have the task to create this from scratch by examining the original contract documentation or by interviewing key people.

No Data (or significant amounts Missing)

If you are faced with missing contract data or even no data at all then your options for uploading are limited. In this scenario, you may have no options and must load only current and going-forward data (i.e. only that data you can acquire)

Historical Vs Current data

If your data is unstructured or if you prefer not to load old data to your new IC implementation, then you are able to cut down the amount of data you import to save time and effort during implementation.

You should agree a specific cut-off date, before which data will not be loaded. Typically, this might be between 6 and 18 months depending upon the value of having historical contracts to hand. The cut-off date is normally associated to the end date of the contract (i.e. don’t load any contracts that expired 12 months ago or more) but some organisations pin their historical cut-off date to the start date of an agreement. In either case, make sure that the historical cut-off date balances effort to load the data with the convenience of having the data to hand within IC.

Note: You should leave your existing system in place to reference any historical data that is not loaded into IC. As time passes this data will become less relevant. You should agree an historical system shutdown date so that you are not maintaining two systems (and also two sets of contract data) indefinitely.

Full Records or Partial

You need to decide the level of granularity you wish to upload for each contract. This level could be different for different contract types or based on the age of the contract.  You may decide to only upload a title, end date and a party for contracts older than 6 months but full data (e.g. notes, parties, people, documents) for “current” contracts, for example.

Upload or Type

Having decided which data is to be loaded there are two options to get that data into IC. There are standard interfaces which will allow the contract data to be uploaded via a CSV sheets (and, if required, ZIP files for contract documentation). A template can be generated by IC ready for you to populate. This approach is useful where the functions of a spreadsheet program can help with filling in missing data. For example, you may not have the start date for your contracts and have decided to have a “default” start date - A spreadsheet will allow you to quickly populate this data.

If you are adding only a handful (typically less than 50 contracts) or the data is highly unstructured that the data needs to be “created” by examining the original documentation then creating the contract data via the IC standard interface may be the best option. The system in this case will validate the entries as you create them rather than having to “bulk upload” and correct errors after an upload attempt.

Now or Later

The final decision is around the timing of when data is imported into the solution. You may decide to configure your IC account and load your data at some point in the future. Users will be able to create new contracts as they arrive and begin work on the solution immediately.

Not loading your data means you may have to run two system (i.e. IC and your legacy contract management system) together until your data is loaded, but if you have no effective current system this may not be an issue.

Having historical data loaded gives new users confidence in their new solution. A solution with no data may seem incomplete for new users.

One option is to go half way and load “placeholder” information for all contracts. This might be title, party and end date for example. You can mark each contract “Not Reviewed” initially and then over time, resources are able to fill in the gaps on the placeholder and remove the “not reviewed” marker.


Following internal discussions about which data is to be loaded, how and when, you will be able to build a historical data criteria statement. For example you may decide:

  • We load all available data (including notes, financial, people, parties, header info, documents) for all current contracts (i.e. active within last 6 months) except Lease type contracts;
  • We load header, documents and reminders for current leases;
  • We load only the title and party for any contracts older between 6 and 12 months old.
  • Anything older than 12 months will be left in the historical system for 2 years.

This criteria statement can be developed and then agreed by internal stakeholders. Having an agreed criteria can set expectations appropriately as well as informing the planning of resources to facilitate data migration.