Project Process - Details


Kofile has extensive experience with the conversion of various document imaging, COLD archive, check archive, and signature card systems. Throughout our years in the conversion business, we have developed a large number of custom applications and utilities that allow us to convert data from these systems. This allows us to be price competitive with companies large or small due to our prior engineering and development efforts.

Knowledge, experience, innovation, and flexibility give Kofile the ability to deliver on any development activity regardless of the size or complexity.

Don't trust your critical, confidential data with just anyone. Trust it with Kofile Conversion Services.

Implementation Methodology

Conversion projects are all unique, like puzzle pieces, and each one requires careful planning, analysis, and implementation. No two source systems are alike. There are differences in system configurations, storage architectures, database software, metadata, image/file formats, etc. So, even though we have experience with a particular system, there is no cookie-cutter approach that can be taken. In addition, we also need to take into account the requirements for loading into the target system. As a result, we have devised a methodology that can be applied to any conversion project. This methodology is used for any type of digital conversion project, be it an imaging, reports/COLD, check archive, or other system.

The basic steps that are performed for all conversion projects are:

  1. Extraction of data, images and metadata into a "standard" or neutral format. Generally this is TIFF images or other native format files (PDF, AFP, XLS, etc.) for imaging & check repositories, text files for reports/COLD repositories, and metadata in flat files (delimited text files) or de-normalized in database tables.
  2. Massaging of the extracted data based on business rules and to meet the requirements of the target system(s). This could consist of: separating multi-page TIFF files into single-page TIFFs; merging single-page TIFFs into multi-page TIFF files; converting TIFF and other image formats (JPEG, BMP, etc.) into PDF files; combining reports/COLD text files into files based on report type and date. In addition to the file conversions/manipulations, report types & document types are generally remapped to match the target system configuration. Account numbers may be remapped, and other data manipulations may be performed.
  3. Formatting the data into the necessary load formats for the target systems. This could be DIP files for loading into OnBase, proprietary XML load files, or others depending on the specific requirements of the target system.

Source System

Image Archive

COLD/Reports Archive

Database(s) with metadata

Neutral Format

Native image formats

ASCII text

Metadata de-normalized

Delimited text files

Target System

Formatted Images

Formatted Reports

Metadata in specified load format

In addition to these basic steps that occur for each project, there is the need for careful analysis and the development of custom code (conversion tools, scripts, and database queries). There are also other factors that must be taken into account when performing data conversion/migration projects. The following sections go into these in more detail.


The secure transport and processing of all customer data is a top priority. As such we make use of encryption, secure network environments, access restrictions, stringent security policies, and other tools & technologies to ensure that all customer data is protected.

Source System Data Copy

One of the first steps in any conversion project is to obtain an offline backup copy of the source system. Generally this is a copy of the image repository along with a backup copy of the database. In the case of back-end storage management products (e.g. Tivoli and Centera), we require that the contents of the image repository be exported out via either tools or API provided with the storage management product.


After we receive the data, the database is copied to one of our servers and restored for access via the appropriate database engine. From there, we start an analysis of the database structures and metadata that is stored. We identify document & report types, metadata index fields available and the mapping between the database records and the copy of the received image repository. From this work, we generate the initial mapping spreadsheet(s).

Depending on the nature of the source system databases and data structures, we may need to develop custom proprietary software components to assist with extraction of the objects and metadata from the received repository.


Our development efforts can include the creation of custom proprietary utilities for data extraction and processing. Often times, the writing of these proprietary utilities entails reverse-engineering the source system data and file structures. Other development efforts include the creation of SQL database scripts and queries to convert the metadata and format it for ingestion into the target application. We also develop scripts and other proprietary automation tools to aid in the conversion process.

Data De-Normalization

In the case of imaging systems especially, we need to take the normalized database structures from the source system and flatten or de-normalize them. Generally, this entails breaking the index data down and extracting it out at the document (or page) level. The document oriented index data is written to delimited text files for use during the actual data processing as we extract and convert the source objects (images, reports, files, etc.) into a neutral (non-proprietary) format.

Production Processing

The production processing generally consists of: 1) extracting the data objects (images or reports) from the proprietary source system formats; 2) re-formatting the extracted data objects into standard (or neutral) formats; 3) converting the "standard" format data objects into the necessary formats for loading into target application.

There is not a single monolithic application that we use for this production processing. Depending on the source system and the processing that may be required, we could use a variety of our custom proprietary utilities to perform these steps.

Often times, some or all of these processing steps are automated to facilitate the processing of this data in manageable batches. However, regardless of the level of automation applied to the processing steps, the conversion process is monitored by our highly trained technicians.

QA/QC and Reconciliation Process

Project reconciliation will be done on an object (document, page, report, etc.) basis, generally driven by the source system database. We verify receipt of all the referenced source files, and then also that we were able to extract all of the documents. We also perform a verification of the document import/load files for the target system both looking at the integrity of the load file as well as to compare their contents to the source system database and image store. This will provide an end-to-end verification of the conversion of each document. After the converted data is loaded, the customer typically performs random validations of the data from within the new environment.

Output Data Copy

The final converted data is then copied to encrypted external disk drives for transport to the customer. The data is copied in such a way that it can be quickly and easily loaded into the customer's system with minimal impact on access or performance.

The encrypted media is then shipped to the customer, using a national carrier that can provide shipment tracking (e.g. UPS or FedEx).