The good news is there are best practices insurers can employ to minimize the risks of conversion. From the experience of data conversion experts and insurers that have navigated their own conversion projects successfully, the following tips can help you achieve the results you're after in your next effort.

Treat the Project–and the People–as Mission Critical

“A lot of projects fail because the rationale isn't well articulated,” suggests Eyler. “Companies treat data conversion as dirty laundry rather than a business objective.”

In contrast, consider the philosophy of Northwestern Mutual. Bob Kowalsky, the insurer's vice president and chief architect, compares data architects to house foundation builders. “Even though they might not get invited to the open-house party, without them the home wouldn't be there,” he says. “We identified our data conversion project as a strategic initiative.”

That project was an eight-year effort, beginning in 1997, to convert data underlying the carrier's core contract administration systems for life insurance and disability income from Cincom's SUPRA to IBM's DB2, running on a zSeries mainframe.

Kowalsky indicates, particularly in a multiyear project such as this one, motivation is essential. “We focused on individual recognition for accomplishments, and on an annual basis, we pulled everyone together for a luncheon with the CIO,” he says. “Our managers focused on team building, both between members of the Northwestern Mutual data conversion team as well as the 'extended' team,” which included business and IT staff from impacted areas and from outsourcing partner InfoSys, which handled coding tasks associated with the conversion project.

More commonly, data conversion is one part of a larger application project. But in those cases, as well, recognizing the importance of the conversion component is essential to overall success.

“[Data conversion] should not be a little project off to the side,” cautions Mark Christman, director of conversions for the life and annuity division of CSC's Financial Services Group. “You have to assign the right number of staff members and make sure they're 100 percent dedicated to the project and also make subject matter experts available, both from an IT and business perspective.”

Clean Up, Upfront

We all know trying to convert “dirty” data creates problems, yet it still is a mistake many companies make. “Companies do not do enough data conversion to understand the right approach, and as a result, they discover how dirty their data is only when they are well into testing–far too late to start cleaning up data,” observes Jerry Kaul, chief marketing officer of Universal Conversion Technologies (UCT). “When data cleanup becomes a critical path item during a data conversion, you have screwed up.”

In Manulife Financial's late 2003 acquisition of John Hancock, a large focus of the insurer's IT staff was on data conversion issues associated with policy administration. However, many other areas of the company were faced with system consolidation issues and data conversion challenges. For example, the human resources department, charged with bringing former John Hancock staff onto Manulife's payroll, needed to move employee data off John Hancock's PeopleSoft platform system to Manulife's internally developed Oracle-based HR system, called EPIC.

“Not being able to manage our company, manage our employees, and maximize our return” was the risk of a failed data conversion, accord-ing to William Harmer III, assistant vice president of corporate human resources and distributed systems at Manulife. “We needed to be able to track employees and where they are both in the company and in the system and to make sure we were able to make the appropriate decisions with regard to restructuring the combined organization.”

Fortunately, Manulife had itself been a PeopleSoft customer prior to rolling out the EPIC system just months before the John Hancock acquisition and therefore was familiar with both systems as well as the conversion process. Manulife's data conversion issues primarily involved data quality. “There were discrepancies in job codes and salary grades as well as duplicate employee IDs and duplicate cost centers and descriptions [between the John Hancock and Manulife employee databases],” Harmer explains.

In identifying and solving data quality problems, data analysis and scrubbing tools can help with the job, but there's no substitute for a magnifying glass and a well-trained eye. “Finding fields with missing data or fields filled with all 9s are common problems, but someone needs to go in and do the analysis,” says John L. Johnsen, senior manager with Deloitte Consulting.

After identifying suspect data and making repairs in the John Hancock system, Manulife addressed many of the data redundancy issues by appending a source code to common fields between the two systems to indicate the origin of a particular value. Rolling all John Hancock employees to the EPIC system took five months.

While it is most important to address quality issues before the conversion process even is begun, ensuring data quality needs to be an ongoing effort throughout the project. For instance, in 2004, Sammons Financial Group began installing CSC's CyberLife administration system, starting with a block of whole and universal life business it had acquired, which had been administered on a homegrown legacy system. Sammons and CSC cleaned what data they could identify as problematic before the conversion, then they did incremental testing to find additional problems.

“It was an iterative process of running a conversion to a neutral file, comparing the results, fixing things, and repeating that until we had pretty clean data going through the neutral file. Then, we repeated that process as we went from the neutral file through the new-business process CSC uses to convert policies to CyberLife,” says Jim McAdaragh, AVP of business systems for Sammons Financial Group.

Assess and Address Knowledge Gaps

“My strong advice is to find someone who's done a conversion before, because to do one for the first time, you're going to make a lot of mistakes and the cost is going to skyrocket,” recommends Johnsen.

Like Sammons, Great American Financial Resources, Inc. (GAFRI), was faced with the need to convert an acquired book of business: 30,000 fixed annuity policies from a heavily modified ID3 system to PDMA's LifePRO, GAFRI's primary policy administration system. The problem, according to Dale Wilcox, GAFRI's vice president of strategic systems, was the company had no knowledge of the ID3 system. It engaged Universal Conversion Technologies to take charge of the data conversion aspect of the project.

“Our core competency is LifePRO, whereas one of the things UCT brought to the table was its knowledge of different industry vendors,” Wilcox says. In addition to using UCT for consulting and project management, GAFRI relied on UCT for data mapping and used the vendor's Data Conversion Architect (DCA) tool to perform the data transformation process.

In choosing a data conversion consultant, it's advisable to use the exercise as an opportunity for knowledge transfer for future projects. “The sooner you can get people trained and familiar with the [data conversion] process, the better,” says McAdaragh. “We thought [CSC] would do its work, drop us a gift-wrapped package on our desk, and we would move on. But we really needed to get our people involved and to have them try things, have them see what goes wrong and how to fix it. In retrospect, we should have ramped up for that earlier.”

Also, particularly for insurers inexperienced in data conversion, a trial run can be invaluable to help identify knowledge and skill deficiencies as well as to select needed conversion tools. “If I want to get a handle on how hard it would be to move data, I would use a low-cost [ETL] tool and simply prototype grabbing data out of the source system and moving it to a target database. What happened when I did that? What are the problems with the data model? How well do I understand how the data is organized? You can get a fast read on how hard it is to convert something and whether the data is bad or not,” notes Selip.

Don't Overcomplicate

As in nearly any systems project, scope creep can plague a data conversion effort. “When you get in and open up your data, there are many other changes you are tempted to make along the way,” comments Kowalsky. “We wanted to hold the line but in a way that would recognize there were some improvements that made sense. It was a real balance.”

For example, Northwestern did take the time to build a data access layer after converting the first database to make subsequent conversions run more smoothly. “We had technical access to the data before, but we wanted to loosen the coupling between the application and the data even more. We built a services-oriented access layer so that the application is removed almost completely from having to understand the physical layout of the data,” Kowalsky says.

Sometimes, resisting the urge to complicate the project can take you down a completely different path to a better solution. For instance, Allmerica Financial wanted to provide its agents access to policy information via Allmerica's agent portal. However, it also was important to offer that information in the same print format customers received to help agents better answer service questions. So, providing a field-based display wasn't sufficient.

“The problem was customers would call up the agent and say, 'I have a question about my policy on page seven,' and the agent didn't have a paper copy on hand. It could take days to get a copy before, if the agent had to have it mailed,” says Dave Trigo, chief architect at Allmerica Financial.

Allmerica initially planned to attack the problem at the data level by taking its AFP (Advanced Function Presentation) print streams, converting them into XML, and reformatting them for PDF delivery to the agent portal. This strategy would give the carrier data that potentially could be repurposed to other uses and delivery methods.

It quickly ran into problems with that approach. “Where we originally thought we had dozens of templates, we actually had hundreds because we had tailored the templates for individual customers,” says Mike Clifton, Allmerica's vice president and CTO. After four months of working on the project, Allmerica realized a simpler solution was what was needed. It deployed Whitehill Technology's TransformAFP software to convert directly AFP to PDF on the fly, when agents request a policy print via the portal, and completed the project in two months.

Complication of the data conversion task itself also can come from excessive customization of the new system. Resist the urge to customize, and realize the more target systems for which you need to convert source data, the harder your efforts will be.

“The functionality of our core system has been critical to our data conversion efforts,” says Wilcox. “We're in a unique situation where we administer all our products on LifePRO. As a result, we can look at just about any [company] acquisition and put [the book of business] on one system vs. having to decide what system to convert to or needing to convert to multiple systems. That leads to incremental cost savings, eliminates building multiple interfaces, and lets us leverage our competency with the admin system.”

Expect Problems

Despite the best data cleansing efforts, there will be balance problems–when the ending value on the source and target systems don't match for the same transaction. Part of the solution is finding out why–errors in the source system, rounding or calculation differences, or undiscovered code changes made to the legacy application over time.

The other part of the solution is planning for just what level of “imbalance” is acceptable. In a commercial lines premium calculation, a rounding difference even of a few dollars might not matter. But in an annuity, before and after cash values need to be exact.

“We identified about 20 'critical' values and fields,” says McAdaragh. “We decided at the outset of the project what our balancing tolerances were for each of those fields, and those are tracked in the reports the CSC conversion [tool] supplies.”

Plan for the Future

Insurers need to look beyond any individual data conversion project, both to avoid creating new problems as well as to plan for future conversion efforts.

Avoiding–or at least more easily solving–future problems begins with effectively documenting the data conversion process. “As you go through the project, you make decisions, particularly regarding data mapping. You need to have those decisions documented so that if at some later date you question a result, you know why you made the decision in the first place and what the impact might be if you change it,” Wilcox says.

Planning for future conversions may mean creating or investing in a data conversion toolkit–data analysis tools to help identify what data you actually have vs. what you think you have, tools for data cleansing activities such as name and address scrubbing, and automated mapping tools. Ideally, it also means creating a repeatable conversion process.

“Over time, we basically have created a 'data conversion factory,'” says Northwestern Mutual's Kowalsky. “The team we have is able to identify data patterns and potential problems and readily can create metrics around each one of these patterns to scope new project stages.”

“Our short-term goal was to move the block of business we acquired, but by the time we were done with that project, we wanted to have a Sammons conversion team that could do future conversions,” says McAdaragh. “We learned a lot through the first process that will help us deal with our [CSC] LIFE-COMM and LIFE/70 conversions that are coming up in the future.”

Last, in addition to these conversion-specific strategies, avoiding the risks of data conversion requires good project management, whether the conversion is part of a larger initiative or a project in and of itself. That means developing and managing a detailed project plan including all project-related tasks, dependencies, and critical paths; being willing to make decisions; and focusing conversion team communications on problems.

“You should focus on tasks that are behind schedule,” says Universal Conversion Technology's Kaul. “If you just focus on the things you got done you were supposed to get done, it quickly can become unproductive self-gratification.”

In the end, even though a data conversion process may not be celebrated for its successes, it certainly can avoid being the center of negative attention.

“In the final years of the conversion project, we were invisible–45 weekends out of the year we had conversions going on and you would never know it,” Kowalsky relates. “I had to make a point of bringing it to our CIO so nobody forgot about the work we were doing, but that meant we were doing it well.”