Cloud versus on-premise CRM

by Richard Boardman on February 3, 2016

I got involved in a forum thread on LinkedIn over the last week, the gist of which was whether the implementation approach was different depending on whether you deployed CRM in the cloud or on-premise, and what the pro’s and con’s were of the two means of deployment.

I can’t recall having written on this before (which doesn’t mean I haven’t by the way!), so I thought I’d put together a post, particularly as I think there’s a myth or two that needs to be addressed.

If we go back to the early days of software as a service, as took on the likes of Oracle and SAP, the debate seemed to polarise with Salesforce in one corner as web-based and easy to set up, and Oracle and SAP in the other, as client-server, complex, and inflexible.

The problem was (and to some extent remains) that these differences were often perceived as being down to the means of deployment (i.e. in the cloud or in-house), rather than simply being differences between the CRM applications themselves.

The fact that there were plenty of web-based, easy to set up, on-premise CRM options was often missed.

When I noted in the forum that I saw no great difference between the implementation approach for a cloud-based CRM project versus an on-premise one, there seemed some measure of surprise, which I suspect results from a lingering perception in some quarters that cloud is by definition quicker and easier to deploy.

There certainly are some aspects of cloud that do lend themselves to speed of deployment.  Firstly, there’s the potential to short-circuit the procurement process. One of the reasons for’s initial success was that low up-front costs combined with user configurable functionality, and no requirement to install software locally, meant that purchasers could bypass the potential road-block of the IT team, and in many cases the procurement process altogether, because expenditure fell under sign-off limits.

Secondly, cloud removes the need to set up the software on servers as is needed for on-premise.

That said, if you’re looking to do something meaningful with CRM, then working with the IT department rather than around them is generally the preferred option, with most organisations now wise to the arrival of CRM in stealth-mode.

The software installation step might be a relatively big chunk of time if you’re looking at deploying out of the box functionality to a handful of users, but in larger projects it’s a comparatively trivial task in the overall implementation cycle.

It’s also worth pointing out that, contrary to some perceptions, cloud doesn’t have an inherent speed advantage in terms of the actual configuration and customisation of the system, with most modern CRM systems being quick and straightforward to tailor.

So from my perspective anyway, whether you’re electing to run CRM in the cloud or on-premise, has little bearing on the implementation approach itself. There’s still the need to define requirements, design and set up the system, integrate, migrate data, test, and get people using it in a consistent and structured way.

With a wealth of web-based, easy to set up and use, feature rich, CRM software options available in both cloud and on-premise flavours, the choice of whether to go cloud or on-premise should be dictated by individual circumstances. Cloud-based has a lot of advantages, which include:

  • Speed of deployment can be quicker, for the reasons I’ve described above
  • There’s generally less up front cost because licences tend to be paid for on a monthly or annual basis
  • You don’t have the cost and worry of setting up and running in-house servers
  • Updates and upgrades are quicker and easier

While these are strong benefits, there a number of reasons that for some organisations cloud-based might not be the right choice:

  • It requires reliable internet access. Relatively ubiquitous though it may be, not all would-be users have it in all locations that they work from.
  • There may be current or potential legal constraints about storing data remotely or in specific geographies
  • Where organisations are particularly sensitive about having direct control of the data they manage
  • In some instances (and this really needs to be analysed on a case by case basis) on-premise can be the cheaper option over the life of the system
  • Cloud users can be hostage to potential hikes in subscription fees
  • The impact of a CRM software provider going out of business is likely to be more acute for a cloud user rather than on-premise. I can only recall one example of this happening, but as the market consolidates over time I suspect we will see more casualties.
  • Finally, organisations running mission critical systems, particularly where there are high levels of customisation or integration, may prefer the ability to better control the management and timing of upgrades

While the majority of projects we work on these days are cloud-based, it’s certainly not all, and it’s important to keep an open mind and match the means of deployment to suit each situation. What’s right for one project may be a hundred percent wrong for another. But whichever approach you take, implementing it the right way is what determines success or failure, and that doesn’t change whether it’s running in a vendor’s data centre or down the corridor in your server room.

[Facebook] [Google] [LinkedIn] [Twitter] [Pinterest]


It’s the outcome that counts…

by Richard Boardman on January 24, 2016

I’ve worked on a couple of system reviews in recent week for clients who felt their CRM system wasn’t living up to expectations.

Interestingly, in both cases the systems were reasonably sound. What was missing were the finishing touches.

This is a common problem. Salespeople often dazzle their customers with wizzy demonstrations of things like dashboards and mobile apps, but invariably what’s delivered looks rather less glossy. This in turn often leaves the customer feeling rather short-changed.

So why does this happen? For two reasons I suspect:

Firstly, I think in many cases there is a lack of clarity as to what the final deliverable looks like, often because there’s insufficient focus on clear business outcomes.

Secondly, accountability for who is doing what in the final set up of the system. Implementers will generally expect their customers to undertake some of the softer configuration of the system, but these responsibilities aren’t always well defined or articulated and sometimes simply don’t get done.

The solution is straightforward. Implementers and the customers need a common understanding of what the final deliverable looks like, and clear responsibilities for delivering it.

In my book that should be defined as part of the requirements gathering process, but the key that it is documented somewhere.

Would-be implementers of CRM need to be mindful that doing 99% of the project well isn’t sufficient. It’s the final 1% that generally determines success or failure.

[Facebook] [Google] [LinkedIn] [Twitter] [Pinterest]


An independent review of Pipedrive

October 19, 2015

As products like and Microsoft Dynamics have increased in functionality and moved up the food chain in terms of target market, opportunities have inevitably opened up for new entrants in the CRM market. One of the most successful has been Pipedrive. Set up in 2010, and based in the US and Estonia, the company [...]

Read the full article →

An initial assessment of Microsoft Dynamics CRM 2016

September 13, 2015

Microsoft released their Dynamics CRM 2016 Preview Guide this week (here) and a one minute fifty two second release overview video (here) , which set out what new capabilities will be available later in the year for both CRM online and on premise versions. Microsoft release documents aren’t the easiest to interpret, (lots of impenetrable [...]

Read the full article →

Eight entirely plausible beliefs about CRM that don’t stack up in reality

September 5, 2015

I’ve been involved (at the time of writing at least) in the CRM industry now north of twenty years, eleven of which have been spent as an independent CRM consultant. Over that time I’ve been involved in, or a spectator to, hundreds of CRM projects, involving a wide range of CRM technologies, across the full [...]

Read the full article →

It’s not the technology, it’s you – a seven step plan to turn your CRM system around

July 11, 2015

Not so long ago I wrote a post called ‘The coming Zombie CRM Apocalypse and what to do about it’. The gist of the post was that a lot of CRM systems, while technically functioning, don’t contribute much to the health of the organisations that run them. While I outlined a number of steps to [...]

Read the full article →

Sales automation technology

May 31, 2015

One of the big movements in recent years has been the rise of marketing automation technologies such as Marketo, Eloqua, and Pardot (to name but a few). These systems are designed to help marketers move prospects through the sales funnel from initial interest to leads that are sufficiently qualified to pass to the sales team. [...]

Read the full article →

How to implement a CRM system – fast

May 17, 2015

We’ve worked on a few projects in recent months where there was a compelling need for the system to be implemented quickly. This isn’t as easy as it might first appear. There’s only so much that you can compress the major building blocks of a CRM implementation, such a requirements definition, vendor selection, design, build, [...]

Read the full article →

The increasing power of CRM portal technology

May 4, 2015

One interesting area of CRM technology whose potential seems yet to be fully realised is the use of portals. A portal is a website that serves as a gateway to the CRM system, and allows third parties, such as customers or partners, the ability to create and update records within the CRM system without being [...]

Read the full article →

How to gather and document a CRM requirements specification – The ebook

April 23, 2015

I’ve written a lot over the years about the importance of requirements gathering when implementing CRM systems. For me, the CRM requirements specification is the foundation of a CRM project, and I don’t believe there’s any other element that has as much influence on ultimate success or failure. What’s surprising however is that there’s so little [...]

Read the full article →