Migrating Historical Data between Historians

Organisations that wish to change the data Historian they use are often faced with the challenge of what to do with the data contained in the existing historian. Simply powering the old historian server off is usually not a viable option, and maintaining two parallel systems introduces additional complexity and cost. Clearly, migrating the data in the existing system to the new system is the preferred route, but when large quantities of data are involved over extended time periods, this is not as straight forward as it may appear.

Historians often include tools such as an OLEDB client that can be used to import data from other OLEDB-compliant sources. These tools are usually fairly limited, single query-based affairs that return and insert data in large lumps and tend to be slow given the quantity of data queried.  Also, the data is inserted blindly into the new historian, without providing any way of validating the inserted data, bar manually eye-balling trends of the inserted data on the target historian and comparing those with the source. This cannot possibly be considered a thorough and reliable migration process for valuable historical data!

Because we have encountered the need for a verifiable data migration process between historians on more than one occasion, when we developed the IDX Historian, our cost-effective enterprise-grade historian, we decided to incorporate a Data Migration tool that addresses this need directly into the Historian’s tool set. The tool does not require any additional license to use and allows for the migration of data between essentially any historian with an OLEDB interface or software API and the IDX Historian. However, the tool also allows data to be migrated directly between 3rd party historians; for example, it is possible to migrate data from a Wonderware (InSQL) Historian directly to an OSISoft PI Historian.

The migration tool uses the following methods and items to effectively migrate historical data:
  • Assistance from IDX 8 Tag Manager: The first step in migrating data often involves ensuring the tags for the data to be migrated already exist or are setup in the new historian. IDX Tag Manager allows the tag configurations to be automatically synchronised between systems before the migration takes place thus averting having to perform this process manually.
  • Source/Target Plugins: It is possible to migrate from any supported source historian to any supported target historian, which currently includes the Wonderware (InSQL) Historian, OSISoft Historian and IDX Historian. Plugins can be developed to meet other requirements on request.
  • Jobs and Batches: The migration tool carves up the data under migration into various levels of repeatable work items. The first step is to define a job which runs as a Windows service that encompasses a configured set of tags over a specified time period. Once a job is configured, the migration tool automatically creates a set number of work batches to be executed that equally divides the job data to be migrated. The two principle advantages of using the job/batch approach are:
    • Parallelisation: today’s computer hardware benefit from parallel operations. This speeds up the migration process considerably.
    • Recoverability: because the migration process is divided into batches, any batch can be resumed, re-executed or analysed as required.
    • Data Analysis and ReportingPost migration, the migration tool provides the option of analysing and comparing the data from the source and target historians at the batch level, allowing for greatly simplified side-by-side data comparison. It can also be configured to automatically highlight anomalies in the migrated batches that require further investigation. The provided analysis reporting can be used to provide an overview of the result of the complete migration.

Migration job summary page illustrating pre-creation of job batches and batch status

Using these features, the migration tool, as illustrated by this case study, is able to perform data migration where vendor-provided tools are slow, or simply fail, and provides a fully analysed and verified migration process in a reasonable time period.

Because we understand historian users may not wish to delve into the world of historical data migration themselves or purchase IDX for a once off migration project, we also perform data migration using the IDX Data Migration tool as a service, should this be more suitable. Feel free to contact us.


Popular posts from this blog

Common pitfalls when installing a Modbus RS485 network on site

IEC61850 to Modbus TCP/IP, EtherNet/IP, M-bus, PROFINET or PROFIBUS

IDX 8 Tag Manager - Managing the unmanagable?