I have discussed at length in this column the rise in recent years of the new breed of insurance software vendors. I have characterized these "new kids on the block" as being better software developers that produce better and more configurable software, are better implementers (usually employing some form of agile methodology), and generally are more client-centric. So, when you finally decide to bite the bullet and replace that ugly, old legacy system, the obvious place to go is to the new vendors, right? Well, maybe.

What about that vendor that wrote that ugly, old legacy system? Why would you possibly want to talk with that company? No reason at all, unless that company has written a new system, which several of the legacy vendors have in recent years. In addition to chronicling the rise of new vendors in our market, I also have commented on the fact many legacy vendors, recognizing the existential threat posed by the newbies, have upped their game by upgrading current systems, writing new systems, becoming more client-friendly, and working to improve delivery. If your legacy carrier falls into this group, there are several compelling reasons at least to consider the devil you know when assessing your legacy replacement options.

First, a legacy vendor likely has a functionally mature system to use as a blueprint for what the new system needs to do. I held it as axiomatic for many years when searching for new software, the choice came down to getting technology (and configurability) or functionality, but not both. While this statement is no longer axiomatic, it still is worthy of consideration.