If you are an ISV and are switching from a legacy application to a SaaS application, your organization will undergo a transformation on five levels – strategy, finance, organization, go to market, and technology. We will be examining each of these levels in more detail in this five-part series. As the levels overlap one another somewhat, or one has an impact on another, they cannot be viewed as five separate areas. Nevertheless, each poses its own questions and topics that need to be taken into consideration.
This article will look at the organizational changes and the decisions that an ISV needs to consider when switching from a legacy application to a SaaS application in the public cloud. I also recommend that you take a look at the ISV playbook from Microsoft. It addresses many of the transformation levels based on in-depth research, which can help you to arrive at the right decisions.
Organization
Now that we have looked at strategy and finance, let’s look in more detail at how you can prepare your organization for the switch to the public cloud. If you consider how, we used to install applications on a PC and then deliver them from a client server, a lot can change. End users are actually well acquainted with working with Software as a Service (SaaS) applications. Take e-mail for example, which since the outset has come to us via the web, although admittedly hosted from local data centers. Or ordering clothes – where once we picked up the phone and spoke to a voice-response system, we now use an app or browser. This means that at least the same is expected of your organization when you make the change. You must be present (technically and organizationally) at all times, there is less tolerance for errors and downtime, and end users expect constant new functionalities, speed, and top performance. This may sound arduous and intense, but it does offer enormous opportunity. Let’s look at things in more detail, one step at a time.
Always Available – Customer Service
The technology outlined below is already discussed in other articles, so here will we stick to the organizational side of “always available.” You choose a public cloud service that offers the right SLA with the right configuration, so you are as good as covered, technically. In addition, you also have your support department or customer service department – end users expect an instant response or the right advice on how to resolve their problems. This means that you need to have a solution for availability to your end users. During office hours, this is unlikely to be a problem, but if your SaaS solution is being used in different time zones, everything becomes more complex. At the moment, it’s relatively easy to implement chat functionalities, whether or not with integrated with AI, to communicate with your end users or point them toward the right information. Depending on the type of application that you have, one may be better than the other. In addition, you can also set up a 24/7 telephone service through a third party that is capable of answering the most common questions or of calling through a sequence of telephone numbers whenever problems arise.
The impact of unavailability is also many times greater. Where you used to have one client suffering problems, now, if you haven’t got your technical organization in order, all clients will go down at the same time. You need to ensure that your communication is well prepared. I’m sure that companies have gone under for less. So, from an organizational perspective, streamlining your communication in the event of downtime and other emergencies is crucial if you want to maintain a positive image in the eyes of the end user.
Less Tolerance for Errors vs Higher Expectations of New Functionalities
In the eyes of the end user, you can be replaced by another SaaS supplier relatively quickly, so remaining relevant is crucial to your survival. If top performance and 100% availability are already obvious givens, you can stand out by offering a fantastic user experience and by providing new functionalities at regular intervals. If you allow your users to influence the user experience, you can also work consistently on improvements from their point of view – and that will make you popular. One of the biggest advantages of working with the public cloud and DevOps, for example, is that you can push new updates constantly and can swap staging on the fly for production without end users ever noticing. We have clients who carry out updates anywhere from twice a year to five times a day. Consider the speed that this entails, the ease of rolling back is also much greater and the impact less. Quite simply, you are in a much better position to launch and test new functionalities quickly, and to roll them back if something is not quite right. This not only wins you kudos with your end users, but also means that you can stay one step ahead of your competitors. You can really turn end users’ higher expectations and lower tolerance to your advantage by launching new functionalities to the market much faster in controlled roll-outs.
Faster Time to Market
If you are able to roll out functionalities at a faster pace, you can also benefit from being able to connect more clients more quickly. Since you’re working in the public cloud, you don’t need to go after clients one by one but have one place where you can connect them all. Whether you choose to do this multi-tenant or not doesn't really matter. We have a client who, a few years ago, worked on implementing of one client at a time. Bear in mind that from an organizational perspective, you need to do this with every update. Now, a new client is registered in the CRM system, a webhook is initiated, and we can start automatic deployment in Azure. Time to market now? Ten minutes. Eighteen months ago, it would have been two weeks. As such, you can use automation and autodeploy to more quickly connect more clients in Azure, and you don’t need to increase your staffing numbers. All of this has a positive effect on your margin and turnover, which is indispensable considering the costs involved with changes to the license model – as we discussed in the article “Transformation Levels for ISVs – Financial”.
In Summary
The switch from an on-prem legacy application to the public cloud is an organizational challenge, but if you take the change slowly, it also offers opportunity to take better care of your end users. My advice? Automate, automate, automate, under-promise, and over-deliver.
Would you like to read more about transformation levels for ISVs?
This article is part of a series of articles on transformation levels in the switch to the cloud. If you would like to know more about what the transformation to the cloud involves on a go to market level, you can read more here.