Many enterprises and ISVs with on-premise applications have made the decision to migrate their offering to SaaS. They do the research and come up with a solid technical and business transition plan. They select the right hosting platform. They determine whether to spin instances up on virtual servers or recode as multi-tenant. They plan for a shift in business culture, etc. They avoid the common missteps and do everything right to get their software into the cloud, with one exception. They try to port all of the functionality and user experience of their on-premise application into the first version of their SaaS offering.
The bad news
Porting an existing on-premise software application to SaaS point-by-point is a recipe for failure. You will burn through a lot more money then what you really needed to spend. It will take a lot longer than was necessary to get to market. Most importantly, you will end up with software that is far too complex for a SaaS implementation and that customers simply will not use. That’s the bad news.
The good news
The good news is that in SaaS, users will accept and embrace applications that provide smaller areas of functionality as long as they work very well. On-demand customers have a different set of expectations in terms of the features and functionality than on-premise users. So a key part of the process in designing a SaaS solution is to engage with customers who are going to use the SaaS and evaluate what functionality is of most immediate value and what can be pushed off into future releases. Based on these user studies along with user-validated prototype testing, you come out with a release 1.0 that offers a limited set of high-value functionality that meets immediate user needs. This is delivered on time and on budget. Then every 90 to 120 days you add in additional functionality based on user feedback/monitoring or offer carefully designed upsell packages for specific business scenarios.
Designing your initial SaaS releases with targeted, but limited functionality rather than as a full port has another advantage. It avoids or delays revenue cannibalization of your existing on-premise product. The on-demand SaaS does not immediately serve as a replacement for your on-premise app. It addresses an ancillary market that may not need the full set of functionality in your on-premise version. Many organizations even start a separate business unit specifically to address this ancillary SaaS-targeted market.
Another key advantage of starting with a limited release focused on the highest value functionality is that you can add on additional services based on actual customer feature usage data and usage patterns. Unlike on-premise applications, which are generally black holes when it comes to information about customer behavior, with SaaS, the application can monitor almost everything the customer does. You can identify and correct drop out points, incrementally try features and explicitly test what functionality has the greatest customer value. So you design your SaaS based on empirical data rather than historical convention or marketing checklists.
At some point, you may end up having added in all of the functionality of your on-premise application. But from our experience with more than 60 SaaS engagements, this scenario is unlikely. Instead, user monitoring enables you to design a less complex base application, then develop and offer additional functionality bundled into different purchase scenarios for different customer groups.
Leave the past behind
SaaS offers a unique opportunity to reinvent your business. It is not just a technical product migration exercise. It is a way to use your domain expertise to design a new set of targeted solutions that will surprise and delight your customers (internal, B2B or B2C), as well as drive new revenue and productivity.
Paul Giurata is a managing partner and lead solution architect for Catalyst Resources. His work focuses on the design of software for mission-critical solutions in cloud computing, SaaS, financial services and mobile.