What it means to migrate your existing application business
A look below the tip of the iceberg.
Software as a Service (SaaS) has taken the software world by storm in recent years. One of the main reasons for this is that the hosted subscription-based software delivery model is much more beneficial for buying organisations. Consequently, some software vendors may offer subscription pricing for their existing solution and add hosting services for customers. While this may help to convince new cloud-minded clients, the long-term financial success could be better. Subscription pricing covering the actual hosting costs and ongoing maintenance may eventually push these vendors out of the competitive game with native SaaS vendors, especially with a high volume of customers running on individual hosted environments, where each upgrade needs to consider customer-specific technical and functional aspects.
Customers running on-premise or hosted environments usually preserve a mindset of individuality. In contrast, SaaS customers naturally have bought into the concept of shared code and environments with ongoing innovation and encapsulated data privacy.
Positioning a hosted on-premise application as Software as a Service to SaaS-minded organisations will lead to unhappier customers over time at a high cost for the provider.
The truth is that converting an on-premise solution to Software as a Service requires rewriting the application.
SaaS transformation challenges beyond Coding
Running a sustainable SaaS business requires a service-oriented organisation – different from an on-premise software company.
Apart from retraining sales reps, the following business functions experience significant changes when moving to a Saas business model.
Software Engineering
Operating a SaaS business model creates challenges for engineering beyond redeploying the application on a shared platform for customers. The most critical aspect is the change in release cycles. While an on-premise application deploys new releases every 2 to 5 years, the SaaS market expectation is ongoing new features and updates every 3-6 months. For the software engineering team, this implies ongoing, incremental approaches to release management. Rather than releasing significant packs of new features in one update over a prolonged period, SaaS functional enhancements are deployed in smaller packages but in shorter release cycles.
Processes for software testing, transfer of information for new releases, and enablement for partners and sales reps become ongoing efforts the software engineering organisation needs to handle.
Product Support
Within the established software support model for business applications, support engineers usually work with their customer’s IT counterparts, who reasonably understand the support process. In the case of SaaS, functional end users often directly raise tickets – ideally from within the application logic. This requires a simple support process and easy-to-understand language for non-IT folks, including rapid response time. The impact on a support organisation is significant because SaaS allows global usage.
Product support responsiveness directly impacts customer satisfaction and related potential SaaS renewals. At the same time, funding for support services becomes a challenge since a SaaS model has no direct support income stream.
SaaS Cloud Operations
Application hosting does not exist within a classical on-premise software company, and if so, it is an added value service charged separately to customers. In a SaaS model, Cloud Operations is at the heart of the delivery organisation, tightly linked with or even part of the engineering and support functions. For globally available SaaS solutions, data center locations become business critical due to data privacy and security regulations. Application service levels and uptime commitments can make or break deals with new customers, especially in industries like Financial Services or Manufacturing.
SaaS platforms like AWS, Azure, Google or Oracle OCI can provide the backbone as a purchased service. Still, the SaaS provider should follow overall service levels for the end user, including the behaviour of the actual application running on top of the third-party platform.
SaaS Customer Success
In the case of on-premise deployments, the software provider is paid the license fee before the customer can legally use the software. License usage rights are indefinite. If the end user stops using the software license, then there is no payback of the license fee.
SaaS, however, is a rental model where the end-user pays subscription fees periodically and obtains the right to stop the contract at the end of a term. Consequently, the SaaS provider has a vested interest that the software is utilised as much as possible, end users gain business value and happily renew the contract for the next term. Customer Success teams have evolved within the SaaS industry as a business-critical function for ongoing customer engagement and assurance for ongoing contract renewal.
Order Management, revenue recognition, and invoicing
On-premise license revenue can be recognised as revenue when the software product is shipped to the end customer. Order Management is straightforward, and only one invoice for the license needs to be sent at the point of purchase.
The Software as a Service model requires a more complex order management process. After a new contract is booked, the software needs to be provisioned in a data centre, and the customer’s application administrator is notified and given access. Provisioning of the application can be more or less complex depending on the services included in an order, e.g., several SaaS modules plus added storage or integration software services.
SaaS revenue recognition is an ongoing process triggered at the end of every contract period, typically monthly. Subscription invoices are released along the same flow. While this may not be a stark difference, growing volume can be challenging. At the same time, in a service business, each customer interaction contributes to customer satisfaction levels. Therefore, back-office interactions are increasingly relevant.
In summary - migrating proven software applications to a SaaS model requires cautious planning and consequent execution for the entire software business. Existing customers should be considered companions on this journey.
Comments