Migrating your application to the cloud

Here’s a sobering story…

Looking at the resignation letter on my desk, I don’t understand how we got it so wrong. He was our top salesman and was the most vocal about offering a cloud solution as an option alongside our existing product. And now he’s joining our biggest competitor, who hasn’t even considered the cloud. Why?

Execution was clearly the issue. The strategy was correct but our implementation was a disaster as new issues kept surprising us. We underestimated how this new offering would confuse customers. We thought they understood cloud computing. But it simply stalled sales. They assumed they needed less consulting support and projects started to fail.  The help desk was swamped and customer satisfaction scores went through the floor.

But the worst was the sales cannibalization and changing salesmen’s compensation to be tied into our annuity model. And that, it seems, was the last straw for our salespeople. If they can’t make money, they will go somewhere where they can.

12 months ago, before we launched our Cloud Computing strategy we were on the top of our game. Now we are fighting for survival.

There are so many questions, with hindsight, we wish we’d asked.

In the beginning

Over 10 years ago Salesforce.com was breaking new ground by offering a cloud-only CRM product.  It wasn’t even called cloud back then. It was SaaS or ASP. It sounded techy and complicated. And the confused mind says “No”.

CIOs were wary, scared and hesitant. But business users saw the benefits and were unfazed or probably oblivious to the risks. And whilst Salesforce weren’t the only company offering a cloud solution, there were by far the most vocal and visible. Their guerrilla marketing stunts and showman CEO, Marc Benioff, were not afraid to take on the status quo and that definitely accelerated cloud acceptance across the board.

And the rest, as they say, is history.

Now every startup, by default, offers its solution in the cloud. The benefits “appear” to be obvious with a win-win for both vendor and customer. But, the business case for the customer is not always as clear and obvious as cloud vendors would like to have them believe. There are certainly trade-offs that need to be considered, which were discussed in my recent article The cloud vs on-premises software: What you need to consider for your business.

Born in the cloud

There are also decisions to be made for the vendor before giving a customer the option of a cloud solution. If you are a startup launching today, so-called “born in the cloud”, then it seems obvious and the most compelling reasons are:

• Rapid sales cycle: With no cost or time to get clients started, and the ability to provide a ‘try and buy’ approach, it is quick and easy to sign up business users. This is often below the IT Department’s radar, something I have called ‘Stealth Cloud’, circumventing complex and time-consuming procurement.
• Cost of delivery: A self-service, multi-tenant, cloud solution means vendors can offer their solution equally to major corporations and to the “long tail” of SME customers just as cost effectively. No longer do vendors have to focus on the high margin multi-nationals, with their associated high cost of sales.
• Ease of updates: Unlike on-premise solution, the vendor can quickly apply bug fixes or new features that are automatically applied to every client. This should reduce support calls and ensure an innovation lead over competitors.
• Customer Success and benchmarking: With the usage patterns of every customer visible to the vendor, the vendor can make suggestions to drive up the benefits the customers are getting which will lead to further sales. But the vendor can also benchmark across customers to help laggards catch up and this can be another valuable revenue stream.

Annuity revenue model: The monthly revenue recognition can be painful to start with when cash is king and there is a risk that customers will churn. But in the long term, the annuity revenue stream gives a great deal of long term business confidence.

Migrating an existing business

However if you are a vendor with an existing on-premises offering then the decisions are not so straightforward. Naturally people start to think of the technical issues of re-architecting the application to run as a true multi-tenant application, but these are the easiest issues to resolve.

The bigger the company, the more difficult the migration is. Which would seem strange. But just look at the struggle that Microsoft is having in the office productivity and email space, with all its resources and the huge incentive to move with the pressure from Google.

So why so hard?  Let’s look at issues in order of difficulty (easiest first)

Which cloud architecture: While simple to answer, it has fundamental implications on the entire organization. There is more than one cloud. It could be infrastructure hosted by the vendor which gives great control, makes customers feel they are more secure, and potentially it can be cheaper; private cloud. This is especially true if you are having to ‘fudge’ your solution to make it look like a true cloud offering (single instance, multi-tenant).

Alternatively vendors can leverage the big PaaS player, but then they need to play by their rules and may make architectural decisions based on the PaaS charging approach or other quirks.  Vendors could even offer customers an on-premise implementation on their own private cloud, and take on some of the cloud attributes such as the annuity revenue model.

Architecting for performance: Everyone focuses on the hardware and application when they think of the cloud. But there is also the network, which is often the major factor in the performance of the service. Relying on the public internet may seem the easy and cheapest option, but could dramatically throttle growth and be a false economy.

We are already seeing PaaS providers such as Amazon (AWS) offering a dedicated network connection for clients who are demanding greater bandwidth, and more importantly, a more consistent network experience.

Technical architecture: You can fudge this by hosting the application and then providing a separate instance for every customer. This gives rapid sales cycle benefits of the cloud but none of the other cost of delivery savings. The real answer is to rebuild the application so it is multi-tenant and will scale correctly when deployed onto any cloud architecture. This of course may be a non-starter and a new build may be quicker, easier and take advantage of new technologies.

R&D and release management: Cloud clients have come to expect bugs to be fixed in days and new releases at least quarterly. This requires a far more agile development approach vs. the tradition waterfall development cycle with releases every 6 or 12 months. It will take time to train and redirect R&D teams and implement new release management processes.

Implementation: A common myth is that cloud apps are quick to implement. The installation time is down to virtually zero, but the changes to user processes and working patterns still needs to be done if the benefits of the new application are to be achieved. In fact implementation is even more important as it is the only thing preventing customers churning, as they are no longer locked in with multi-year license agreements.

Selling: It seems like selling cloud solutions is easy. It’s not. Getting a foot in the door and possibly getting a small trial is probably easier as you can bypass IT and procurement. But that larger roll-out requires a successful implementation and that is now in the hands of the support desk and implementation teams. And only when that happens does the salesman start to see any real commission. But even then it is accrued monthly – no big upfront sale and resulting commission which is what salesmen are used to, celebrate and are driven by.

A move to the cloud could be the fastest way to alienate and drive out your best salesmen to your competition who have not migrated to the cloud.

Consumption economics: There is no large upfront deal. The strategy probably needs to be “land and expand”. That means the continued usage and wider roll out of the software inside the customer is driven by customer support (often renamed Customer Success), implementation consultants and evangelists inside the client.  Each of these teams needs to be trained, aligned and incentivized.

Revenue recognition: For large quoted software vendors this is probably the largest issue. For every deal that changes from perpetual license to cloud there is an impact on cash flow and quarterly revenue. Sure, there is an increase in deferred revenue but that is not as visible to staff, investors and The Street. So, a huge success in selling the cloud solution can be perceived, when simply looking at the reported numbers, as a failure.

For smaller private vendors, the cash flow hit is the most painful. However, this can be mitigated somewhat by getting customers to commit and pay up front for annual contracts. Most large cloud vendors advertise their prices on a monthly basis but most heavily incentivize annual contracts.

These issues need to be balanced against the benefits, which I have listed earlier.

Migrate, stay or both?

So the questions are: Do you really want to migrate? Do you need to? Can you afford to? Can you afford not to? Will it cannibalize existing sales?

You could stay with your existing business as customers will be buying on-premise software for many years to come. However, there will come a time when you will be forced by customers or by upstart competitors to move.

I cannot tell you when that time will be, but I can say that at least three years before that time comes you need to have started your migration. Not helpful, I know. But it does mean that you need to start doing the planning for cloud right now.

Approach to migration

There are broadly four approaches that have been taken effectively by vendors, which is normally alongside their existing on-premise business:

Migrate existing applications: Rebuild or re-architect some or all of your applications, taking advantage of some of the virtualization technologies around to accelerate the work. But it will require your top engineers, pulling them off projects to develop new functionality. This can be achieved over the course of several releases with the timing determined by customer demand, as they will be able to inform you of the relative importance of cloud vs new functionality.

Cloud revenues will climb slowly, particularly as your sales guys will not want to sell cloud due to the revenue recognition and associated impact on their commissions. This is the approach taken by most existing software vendors and their success rate is very variable.

Start from scratch: Rather than cannibalize sales, confuse customers with choice, and tie up your engineers trying to rebuild your existing application, it may be easier to start again. Many of the R&D decisions will be different now and with some of the more sophisticated development environments you may be surprised how much can be achieved with a small focused team locked in a room with a crate of RedBull.

This will inevitable cause friction between the “dream team” building the new product and those left maintaining the legacy systems. It will also cause conflict with the sales team and the relative sales commissions of new and legacy applications need to be delicately balanced to ensure the right answer. Which leads to the next option.

Separate company: You may want to create a whole new company with separate brand, management, R&D and sales. The investment and IP may come from the existing company, but many of the conflicts disappear as you have effectively a new “born in the cloud” company.  The separate company may even be subsidiary of the existing company. What is important is that the new company can act, operate and behave like a cloud-based start-up.

Buy an existing cloud vendor: For a large established vendor, buying a cloud based competitor achieves two things. Firstly it removes a competitor and secondly enables the vendor to hit the ground running in the cloud space. The risk of course is that the innovation, drive and operational approach of the cloud based company is destroyed as it is merged into the larger acquirer. So therefore it is probably better to acquire the company, and then hold it at arms length rather than try and integrate it too tightly or quickly.

You needed to start 10 years ago

As I said earlier, I cannot tell you the perfect time to have a cloud based solution available in the market. Every country, market and industry is different.  Building or rebuilding software is expensive and risky. But planning is not.  Therefore starting to ask the important questions about migrating needed to start some time ago. And it starts with trying to identify the right questions to ask.

Fortunately, some of that thinking has already been done. A couple of years back I co-authored a book called Thinking of… Migrating to the Cloud? Ask the Smart Questions. It has many of the questions that you need to consider. But I warn you, it is not a fun read. But it is way better than having your business destroyed by an upstart cloud-based competitor because you hadn’t planned your response.

Disclosure: This article contains an affiliate link. While we only ever write about products we think deserve to be on the pages of our site, The Next Web may earn a small commission if you click through and buy the product in question.