Deployment choices have trade-offs and to make good decisions, organizations need to equate values on the following factors so that their decision is based on the entire problem set. This blog compares the differences between the two deployment methods for Microsoft Dynamics CRM specifically. Although some of the items apply to software as a service (SaaS) and on-premise deployments generically, some other items like reporting, are specific to Dynamics CRM. The goal is to account for most of the categories but there may be other items to consider.
Many clients are concerned that when they store data on Microsoft’s data centers that there is more risk of being compromised than if it was on their own servers. This may be true for an on-premise deployment that was not an internet facing application but most of our clients want the application to be available to users via phone and tablet and therefore, are deploying Dynamics CRM on-premise as an internet facing deployment. This configuration can expose the application to hackers. At this point, it is rare to see a small or medium business with as many resources dedicated to security as Microsoft has in their data center team and its not to say that all small and medium customers have no security, but only to say that Microsoft’s data centers are well managed and secure. In addition, they have all software patches installed on the gateways, operating systems and other applications that serve as interfacing technology for the application. They also perform penetration tests often as well as have specifically trained staff that specialize in setting up and running internet facing applications.
For an organization to deploy an internet facing deployment of Microsoft Dynamics CRM on-premise, they need to account for the skill set needed to set up and run the application and internet hardening. There is nothing preventing a smaller IT group within an organization from being very proficient at doing these tasks but they will need to account for personnel, training and equipment choices. If the organization is not prepared or able to do this, then they should hire the appropriately qualified partner to take on this function. A partner like RSM provides these services in our risk and infrastructure groups.
One of the traits of almost all SaaS applications is that they are upgraded within a single window for all users. This is true for Microsoft Dynamics CRM Online. This means that Microsoft informs the customer when an upgrade is coming and gives them a time frame when the upgrade will be available. The organization has some leeway to choose the time but when the window closes, the application will be upgraded regardless of readiness. This rarely has a negative effect to users however, if this is a retail business and the upgrade comes between October and December when most retailers see 80% of their revenues, then it could be hard for them to upgrade if their resource are limited.
On-premise implementations can perform upgrades to a schedule that is set up by the organization. We recommend software assurance to be purchased from Microsoft on all software included in the Dynamics CRM deployment so that organization remain current on all versions of the software. This will allow an organization to move from on-premise to SaaS if needed and ensure that they have the latest security features available.
One more item to consider is that Microsoft has chosen a “Cloud First” model for feature deployment for Dynamics CRM. This means that all features will debut online before being available in on-premise version. On-premise deployments may lag behind online, up to 9 months in some situations, and organization should consider the model in which they want to operate.
Integration along with price, are the two most common topics used for choosing between SaaS and on-premise. Microsoft Dynamics CRM does not have integration features built into the product outside of simple file import and export. This means that all integration to the application needs to be handled externally to Dynamics CRM. This is commonly done through third party applications like Scribe Software and Cozyroc. These applications call the application programming interface (API) but are housed somewhere else for execution. In the case of Scribe, they offer an online version which is hosted by Scribe servers. As for Cozyroc, you would need to host the integration application locally. This is common when integrating. Although you can do integrations through custom .NET programming, you still need a place to host the code. This code cannot be hosted within Dynamics CRM so if you are integrating between Dynamics CRM Online and another cloud based application, you would need a third cloud space like Microsoft Azure to host your integration code. These monthly costs need to be considered along with other issues like upgrades and testing which may be required when changes occur.
When integration needs are between an on-premise application and Dynamics CRM Online, then you need to consider the bandwidth and security of the integration during design. When you integrate between the two environments, the connection needs to be secure and there needs to be an adequate level of logging to maintain the integrity of the integration. Integration between the two environments is not overly difficult but it does require different asset allocations than if the applications both existed in the same environment.
Microsoft Dynamics CRM Online does not allow direct access to the database which means that custom reports using SQL Server Reporting Services (SSRS) are executing used FetchXML language instead of TSQL. FetchXML and TSQL have some differences between them and the most noticeable is the ability to create TempDB tables and then query from them. In the online environment, this setup is challenging due to the unpredictable resource allocation. As such, there is no ability to currently do this which prevents some reports from being created in the same way in both environments. There are some workarounds depending on the configuration that include creating a Dynamics CRM entity that serves as the roll up container that the report would then be run against. Another popular solution is Excel and the Power BI tools. The feature of using Excel as a report interface has always allowed Microsoft Dynamics CRM an advantage in the reporting space. For each scenario where the difference between TSQL and FetchXML is noted, there will be an additional cost for the workaround. This cost must be accounted for in the original project and subsequent upgrades.
When addressing the customization of Dynamics CRM, the two deployment options are very similar. As new features are introduced, we anticipate that there will be more parity between the two environments. With the earliest versions, there were items that were not available online like plug ins and now, they are available in both deployments. However, in the online environment they need to be sandboxed, and can make a difference in the work required to do the plug in. In addition, there are limitations to the number of custom entities available between the two with more available for the on-premise deployment. We anticipate that this is a moving target and although we should look into these limitations, we also need to understand that this most likely will change in the future and therefore it is a weighted decision. Where today the difference is in the amount of custom entities, the next release may change the number or eliminate the difference all together. This is an area that always need consideration with an eye to the future but assume that the on-premise version will always allow more customization.
Implementation costs are larger with an on-premise deployment because you need to include server setup for each environment which includes development, test, quality assurance, production and training. There is also time in each project for performance tuning and security setup. These items are handled for online deployments and the actual time it takes needs to be evaluated along with the IT capabilities of the organization. There is time that needs to be allocated for the transfer of solutions and data between the environments, like a development and quality assurance environments. The process for on-premise could be as simple as a backup and restore of the database. This works for some organizations but does not take into account the need for integrations, quality assurance data and other factors, like the environments being in different domains. For online, there are fewer options and the transfer between organizations is primarily a solution move accompanied by possible data movement . These steps should be predetermined and planned out so they happen the same way each time reducing the chance for error being introduced into the activity. When planning an online implementation, there needs to be time dedicated to account and security setup with Active Directory online and how that needs to be linked into the local Active Directory if present.
The pricing model differs in the obvious way of subscription versus capital costs. Today the software cost online is about 5% of the on-premise cost as a per month charge. Of course, these monthly costs does not include any of the costs for the underlying operating system and hardware. These costs vary per organization but it should be noted that Dynamics CRM runs very well in a virtual environment. We recommend evaluating these costs in a five or ten year comparison. It should be noted that the online costs are forever. When you stop paying for online, it no longer works.
In conclusion, the cloud and specifically a SaaS deployment of Microsoft Dynamics CRM, is a trend that is only going to increase in use. As organizations look into what this means to their resources, it needs to be done in a holistic fashion. We hope that this information has sparked great conversation within your organization and helped solidify your choice of deployment for Microsoft Dynamics CRM. Both options are fantastic and we serve very satisfied customers in both deployments of Dynamics CRM and have moved deployments in both directions. The facts and topics contained here are guaranteed to change but the topic categories should be the ones that you focus on as a business to ensure that your maximizing the investment that you make in Microsoft Dynamics CRM.
If you are evaluating these choices for Dynamics CRM, RSM can help you assess what is best for your organization today and into the future. Contact our professionals at firstname.lastname@example.org or by phone at 855.437.7202. We have resources throughout the United States with a broad range of CRM experience. We assemble teams based on your industry, business requirements and technical needs.
By: Phil Haase – Great Lakes Microsoft Dynamics CRM partner