From licence sales to digital platform businesses
The cloud is more and more becoming the no. 1 option in terms of standard software. Custom software and operating IaaS & PaaS are also becoming more popular by the day. While just a few years ago, companies were still running their traditionally purchased licence software independently “on premises”, in their own data centres, or in a co-location, today they are increasingly making use of cloud applications. To ensure that providers and independent software vendors (ISVs) can also support a single stack and offer the right delivery method to meet their customers’ new requirements, there is growing pressure on them to increasingly deliver SaaS solutions instead of traditional on-premises software.
For traditional ISVs, which have so far operated independently of software vendors, transitioning to a Cloud and SaaS model is both a great opportunity and risk in equal measure. Cloud transformation clearly offers access to new markets, potentially high growth, and the chance of establishing new business models using SaaS. Increased demand from businesses is also making cloud computing the strategic paradigm for ISVs and providers of software and digital services. Nevertheless, the changes in development standards, new skills, and processes for teams, and 24/7 operation with a different billing and procurement model for customers can, in extreme cases, go wrong. 
7 Mistakes to be avoided
To avoid such a failure, the following points should become part of the avoidance strategy for every ISV:
- Losing sight of the why
Companies that purchase SaaS solutions enjoy a host of benefits – simple implementation, a pay-as-you-use billing model, flexible storage, and much more – things that are making the demand for cloud applications skyrocket. That said, an ISV’s entry into the cloud and platform business should be based not so much on demand or new markets, but rather on the technological opportunities that this presents for a SaaS provider. Scalable and elastic applications are the magic words, and they should be the centre of attention. For this scalability, container technologies such as Kubernetes, Docker, etc., which ensure portability of applications for the various infrastructures, are the right way to move away from monolithic architectures and should be the driver towards using the cloud. - Ad hoc decisions
In order to offer their customers SaaS solutions, ISVs not only have to change their testing, development, and IT operating processes, but also adapt their entire business model. With cloud migration, the focus should not solely be on achieving quick wins or on keeping costs and time to a minimum. Rather, they should be anchored in the IT strategy, and the necessary organisational measures to make it happen should be taken. If the company’s goals are not clearly defined or if the IT strategy does not specify the company’s intended cloud orientation for the next few years and what roadmap is to be pursued, SaaS stand-alone solutions can emerge, which can often create a great deal of work at the interfaces to other systems or in the interaction with staff. - Consistent cloud migration strategy
When determining the appropriate migration strategy, information on load behaviour, APIs and interfaces, release cycles, downtimes, management tools, etc. is crucial and makes it clear that not every application can be migrated in the same way. The complexity of migrating existing applications depends on the architecture and existing licence agreements and affects both cost and time required. It is therefore wrong to expect a one-size-fits-all approach as part of a uniform cloud migration strategy for all applications.
- Going it alone when going cloud-based
24/7, microservices, shared responsibility, etc. – the new cloud tasks are not to be underestimated. Even for experienced software developers, making the transition from a private environment to the public cloud can be a difficult one. Storage management, user management, or databases are just some of the things that work differently in the cloud, but should still be used efficiently. ISVs should therefore get a service provider on board who can provide optimal support to meet their needs – starting with skill building, through migration, to operation. - Not upgrading mindsets
Delivering cloud applications requires experience and new ways of thinking to keep things running smoothly. While companies previously had full control and the ability to upgrade on demand, ISVs now have to keep SaaS solutions up-to-date and remember to keep disruption to a minimum. Ideally, a new version can replace the old one without downtime. But reverting to monolithic thinking does not make it easy. It is important for an ISV to build or purchase the appropriate team skills as well as cloud native and container expertise. For ISVs, this means development teams need to build dedicated skills for operation and that they need to focus even more strongly on the operation of the solution, or that they will have to work with a service provider with DevOps experience. Traditionally, many ISVs are strongly characterised by development competence. To be equally successful and state-of-the-art on the operational side, there is no avoiding questioning their workflows and organisation for an ISV, but this can pay off in terms of time-to-market and software performance. - Neglecting security
Although cloud platforms such as those provided by AWS, Microsoft, Google, etc. offer very good security, they do not protect against issues with their own application. While previous solutions only raised security concerns where local use took place, cloud applications have to undergo rigorous security testing before their release. In a cloud-based world, new features are constantly being developed and the performance of applications also has to constantly be improved and adapted to new security standards. This requires ISVs to rethink. It becomes necessary to create appropriate organisational models and team structures, and to establish a culture of innovation that implements concepts such as DevSecOps. The DevSecOps approach requires the integration of security into the entire development lifecycle and can, for example, identify problems and sources of error at an early stage by scanning and monitoring. - Thinking in black and white
There is a great risk of ISVs thinking in “black and white” when it comes to the cloud or on-premises solutions. On the one hand, the existing customer base requires time to transition into using the cloud. On the other hand, some applications are difficult to port. This is especially true for applications with high data volumes and real time processing. Legacy applications that are already difficult to maintain may require a build-new approach and thus a longer-term project. Here, the recommendation is to first expand the repertoire with cloud services, before switching entirely to the cloud. It is also worth assessing whether a hybrid approach makes sense, for example, to move only those parts of the application to the cloud that are important for storage and analytics processes, while security-critical or data requiring protection, for example, remain on premises.
Moving an ISV to the cloud is certainly not a walk in the park. It takes time to deal with new technologies and build new skills. Cloudflight’s experts will help you find the right way to transform to an agile cloud and IT operations model. Get in touch.
Please also refer to the free white paper “From Software Vendor to Digital Platform Business” for further information on the topic. This paper was developed by Cloudflight and Claranet and it provides information on the opportunities, obligations, and work areas associated with moving to the cloud. In addition, an ISV Cloud Transformation Checklist illustrates the most important fields of action for ISVs.