Prior to the early 2000s, most enterprises purchased software and applications that lived “on-premise” — meaning they were installed, stored and administered locally.
With its founding in 1999, however, Salesforce.com changed everything. One of the first to deliver enterprise applications via the Internet, it would launch an era of what has come to be called “cloud computing,” or software-as-a-service (SaaS).
SaaS is an on-demand delivery model that enables organizations to subscribe to the applications they need without hosting them in house. Unlike the traditional deployment model that requires users to purchase a specific license, cloud-based tools are purchased on a subscription basis and incur a monthly or annual fee.
Choosing one of these options, SaaS vs. on-premise apps, can have a considerable impact on time, resources and costs, so it’s a good bet that finance teams will be involved in discussing choices. So what are some of the major differences between these two approaches in how they help you accomplish your ultimate goals?
Costs
On-premise software solutions rely heavily on hardware and IT staff and skills to implement and administer. If you have to hire staff with the latest/”hottest” skills they likely come with a premium price. Or, to train current staff takes time and money. On-premise also requires the purchasing of servers, a place to house those servers, and myriad other support processes (more to come on that below). Moreover, as needs change, significant investments may need to be made in making custom changes to the platform.
SaaS, on the other hand, involves a known fee that usually bundles subscription and support costs together. You are simply purchasing a service for a set period of time. Details are known up front and in writing. Very little, if any, technical knowledge is needed. The SaaS host handles all the technical aspects, including updates to the infrastructure and the application. This often includes ongoing user and technical support. Contrast that to the skillsets of your in-house developers (if any).
Maintenance and Security
Control. Or, at least, the perception of it. It’s one of the biggest reasons that companies gravitate to an on-premise solution. In some instances, the company’s (or government entities) governance dictates it, thus making it the only choice. This sense of control, however, comes at a price. When you own the process, all the details fall back on your shoulders. Administering access, optimizing performance, application updates, data encryption, and backup/disaster recovery are all your responsibility.
While giving up perceived “control” as it relates to a truly customized solution, with SaaS you are essentially hiring a professional to manage and maintain the application for you. In addition to easy data accessibility when needed, cloud services perform routine automatic data backups as often as every 15 to 30 minutes. If updates to software are needed they are implemented, usually without users ever noticing. Can you honestly say your current processes are backed routinely, stored offsite, and rigorously tested?
Another key consideration is security. While you may have a clear understanding of how your on-premise technology protects your data, you need to do your homework if choosing a SaaS provider. They should be happy to explain their security certifications and protocols; if not, buyer beware!
SaaS providers have to undergo comprehensive annual audits to ensure data security and transmission. SOC 2 Type II certification also serves as a great indicator of how well a provider is prepared for regulatory compliance and able to maintain the highest standards of data security. Encryption in motion and at rest is best practice.
A Real World Example
My background, in large part, is accounting and finance support. As such I have been involved with quite a few on-premise financial software rollouts, some purchased and some built from scratch. Large scale rollouts usually meant I was given the role of being a “power functional user” and tasked with converting reports and testing. This meant weeks of identifying what to test, assembling sample data with known results, creating test scripts, and building a team to carry out the test. That also meant having to record errors, work with the tech team to find out what went wrong and correct it, and retest. This process took weeks and even after that time we often couldn’t find every issue.
When we did find an error that was bad code our vendor would typically provide a patch within 48 hours and we were back in business. But not always. In one instance, I pointed out to an ERP provider that their general ledger had issues handling recurring, intercompany journal entries. It took several days of phone calls before they admitted the issue even existed. When it was acknowledged, their response was: “You have to purchase a new version for that functionality to work.” Wasn’t much fun to have to explain that to the senior finance folks.
I share this because, by going with SaaS, you are purchasing software that has likely been vetted by thousands of users and if an issue is found by a user in one company the fix will be given to everyone, everywhere. You have the benefits of side-stepping the traditional costs, and headaches, that often come with ownership.
Scalability and Implementation
Yet another set of factors to consider is how well the solution you are vetting is able to grow (or contract) as your needs require, and what does the adoption curve look like in your organization as it relates to user utilization?
With on-premise make sure, for example, that you plan ahead for additional capacity as it is usually cheaper to buy/build ahead rather than piece together as you grow. This requires a lot of preplanning and possibly spending on capacity you may never use. With SaaS, you can adjust your subscription terms/seats as needed, either as you go or based on the terms of your contract.
Also consider what will be required to get as many of the essential users you’d like to be engaging the solution in question, and what it will take to get them to “comply.” How much configuration will, or will not, be required? Is it easy to access? How good is the support that you will receive? You’re making an investment in a software solution to overcome challenges, and create opportunities; if the application takes too long to make available, or hard to use, you’ll be faced with a case of diminishing returns.
Lastly, consider that a custom solution can be vulnerable to the loss of a single internal programmer or other individual responsible for designing, building or testing the application.
Connectivity and Mobility
Given recent events, it’s easy to see the need for remote access and delivery of applications. Working from home is now a necessity for many — and even before the pandemic the trend was increasing. According to a joint study by FlexJobs and Global Workplace Analytics, remote work grew 8% between 2016 and 2017, reaching 44% growth over five years.
While on-premise solutions often can be accessed remotely (with VPN, for example), administering and controlling that access can be complicated. That issue is non-existent with SaaS. Given the prevalence of internet access today, any concerns with cloud access are largely moot.
Verdict: SaaS vs. On-Premise Apps?
If you work with the government or simply cannot let go of your data, then on-premise is the option for you. If you’re a small business and serve as the CEO, CFO, and CIO then SaaS seems a natural fit. If neither situation describes you, then you have some thinking to do.
Compare providers and options for SaaS vs. on-premise apps. Ask yourself honest questions. What kind of growth do I really expect (people and data)? How important is anywhere/remote access? Do I really want to build my IT infrastructure or expand my existing network? How much customization do we really need? What are my integration requirements?
More often than not, the answer will be to go SaaS. It’s why, according to Gartner, it’s predicted to grow more than 10% in 2020, and represents the fastest growing major IT market.