Session Abstract - Lessons learned from addressing the inevitable.

I was asked to submit a topic for a cloud-related conference, I'm thinking of "Lessons learned when moving enterprise software from a conventional deployment model to a cloud-based model." Obviously I'll need a snappier title like "What were we thinking?", "Please Lord make it stop." or maybe “Lessons learned from addressing the inevitable.”

Specifically the session will relate to companies selling enterprise software and are going to start offering their solutions in the cloud or service providers looking to sell 3^rd party enterprise applications in the cloud.

I’ve attended these “lessons learned” sessions in the past and prefer the ones that basically list all of the things that you need to watch out for with general lessons learned. In the world of enterprise software knowing the specifics of one company’s experiences is not always germane to other deployments. To that end I’m going to focus on the actual issues and some hints on how to avoid them. Here's my outline...I'm going to blog on each of these over time to help me to solidly my thoughts. I’ll add to this as I go.

Internal issues to address

I'm starting with “internal issues” because IMHO these are far more difficult to deal with than the technical ones.

• How will you compensate the field when you move to a SaaS model?
  • Any subscription-based pricing looks less attractive in the short-term to the people being paid on revenue.
• Re-educating the field on what a move to SaaS means.
  • Don’t underestimate the effort in undoing all of the “big sale” indoctrination that you’ve instilled in the team.
• Deciding which customers/use cases to go after first.
  • If you elect to go “cloud” not “managed service” then you are going to have to apply restrictions on how your customers use the systems. How will that change your GTM model?
• Deciding when/if you'll stop supporting new conventional deployments and existing conventional deployments.
  • Will you continue to sell a non-cloud version of your software? This is not a trivial question, the timing is especially important.

Technical issues to address

I'm intentionally not addressing HOW to get your non-multi-tenant solution into the cloud, that's the topic of many other sessions. I'm focusing on the other issues that you'll need to address after you've done it.

• Migration offering for existing customers.
  • Don’t just think about data, think about processes, policies, monitoring, integrations, etc.
• Convincing your customers that your offering is secure, performs well, will integrate into their existing systems, etc.
  • “Confidence”…your customers know how enterprise software deploys today. They may not like it but they understand it. You need to convince them that a move to “less hassle but less control” is going to be a benefit.
• Service levels
  • Customers will have preconceived ideas of what your service level objectives are. Up-time, high availability, data replication, location of primary and backup data centers, performance, etc. These cause work for legal, the deployment teams, the ops teams, pre-sales, etc.

Things you never thought of

• Contracts...you might have enterprise agreements for software and services today but I'll bet that they will not work for your cloud customers.
  • Don't underestimate this one; it is where all of the other issues come to the surface. Why? Because not someone needs to sign a piece of paper that says that what you are offering them will meet all of their needs…and that’s scary.
• Managing the transition from conventional to enterprise.
  • How are you going to manage the transition to a cloud service provider? Will you go "all in" and rebrand yourself as cloud supplier (alienating your current customers), be low key with your cloud offerings at first (letting your competition take the lead), will you start a new organization for the cloud solutions (creating internal strife and completion)?
• Delineation of responsibilities - who exactly is responsible for what?
  • You will have a contract to supply a service to your customers but there will always be a grey area. You will run the servers and they will consume the service. Easy, yes? But who will create users, who will do end-to-end performance optimization, who will monitor usage, etc.?
• Selling…internally.
  • There will be resistance to a move to the cloud and not just from the customer base and the field. You might get push back from engineering, senior management, internal operations, etc. You need to spend an equal amount of time getting buy-in internally as you do selling to your customer base – at first that is.

Objections that you need to be able to handle

• Security. This is the number one objection that you need to be able to answer. How can I be sure that my content is protected and will not be lost?
  • One specific question - who has access to the data and where will it physically reside? This might relate to compliance as some data needs specific levels of protection, (e.g. UK health data, German tax data.) but in many cases this is actually just “justifiable paranoia”.
• Latency. You are moving a service out of a customer’s data center and they’ll want to know how that will affect performance. In my experience it is actually often better – latency is a minor tax on performance in comparison to the gains in having a well-managed, optimized service running on a major piece of hardware.
• Enterprise connectivity. If the customer has systems inside their firewall that need to connect into your service – public, private or hybrid then they will need to know how that’s going to work…and how well.
• Customization support. If the customer has “special” needs that involve making a change to their base environment then how will you handle this, if you will even allow it.