
Server Rack by Kusumsiri, on Flickr
So you have a successful SaaS business, and you come across that first customer who has a unique security need, demanding an “On Premise” version of your product. Before you start off that path, a few important things to consider:
You may say that today’s world is shifting towards SaaS, and you may point at SalesForce.com as the flag bearer, saying that if companies trust the cloud with sensitive data such as their leads, contracts and customer database, that On Premise is a thing of the past. Well, surprisingly, even the mighty SalesForce maintains an On Premise version (and they seem unhappy about the cost).
Having an On-Premise solution is much more than the sum of the parts: Sure, you can package the software today running in your datacenter, slap on an installer, and you are done. Or are you really?
A few of my past companies were “pure” On Premise companies, in the security area. I recall how the person in charge of hotfixes in Check Point is allowed to bring the entire R&D to a halt for when an urgent security-related patch for a release dated three years back is needed. In fact, every R&D plan included time allotted to developing cumulative hot fixes. The organization dedicated to packaging these (apart from the usual R&D) was sizable, and included dedicated QA.
Each instance of that On Premise package actually incurs debt. Debt in the form of customers expecting upgrades. Most SaaS companies update their software very frequently, but those updates are different from the world of On Premise customers. Consider cumulative patches, support for several past major releases, zero-downtime upgrades, monitoring and administration, training for support personnel – these imply a huge investment in creating operations and R&D organizations.
On thing that worked well for many companies is the appliance idea. Most software began as an installer package. Packaging in a big beige (or black) box actually works better, since you can control the entire configuration of the machine, including RAM/Disk/Motherboard and even the make of the network interfaces – avoiding driver hell. Nowadays, with the virtual appliance, there is no need to support a complex shipping operation.
So, what to do?
- Make sure that customers have an inventive to buy the SaaS package. Pricing is everything.
- Communicate the expected upgrade/patch cycle.
- Communicate the investment the customer must make in terms of manpower to support the shiny new server(s) in their data center. You can charge for “support services” but remember to require remote access.
- Work as hard as possible on a standard package, preferably an appliance. Having a standard solution means standardized upgrades, easier installations and less overhead.
- Remember the hidden costs, prepare for them and build the proper organizations to properly bear these costs.
Finally, continue investing in those features that allow customers to opt-in to SaaS. For example, hybrid solutions working partly in the cloud and on premise. Narrowing down on these, and eliminating customer resistance, will make sure the future remains, well, cloudy.