From a legacy vendor's viewpoint, the obvious strategy with a new system is to enter the market by converting current clients to the new system. This requires a high degree of functional equivalency. A legacy client is not going to go through the trials and tribulations of converting to a new system only to be faced with a significant functional shortfall.

Comfort in Familiarity

Second, your legacy vendor knows a lot about your specific business and probably assisted with the implementation of many of your lines of business in many states. As noted above, this is no trivial matter. One of my favorite questions to add in a carrier RFP is not the usual "Does your system support the following lines of business in the following states," but "For the following line of business and state combinations, tell us where your system is in production and define what in production means." The former question elicits a potentially misleading yes from all the vendors, based on the disingenuous rationale the system is "built to support all lines in all states." The latter question gets at the details of a possible implementation reality, where a vendor may have to gather, configure, and test many processing requirements in order to support your business. This functional gap can grow exponentially with the number of lines of business and state combinations supported by the carrier.

Third, your legacy vendor probably knows your application system and can extract business rules and processing details better than anyone, except possibly your in-house IT team. This is important in trying to configure a new system to perform required, detailed tasks, such as product definitions and rating algorithms, so those things that have to remain the same from an old to new system are done accurately and completely.

It is a common realization on legacy replacement projects the business users know only so much about how the current world works and frequently end up appealing to those few IT staff members who have supported the legacy system of years and actually know what the system does. The reality on every legacy replacement is few people know the details of the current processing system; the system is poorly written and badly documented; and it is basically impenetrable to outsiders. There also are legal restrictions on third parties looking at vendor code, which further increases the challenge of understanding how the world works today. So, having the vendor that wrote the system involved in its replacement reduces both cost and risk.

The Data Dilemma

Fourth, your legacy vendor probably understands your current data structures well and therefore is in a much better position to assist or lead in the onerous task of data conversion than any new vendor. As I have commented in the past, legacy replacement is not a project–it is a program of interrelated, projects, and one of the most challenging is data conversion. Be it policy, claims, or other related data, conversion represents a one-time software development effort (assuming an automated conversion) nested inside of a "package" implementation.

Having a vendor that knows both the source and target data structures and that is motivated and capable of leading that transfer is a huge benefit. The difficulty of data conversion varies depending on several parameters: Is only current data being converted, or is history included? If history is included, how much history is there, and how many changes in data format and use are included in the fossil record? What is the delta between the current and new data formats? What data volumes are we talking about? And finally, will the conversion happen as a "big bang" or gradually over time?

All these questions affect the risk and cost profile of a conversion. To the extent the vendor knows the answers to these questions, has both knowledge of and access to the legacy data, and even may have taken the delta into account in designing the data structures for the new system–all this can create a large advantage for the carrier. I hear of very few successful "in-force" data conversions, but I heard of one recently, and guess what? The same vendor wrote both the legacy system and the new system and led the conversion effort.

Fifth (and closely allied to the prior point), your legacy vendor also knows how all the configuration tables for roles and authorities, document definition and selection, and all the other myriad "setup and admin functions" are defined in your current system and how to map and import them into the new system. The simple act of setting up all the administration tables in a new system can amount to weeks or even months of work and carries a significant testing load with it. So, again, having a knowledgeable and motivated partner leading or supporting the effort is a significant plus point, especially if the vendor develops a migration path that includes the automated transfer of all this critical metadata.

Sixth, and last, your legacy vendor wants to sell you the new system and wants, over time, all legacy clients to migrate to the new platform, so the vendor probably will offer you a deal! Take it from someone who is a vendor: It is much easier to sell to your existing client base than it is to acquire new customers. In addition, it is easier to sell a new system to new clients if you already have reference-able customers using that system. So, selling to the "installed base" is quicker and easier, carries a lower cost of sales, and gains momentum for a new product. Also, as we noted above, over time the vendor wants to migrate all its legacy clients to the new platform to simplify maintenance and support.

So, what about this deal? Well, if the vendor has an installed base of 50 legacy clients the 50^th client to upgrade isn't going to get a deal; in fact, it probably is going to get an ultimatum along the lines of: Upgrade or you are off of maintenance (which may in reality mean little or nothing). However, the first two or three–the "early adopters"–could well receive significant financial incentives in terms of license and even implementation costs to bear the pain that inevitably comes with being (one of the) first.

So, all in all, there are several compelling reasons to talk with the devil you know before simply assuming a new system equates to a new vendor.

George Grieve is CEO of CastleBay Consulting. Previously a CIO and still an acting consultant, he has spent much of the past 25 years with property/casualty insurers, assisting them in the search, selection, negotiation, and implementation of mission-critical, core insurance processing systems. He can be reached at 512-329-2619.

The content of "Shop Talk" is the responsibility of the author. Views and opinions are those of the author and do not necessarily represent those of Tech Decisions.