An ISV with a conventional on-premises application has a tricky transition to make, involving both business and technical issues.



Many such ISV's will migrate an existing application to the SaaS model, leading to a situation where the application can be offered as both an on-premises application and as a SaaS application.

Other ISV's, especially those with a relatively old application, will decide to ?end-of-life? the application and develop a new generation of application built, from the ground up as a SaaS application.

Whatever migration route is chosen, in addition to developing the SaaS application, the ISV embracing the SaaS model also has to provide a wider SaaS Ecosystem, including Subscriber Management, Provisioning (System and Module levels), Pricing Engine, Billing Engine, Payment Processing, Application Management etc.   Providing such Ecosystem facilities can easily account for 20% + of the overall development effort.

In addition to the monetization and application management ecosystem surrounding the application, the ISV embracing the SaaS model also takes responsibility (directly or indirectly) for infrastructure and operations management.  A few ISV's will build their own infrastructure on which to run the application, but most will outsource operations to a suitable hosting company.  This marks a radical shift for most ISV's who have been accustomed to their customers providing the infrastructure and operating the systems themselves.

The ISV therefore needs to take a view of the infrastructure and may view that infrastructure in layers, as follows:

 

1.    Infrastructure as a Service (IaaS) ? Bare Metal

2.    Platform as a Service (PaaS) ? Bare Metal + Fabric

3.    Software as a Service (SaaS) ? Bare Metal + Fabric + Application/Framework

All in all, an ISV who becomes a SaaS Vendor has to take on far more work and responsibility, with the possible exception of having less software support work to do.  This overall increase in responsibility has implications for both the technical community and the commercial community within the ISV.  In particular, it is important that the migration plan be fully funded and resourced, which means that the ISV must consider its business plan very carefully.  Not least, because, whilst the migration to SaaS incurs cost, the associated subscription model tends to delay the ?break-even? point.  This causes a ?funding chasm? which has, traditionally, been associated with SaaS applications.

Given the inherent nature of the SaaS model's cash-flow, it is important for the ISV to make the effort worthwhile.  This means that the ISV must be sure that it can drive profit from a more efficient means of operating a software business and must take the opportunities that exist to reach out to new markets, either in different tiers of the market or in other countries/geographic regions.

The ISV must carefully consider the ROI of the investment opportunity and ensure that there is plenty of up-side to justify embracing the SaaS model. The ISV has also to consider the rate at which customers are adopting SaaS, together with SaaS migration timescales and likely competitive moves in order to establish the correct timing.

In view of the complexity and importance of the SaaS migration decision, ISV's could be well advised to seek help in order to gain the benefit of an independent view and to obtain best practice information in order to speed ?time-to-cloud? and minimize risk.