We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.

Too often during my career I have seen customers over-emphasize user interface experience and functional features when making a CRM vendor decision. While both elements are important, they cannot outweigh the long-term stability and performance of the platform, which both are built on. Think of it this way — if you were buying a house you are likely going to focus on what the house looks like, because that is what you will see everyday as long as you live there. You are also likely to look at how the house will function, such as room layout, bathroom locations, kitchen size, etc. But if this house is built on a foundation that will crack in four years, regardless of the appearance or layout your investment will be officially known as the money pit.

In my near-20-year career of covering vendors I too often saw too many platform shifts cause unexpected migration costs, or worse case, cause major business disruption. I can't tell you how many times a customer would call me saying a vendor announced they are going to End of Life the current version of their cloud offering and now the customers are forced to migrate and absorb the expense or kick off an RFP process to evaluate new vendors.

Most, if not all, of theses cases resulted from the customer not doing the proper due diligence on the platform during their initial evaluation process. This is a direct symptom of a vendor's CRM development resources being shifted to building a new CRM application on the shiny new platform because the old one had developed cracks. This scenario often plays out because an on-premise vendor rushed to the cloud with their initial offering. This comes about because a vendor goes through the following 6 stages:

1) Denial - The on-premise vendor denies the value and power of the cloud because the vendor does not have an offering and it is the only way to protect their revenue stream.

2) Pain - The vendor comes to the conclusion that denial will not work and their business starts getting negatively impacted.

3) Anger - Management gets angry with competitors and puts blame on the sales organization because they are not meeting their numbers.

4) Depression - Management now realizes they are in trouble and they somehow have to get to the cloud in some way, fast, and pretend it has always been on their roadmap.

5) False Hope - The vendor quickly develops a cloud version of their on-premise product or creates a new version of their existing product on a new platform that will cause current customers pain when they will be forced to migrate (did I also mention the customers don't always know they will need to migrate to a new platform?)

6) Instability - The vendor is now forced to support multiple versions of the “same product” on multiple different platforms, leading to limited innovation that starts a downward spiral as current customers get frustrated and new customers do not have the functions and features in the new product that will help them be successful.

Every CRM vendor I tracked in my career who started in the on-premise world went through these 6 stages. It is amazing the consistency. Some vendors would launch up to three products in a 10-year period, others would build a separate cloud platform outside of the company's overall cloud platform strategy. This is why I would always tell customers to make sure they inspected the stability of the platform (aka, the foundation) or else they would face migration costs, or worse yet, business disruption in the future.

Here are the four basic questions I advised customers to ask vendors during their evaluations:

1) Did the vendor port and continue to support their traditional on premise application?

The main problem here is the vendor is taking a legacy database centric model versus a meta-data multi-tenant model strategy. This directly goes to the heart of limiting the velocity of innovation in the product, often requiring customers to use special tools to test customizations and configurations prior to upgrade. Cloud-first CRM platform apps simply upgrade without disruption, eliminating any possibility for business disruption and lower TCO.

2) Is the vendor's CRM application on the vendor's core cloud based application platform, or do they create a one off platform just for the CRM application?

It is not if but when the vendor will be forced to shift platforms. This often happens when a CRM team was forced to have a cloud offering before the vendor's platform team built their core development platform. Ultimately, and this has been proven in every vendor I covered, the CRM development team will be forced to port off of their legacy platform they built for speed to market reasons to the new core development platform of the company. This leads to End of Life for the CRM app built on the legacy platform and directly leads to business disruption for the customer and unexpected costs for migrating to the new platform.

3) Does the vendor have a 5 - 10 year track record of customers upgrading on their CRM app platform without any significant migration issues?

For those of you that are not technical there is an even simpler way to evaluate a CRM vendor's platform. If a vendor does not have at least a 5-to-10-year track record of the same cloud customers on their platform, they are likely at risk for a port in the future. The reason is vendors who were not cloud-first often face a 5-year re-platforming cycle. This, again, is supported by data over the past 15 years that I have accumulated in my coverage of 100's of CRM vendors. Cloud-first vendors do not face they same platform recycle issues, therefor provide customers with a stable environment that is proven by strong renewal rates.

4) Is a vendor transparent on their product roadmap?

Vendors who are in the middle of porting to a new platform are often reluctant or vague in the product road map commitments. The reason is because they are constantly battling how much development resources are devoted to porting versus building new capabilities.

The bottom line is that when you buy a house, you inspect the foundation and you ask the questions until you know it is dependable. When you purchase a CRM application, you need to follow the same process and start with an evaluation of the platform. Your stability, future costs, and sanity will depend on it.