With all the focus on the Dynamics 365 Customer Engagement naming, the split into Dynamics 365 for Sales and Dynamics 365 for Customer Service, with or without Marketing, and all the licensing implications and additional functional packages, this is a question that came out of the blue and caught me a little off-guard. While I’m still working on a few on-premise instances, all the licensing discussions lately have been around the online model. As such, maybe I haven’t paid enough attention to versioning for on premise, my bad.
Now, the good news first, there is Dynamics 365 for on-premise, in name at least.
Have to be honest on this one, I think marketing made a few people confused though. Why is that?
Well, look it here: we had Dynamics CRM 2015, then Dynamics CRM 2016. The 2016 release was in fact 8.1
Then came the update to 8.2, along with the name change. But, it’s not a major release. That was just an incremental release.
9.0 came a full cycle after, and the Dynamics 365 nomenclature was already out.
Then there’s the feature set. It’s always been understood that certain features are not available on-premise. And that is fine, we expect that. The features are actually described here: https://technet.microsoft.com/library/mt812192.aspx
To put it into perspective, the on-premise feature set has evolved at an almost unchanged pace from before, with regular incremental updates and features that are probably just necessary to keep the product viable. It’s a different story in the online space, where the evolution has seen a rapid pace, with new solution offerings, integrations into now related platforms, and various other capabilities.
The internet is full of articles on why Cloud, Cloud first, and how it’s time to move your CRM from the traditional on-premise model to Online. And on this instance, the mean marketing engine did in fact a great job. Now it’s on everyone’s mind.
And yet, in a more conservative segment of the market, Online is not always acceptable. Let’s see why:
Existing investment already in place
Ok, not many organizations have the infrastructure in place to host a full on-premise deployment. But for those that do, it’s a at consideration. They probably have either their own data centre, or renting space in a data centre already, have a few more years on the contract or are getting a great rate. Then, why not take advantage of that? Also, if you are a 3rd party hosting provider, or provide a managed service model that includes the hosting for better control, then you’re using on-premise.
Data, privacy and complete segregation
Ok, maybe a little paranoid after the last few years of hacks and cyberattacks, but also trying to comply with stringent regulations or very restrictive security policies, in an on-premise deployment only you own the data. You can have a non-IFD (internet facing deployment), with no external access to your CRM. That way, even for VPN enabled users, you can restrict access to only specific internal resources, not including your platform.
Complete control over the update/upgrade cycle
This is a consideration for organizations transitioning from small to medium. They most likely do not have IT support staff, they do not make modifications to the configuration or customizations, and they prefer to not have to deal with “changes”.
Specialized development platform
Very far in between, but these deployments do exist out there. None of the typical functional modules are in use, the platform is in fact used as an enhanced development platform for very specialized solutions. In most circumstances, there will probably be unsupported customizations, and the solutions built will not live through a typical upgrade process.
Leverage existing in-house resources
This was touted a while back as a feature, but those resources nowadays can be used just as well for online deployments. I don’t really look at it as a decision point.
Extensive custom integrations to other legacy on-premise solutions
This is a big one. Some organizations still use very old legacy systems, and they have built integrations. Most of these systems do not support a deployment model in which they can be securely exposed to a cloud deployment model.
Speed of data transfers and integrations to other on-premise platforms
When pushing large amounts of data back and forth between systems, or a data warehouse, or specialized custom algorithms performing extensive analysis, like for fraud detection for example, proximity makes a huge difference in speed and possibly cost. Again, maybe not too common of a scenario, but nevertheless a consideration.
Limitations in customization options
Yes, with all the features added to an online deployment model, some limitations do exist due to a shared resources model used in online. One very simple example is the limitation on reporting using SSRS reports, but there are others to consider too.
Conclusion
With all that being said, for the most part, the case for online is a very good one. But do keep in mind, there are situations where an on-premise model is still the preferred approach. This is one of the greatest platform benefits that some of the competitors can not offer, and it’s what sets the Microsoft offering apart by a long shot.
Do any of these items described applies to your business model? Do you have any other specialized cases where an on-premise model is better suited?
Let me know in comments below.
thatcrm.com 