One Shield – Data Conversion Should Be Treated as a Separate Strategic Initiative

Given the importance of successful data migration to core system replacements and consolidations, and other major projects, it should be treated as a distinct strategic initiative rather than merely a subordinate task.

By Steve Forte, OneShield

Given the competitive and information-intensive nature of the insurance industry, carriers today recognize the importance of using data more tactically. In fact, sharing data across the company and analyzing it quickly has become a mission-critical priority for insurers working to effectively respond to market changes and competitive pressures. Unfortunately, turning data into an actionable asset is often not a straightforward task. This is especially true when it comes to the process of obtaining the data from various sources, normalizing it and, ultimately, transforming it into a strategic advantage.

It is well-documented that legacy system replacements and core systems consolidations have high-failure rates, due in part to the sheer scope and complexity of the projects. Data conversion is tied closely to system conversions, and adds an additional risk factor because this aspect of legacy replacement and systems consolidation is not typically well-articulated with regard to the who, what, when, why and how of the project. In fact, data conversions are often managed within the legacy replacement project as a sub task. Given the importance placed on successful migration of data for historical analysis, it deserves visibility as a distinct strategic initiative.

Bumps in the Road

When faced with the inevitable need to move data from one system to another, putting the right emphasis on data conversion at the outset can help insurers avoid some obvious bumps in the road. For example, getting the right people, including data architects and business users (such as underwriters if it is a policy administration conversion project), involved in the requirements definition for the conversion will ensure the right data (and the right amount of detail and history) is scoped to reduce waste or missed opportunities for future data analysis.

In addition to cross-organization buy-in for scope and requirements, other obstacles must be identified with risk mitigation plans. Examples include taking into account the potential effects of rigid legacy systems that inhibit data sharing and integration, poor data quality due to inadequate data collection or manual data entry practices, data siloed due to organizational growth via acquisition, and disparate information systems with incompatible formats. Analyzing these potential data challenges and preparing appropriate risk mitigation plans can mean the difference between a smooth transition and unnecessary business interruption.

Solid Planning = Successful Conversion

While solid planning by itself doesn’t guarantee the success of any data conversion project, the importance of managing data conversion as its own strategic initiative cannot be emphasized enough. This includes identifying a distinct set of IT and business stakeholders for the data conversion project as opposed to the overall legacy replacement or system upgrade.

Together, this team should clearly articulate the business rationale (and value) for converting data from the current system. It is also crucial to involve not just IT professionals, but business analysts, in the planning phases. Additionally, it is a good idea to involve a representative from each department that will ultimately need to access and utilize the data.

When planning for a successful data conversion project, keep the following guidelines in mind:

  • Treat the data conversion effort as its own project, complete with its own stakeholders, project management and governance to give it visibility as an important strategic initiative.
  • Carefully analyze and identify the critical and value-add data to be migrated, and map to target.
  • Plan for access early in the project to the actual source data for analysis, as there is often the opportunity for discovery of potential data quality issues or other unrealized data sources.
  • Pay attention to any structural, semantic and syntactical differences among the data sets when merging data from multiple sources.
  • Take into account all aspects of data conversion, including transactional data, statistical data, data-marts, ODS, and data warehouses.
  • Consider the requirements of not merely the target policy administration system, but also downstream systems such as billing, claims, data-warehouse and statistical reporting in the design.
  • Be alert to the possibility of unique application design requirements for converted data, e.g., validation or underwriting referral rules that will not be applied to converted policies or “grandfathering.” Identify and agree upon data conversion acceptance criteria up front.
  • Define performance requirements in time for performance tuning of the conversion process.
  • Perform several dry-runs with large data sets to flush out inconsistent source data, resource leaks or logic bugs.
  • Devote separate hardware resources and quality assurance (QA) environments to data conversion, as long-running conversion test cycles may consume resources that interfere with other development teams.
  • Ensure that the design contains a strong audit component to make certain that the process and its outcome can be monitored and reported accurately.

At the end of the day, each data conversion project will have similarities, but planning will expose key differences based on each insurer’s individual situation. Customizing the above checklist to fit specific internal requirements is an important part of the planning process.

Implementing a Data Conversion Methodology that Works

With the right plan in place, data becomes a strategic asset and a valuable business advantage. The challenge is how to get the data working for you when obstacles such as legacy systems and incompatible data formats stand in your way. Working with a flexible, scalable provider that has proven success with data conversion projects can help you successfully do this and eliminate unnecessary costs and complexities.

Once you find the right technology partner, you will want to address the following questions:

  • Do you want an automated or manual approach?
  • How much data needs to be converted?
  • What data sets should be converted when?
  • Can the data conversion process be re-used for other purposes?

With the strategy in place, detailing the specifications for data conversion becomes critical. Be certain to plan for a thorough analysis of the source data, prioritization of relevant objects/tables/files and attributes/columns/fields, data mapping from source to object model, specifying required data transformations and identifying balancing and reconciliation metrics.

Insurers can expect to gain significant operational benefits from a successfully executed data conversion project. Ideally, users will end up with an easy-to-use graphical interface and the ability to access data from drop-down menus. Additionally, it should be easier to more effectively generate essential reports, reduce manual processes and facilitate better customer service. In the end, your data becomes an asset that works for you and your customers, potentially giving you a distinct competitive advantage.

About the Author: Steve Forte is the director of global product management and alliances for OneShield.

He can be reached via email at [email protected].

About OneShield

OneShield delivers flexible, enterprise class and content-rich core systems for billing, policy, product configuration and rating. Based on an open, tool-based architecture, OneShield Dragon´┐Ż provides companies with the ability to streamline product creation, management, underwriting and distribution. With Dragon, P&C insurers gain a competitive advantage that helps them improve operations and profitability while meeting increasing customer and market demands. OneShield is headquartered in Westborough, MA and has offices in Glastonbury, CT and Gurgaon, India. Visit to learn more.