"Almost no acquirer ever says, in their first press release, that all investments in major architectural overhauls will now stop for one or more of the combined product lines, but that’s exactly what does happen," writes Naomi Bloom in Vendor Consolidation Fairy Tales.

Whether they are announced later or they are introduced as contract renewal discussions begin, changes are around the corner. In some cases, this can be a good thing for clients and users of an acquired company and its software. “Obviously, all acquisitions aren’t inherently bad,” writes Sharon Fisher in the enterprise.nxt article What to do when your IT vendor gets acquired. “Sometimes a merger really does create a ‘chocolate and peanut butter’ combination.”

Expanded functionality, better software performance, and improvements in service responsiveness and quality are just a few of the potential positive outcomes. Unfortunately, such outcomes aren’t always the result. Fisher lays out a number of potential changes that are likely to immediately —or eventually — follow an acquisition. These include:

• Scaling back the acquired company’s operations to reduce costs and achieve a better return on the investment
• Cutting back or eliminating product development budgeting and/or roadmaps
• Charging higher maintenance and support costs
• Ending maintenance for the acquired product(s)
• Aggressively cross-selling other products or functionality

And when an acquisition leaves the acquiring vendor with redundant systems and/or duplicative functionality, there is typically another outcome: Clients are eventually forced to migrate to a new system.

While a forced migration could potentially mean access to functionality not available in your current system, the reality is that the move will likely not be as simple or straightforward as promised. System migrations — forced or otherwise — come at a cost. Before agreeing to (and paying for) the move to a new system, asking questions of your vendor and listening carefully to the answers you receive can help you be better prepared and leave you with time to explore other options.

1) What are the hidden costs that accompany a forced migration?

System migrations are never “free.” On top of whatever you are being charged to move from one system to another, it’s possible that you may even be charged for migrating your own data. There are also additional “hidden” costs that should be factored in, such as the amount of time and effort required of you and your team. And even if your previous system had its limitations, many of your organization’s users “knew” that system inside and out. Power users likely had both the knowledge and, in some cases, access to system tools that allowed them to make changes and quickly resolve some issues.

Upon migration, it’s essential to know whether the new system requires a significant amount of training? If so, does your risk management technology vendor have plans for providing it? How long will it take for users to get up to speed? Once that happens, will system administrators have the same level of access they had before?

2) Will my team lose critical functionality and/or customizations with a move to the new system?

Despite assurances to the contrary, with the forced migration to the acquiring vendor’s new system, it’s highly likely that there will not be a 1:1 correlation between the features you currently have — and in a worst-case scenario, use heavily — and those available in the system you’ll be migrating to. When it comes to functionality, will you be losing anything? How might that affect your processes?

Beyond core functionality, this also applies to any custom solutions that may have been developed over the years. If they are not mirrored through functionality or settings in the new system, can they be easily recreated? If so, does that work come with a lengthy waiting period or additional costs?

3) Does your vendor have contingency plans should the move to the new system take longer than expected, or worse, fail?

A software system migration —forced or otherwise — is never a “push button” operation. Whether the promises are coming from an acquiring vendor or a competitor asking you to consider a switch, any message that doesn’t acknowledge this reality should be taken with a healthy dose of skepticism.

In addition to asking how long a migration will take, answers to the following are warranted: If multiple clients are being migrated to a different system, where do you fall in order of “importance” in relation to other clients? What is the success rate when migrating a system and data similar to yours? Have there been cuts to or departures from the client service team that potentially impact the migration? Will there be a period during which you’ll be forced to work in two systems?

4) Will service improve with the migration to the new solution?

As mentioned at the outset of this post, a common move following the acquisition of a software vendor is for there to be cuts to the acquired vendor's operations budget. In some cases, this may, as Sharon Fisher points out, come in the form of paring back “cost centers such as marketing and back-office groups.” It may also mean the loss — whether through layoffs or the decision to seek out a more stable workplace — of experienced members from the acquired vendor’s service team.

What will ongoing service look like with the migration to a new platform? Will requests for changes come with lengthy waits? Does migrating to a new system mean improvements in communication, additional expertise, or a more consultative relationship with your service team?

Consider your options

The acquisition of your risk management technology vendor by another provider doesn’t mean disaster looms, even if the acquisition does result in redundant systems and you are forced to migrate. Migration to the acquiring vendor’s system could potentially be beneficial to your risk, claims, and safety management efforts. However, as laid out above, there are other outcomes that can accompany forced system migrations.

If you anticipate that you will be forced to migrate from your current risk, claims, or safety software to the platform(s) of an acquiring vendor, you should seek honest answers to your questions about what migration will mean for your organization in terms of costs, functionality, and service. Should those answers indicate that migration will result in additional costs, loss of functionality, or below-average service and support, you have nothing to lose by evaluating other vendors and their platforms. In doing so, you may discover a better option altogether.

To explore your options and begin a dialog about what a potential move to Origami Risk could mean for your organization’s ability to more efficiently analyze risk and insurance data, prevent losses, control claim costs, streamline renewals, and reduce your organization’s total cost of risk, contact us to begin a conversation.

If you're looking for a guide to help weigh your options, take our Vendor Performance Assessment.