Much has been written about the virtues of SaaS vis-a-vis on-premise traditional software in the last 4-5 years as SaaS made inroads into companies. My last post on SaaS Sales Strategy drew a lot of interest and also  brought queries from the sales community regarding how to contend with on-premise vs SaaS issue when trying to sell a SaaS solution from a cost-benefit point of view. So I thought it would be useful to do a follow-up post specifically to address that. Here goes

Large Upfront investment: The first and foremost benefit to a company is that it is hosted by the vendor (or a third party) and a company does not have put in place the IT infrastructure, team to host, manage the application. This frees up the large IT spend that now could be diverted to other projects that require it, now.  Remember the infrastructure includes application deployments for QA, Production, Pilots/Acceptance, Development and Fail-over besides production.  If you are global company then add to it the other needs around replication/WAN optimization to counter the latency issues. It is the Total Cost of Ownership (TCO) remember!. Then there is the Storage. With SaaS, your vendor will address all these needs for a fixed all-rolled-into-one subscription price. The beauty of the model is you can ramp up your costs commensurate with your consumption as opposed to making all the investment upfront often resulting in under utilizing the hardware/software.

Ongoing Costs: This is one of the most contentious one. Traditional vendors will have you believe that over time (5yrs and above) the infrastructure investment will have paid for itself. After that SaaS is going to cost you while an on-premise solution will have no incremental cost if you add more users. This is a bogus argument.  On the face of it, the subscription costs might look like a redundant cost after the “infrastructure pay-off period” but that is only one side of the story. Anyone who has managed IT for a while, will know, IT infrastructure is a living thing and needs constant care and feeding. Software updates, hardware additions, performance tuning, monitoring, backup and recovery. Then there is the burden of negotiating contracts with the hardware and software vendors. This on top managing the application and the upgrades will clearly be much more than the subscription costs. Each upgrade cost could come up to tens of thousands of dollars, if not more.

One thing which was until recent not a consideration was the power consumption and needs. With all the power glut, now energy needs are becoming the first or the second line item on every on-premise software consideration.

What else? Oh! yes. Did I mention that there is the small matter of manpower turnover that you will have to deal with when managing things on-premise?

On-demand Elasticity: SaaS affords you a quick on ramp with costs commensurate with the size of the team. Once you have conducted the smell test and decided to move further, SaaS also gives you the opportunity to scale up and/or scale down depending on your demands. Say your company makes an acquisition – you scale up your usage with just the subscription cost going up – easily quantifiable. Say 6 months later you rationalize the acquisition and decide to reduce a workforce reduction, you can now scale down the usage on the SaaS application. Contrast the same with a on-premise deployment. You buy it – you keep it. You will have to continue to pretend that those phantom users who were part of your organization during the post merger/acquisition integration are still part of the organization and keep on assuming those costs for the hardware procured, higher energy costs for that extravagant hardware footprint.

Anytime/Anywhere Access: Being in the cloud, your users will have access the SaaS applications just by using a browser and internet connection. Contrast that with a on-premise application that needs provisioning of access, you will need to go through a IT root-canal for arranging for VPN, access control etc.

Short-term ROI: Depending on the scope of implementation a SaaS application can quickly allow you to define target ROI and achieve it. Implementations are shorter in matter of weeks for a new implementation and maybe 2-3 months in cases where there is data migration, back-office integration. Contrast that with a long drawn out on-premise implementation. By the time the software is installed, pilots done, it will be a good 6-9 months if not more. ROI is elusive, if ever.

Risk Mitigation: In case of a traditional on-premise implementation, besides the large upfront investment for IT infrastructure, there is substantial investment to be done to get the project off the ground. This could include staffing a team and a prolonged project wrought with risks of project failures and cost overruns.  With SaaS, you could have a defined implementation schedule and near term ROI, which if not met, can allow you to terminate the project at the lowest cost.

Frequent Product Updates: One of the key benefits of SaaS is the product updates are frequent. This nimbleness of the vendor allows them to deliver incremental functionality faster than any IT organization can deliver to business. This represents a opportunity cost that a company will have to bear in a traditional software management model. Also given that the vendor is responsible for upgrades, relieves you of that cost burden as well.

Support Cost & Quality: With the vendor themselves providing the support (included in the subscription price), the buck stops with the vendor. You can define SLAs and measures to hold the vendor accountable. In a on-premise case, the IT organization is responsible for SLAs for a product that they would not be the ultimate experts in.

Get ready to be drilled

While we went into all the virtues of SaaS, there are some landmines that you should avoid as well.

Portability: SaaS has been perpetuating this principle that – “Customers can easily move to another vendor, if they did not like the service. So they have nothing to loose by signing up to a SaaS service”. This is b.s. of the first degree. This is much easier said than done. Never sell yourself into a deal where your bluff can be called. A smart buyer can push you to a corner with this and have it in the contract for you to provide data in a normalized form when/if they decide to move to another vendor. If you are tech savvy then you know what you are getting yourself into with that argument. Talk to your engineering team before you sign-up for this.

Integration: “We can integrate to everything/anything on earth through our APIs”. This is one area were every vendor exaggerates. Integration is not an off-the-shelf offering. Remember – Even a band-aid needs peeling, sizing cleaning the wound before you apply it to the wound. It is not magic. So take time to understand the need before you oversell your integration capabilities.

Disaster Recovery: While you are new SaaS company, it is unrealistic to assume that you will be able to afford Disaster Recovery implementation. While this is one of the gating issues – you would do well to highlight the Service Levels, Uptime statistics and if you do have a roadmap for DR share it. Remember you do not have the same excuse that a on-premise sales person has – it will be ready by the time you are live (read 18 months). On SaaS you are live tomorrow.

About Subraya Mallya

Subraya Mallya is a technology executive, entrepreneur involved in conceiving, building software businesses. In this blog, he focusses on business and technology strategies around Business Model, Product Development and Marketing. Connect with me on Twitter - @subrayamallya