Unclouding – Do you need a cloud exit strategy?

The CEO of a leading cloud provider was recently quoted as saying, that organisations not transforming their business to adopt the cloud were defying gravity and by not being “all-in”, toe-dippers were risking giving their competitors the edge.

The benefits of cloud computing for ERP are immense and well publicised. However I do feel as though, we have a limited counter balance to this view. This is largely fuelled by a growing impartiality between industry research and advisory groups, that are “supported” by cloud providers to push a cloud first agenda and leaving little room to consider the merits of other options.

Putting the cart before the horse

The most common error in technology enabled change is starting with the solution. Therefore, it’s not surprising that many cloud ERP implementations fail to deliver their intended benefits, whilst at the same time subjecting organisations to massive implementation and run costs.

Inevitably there is a growing trend towards cloud exit, or as I like to call it unclouding. It’s a real thing with big names like Dropbox who have reversed their approach.

The importance of an exit strategy

Companies running ERP today, fall into three categories when it comes to the cloud, all-in, partially in, or considering it. Whichever category you fall into and regardless of which stage you are at in your cloud lifecycle, it helps in understanding the reasons why organisations have, or are likely to uncloud. An exit could be both financially and politically costly therefore, developing and maintaining the right strategy is key for exit avoidance and/or readiness.

Why are organisations exiting the cloud?

The core reasons for “unclouding” are around security, regaining control and most commonly reducing cost – Yes! That wasn’t a typo – reducing cost!

One of the consistent messages coming out of the cloud sales push, is that you can’t run infrastructure as cheaply on-premise. But when you apply this to largely steady ERP workloads it might surprise you to hear that you can; of course, there are numerous variables in this statement. We constantly hear that cloud requires a different operating model to leverage cost savings and operational benefits, but again – is that not putting the cart before the horse?

A common example is where cloud providers, implementation partners and advisory groups are leveraging the flexibility of the cloud to architect “on-demand” solutions for ERP environments. This influences the business case to reduce operational costs, by shutting down test environments (when not in use) and scaling up/down your Production environment to meet demands. But there are some real issues with this approach:

1. If you power down systems, you still have to pay for storage costs
2. Database servers require pay-by-hour database licensing, but this is generally more expensive than purchasing perpetual licenses. License exchange discounts pitched in the sales cycle (moving from one database vendor to another) do not usually apply to the pay-by-hour model.
3. Most ERP businesses are global and sizing/costing peak demand is usually limited to month-end/year-end processing. This level of frequency is usually insufficient to leverage significant cost savings. True elasticity in your demand needs daily extremes, which are not always common in most ERP solutions.
4. System administrators are reluctant to shutdown test environments or scale up/down production, due to the disruption and associated risks. Automation tooling is still maturing and can be time consuming to implement and maintain.

Another cost factor that’s often built into a business case, is the reduction of your infrastructure operations teams, but in reality that team just changes shape.

I’m know I am only focusing on a few examples here and clearly business case modelling will continue to evolve. There are a multitude of reasons why cost comparison exercises between on-premise and cloud are likely to provide a distorted view of savings.

How do I develop an exit strategy?

An exit strategy is far wider than the mechanics of how you would perform the exit and where you are likely to land. We need to take a step back and identify the likely triggers (cost, performance, availability, security etc.), understand how we measure these and the levers to respond to them.

There is merit in devising an exit strategy whilst you develop your business case. The risks, impacts and assumptions that build a business case are key inputs into this strategy.

The key takeaways here are:

1. Identify your exit criteria and levers, but ensure your governance model continues to monitor and measure these. Invest in an innovation team as operations are always too busy keeping the lights on. Empower this team to drive benefit by executing and identify further levers, to keep that exit criteria in check.
2. Have a high level exit plan that covers what your landing options are likely to be, impact to the business, cost/risk of a migration etc. Also consider the impact of architectural limitations any future decisions will have on the exit strategy. Your exit criteria may identify certain apps and scenarios, even resulting in a hybrid cloud across multiple providers!
3. Do your homework and due diligence by investing time and sourcing the right skills to develop a robust business case. This is a moving target and is constantly evolving, but that’s technology in general.
4. Design to promote mobility – especially if you are greenfield. Try to avoid painting yourself into a corner with one cloud provider. Design your architecture to keep your options open and limit the impact of moving between providers/on-premise.

Benefits of an exit strategy?

Developing the exit strategy early not only provides that crucial “checks and balances” on the proposal, but once you are in a run state it provides a framework to govern and drive operational efficiencies. In the event of an unlikely exit (partial or full) you are somewhat prepared and also have some collateral to support contract renegotiations.

Don’t underestimate the cost and impact of an exit. Some organisations would have undergone costly transformation projects to move to the cloud and it is not uncommon for complex migrations to cost the equivalent of many years worth of cloud run costs.

If you have a made a solid commitment to your cloud journey and exit is politically damaging, there is still enormous value to your business in developing and maintaining an exit strategy.

Finally, lets not forget – without trying to contradict my opening sentiments in this post; we do have to applaud early adopters. It is those organisations that were brave enough to take the plunge, learn the hard lessons that have enabled the rest of the industry to benefit and develop more effective decision making.