If you have not come across the terms “cloud” or “cloud transformation” so far in your career, then you are in the wrong profession.

Every Tier 1 to Tier 3 companies around the world are organizing themselves to move to cloud over the next 18 months to 5 years.

Why? Because of below:

• you no longer need to have an on-premises data centre, instead you can have your applications in the cloud there by saving loads of money on real estate and storage
• instead of you managing your network and infrastructure, you get the same service from a vendor who lives and breathes this work; you no longer have to recruit network and system administrator, rather the responsibility has been passed on to an external service provider
• your infrastructure is always up with a guaranteed 99.95% uptime; you no longer have to wake up in the middle of the night to restart your server; someone else is already doing that on your behalf
• if you are not using your infrastructure, you can shut them down and bring them up on demand; unlike on-premises infrastructure which is up 24×7, 365 days a year, here you can have cost savings by bringing down infrastructure that is not being used; so you end up paying for only the compute power you actually use
• you no longer have to worry about the infrastructure and can focus your time and effort into building cutting edge applications

These are just some of the benefits for migrating your applications to cloud.

So what is hybrid cloud then? It is a mixture of private and public cloud infrastructure. Hybrid cloud transformation therefore means transforming applications and migrating them from on-premises to hybrid cloud infrastructure. If you follow R-lane methodology, then transformation could mean re-host, re-platform, re-factor, re-architecture etc.

So let’s take a look at the Do’s and Don’ts you need to follow if you want to successfully transform your applications to cloud.

Do’s: The pragmatic approach for hybrid cloud transformation, in my opinion, can be summarized as below:

• Before you bring an external vendor to kick off the transformation or you want to do it in-house, please plan; there is no substitute to planning; as soon as a vendor is onboarded, they need to meet the contractual milestones; unless the customer (that is you or your company) provides them clear guidelines, the vendor will not be able to deliver on time and under budget
• Define all internal and external processes that shows the RACI and roles & responsibilities of the customer and the vendor as they work together as strategic partners; this includes process documents, swimlane diagrams etc.
• Categorize all your applications into technology stack such as Microsoft (.NET, MS Access, VB), Java, COTS, SAP, Integration, Bespoke etc. Then pick one application from each stack based on orthogonal complexity. For example, pick a .NET application with simple complexity, pick a COTS application with medium complexity, pick a Java application with extreme complexity and run a POC (Proof of Concept) to transform them to cloud. Why? Say you have multiple .NET applications/products that your company supports. Due to various reasons, you may not be able to transform and migrate all applications on the same night, cutting over at the same time. You may be faced with a situation where one .NET application can be migrated with the rest of the .NET applications remain on-premises. But all .NET applications happen to share a common database. So you need to prove that your applications can work across cloud and on-premises setup. Unless you are confident that the technology stack has the capability to be transformed to hybrid cloud, you will be totally at the expense of the vendor recommendation and that is a recipe for disaster.
• Ensure that you have a clear idea about what your infrastructure is going to be including security, data integrity, service SLA etc.; I am assuming that the infrastructure design has been reviewed and approved by all technical stakeholders
• involve your operational team early in the engagement; get them to review the RFP (Request for Proposal) responses and provide feedback; get them to review all design document as well as all process definition documents; they are the ones that have been managing these applications over the years and they will know if the new architecture in cloud will work or not; Do NOT ignore them and their feedback
• Empower operational team to speak up and provide feedback, without fear and retribution
• Most importantly, build an atmosphere where the external vendor is an extension of your operation team; at times that could mean putting the vendor under the operational team’s remit

Don’ts:

• Don’t ignore feedback from the operational team such as Development, QC, Production Support, Infrastructure Support etc.
• Don’t pit external vendor against operational team; don’t make it appear as if us versus them culture
• Don’t put people in charge of the transformation projects who will only toe the company line
• Don’t make unrealistic targets and schedule; that will only puts the project in jeopardy as well as creates an environment for failure
• Don’t hide project shortcomings; be transparent with budget and effort; don’t hesitate to admit flaws with plan and execution
• Don’t convey inaccurate and misleading message to stakeholders
• But most importantly, don’t appear weak in front of the vendor in terms of capability and approach

In a lot of companies (private and public), the don’ts sometimes outnumber the do’s. However good companies that listen to the feedback from internal teams are able to resolve some of the don’ts.

I do acknowledge that sometimes internal teams are not willing to accommodate new ideas and tools. This is because no one likes change. However change is at the core of hybrid cloud transformation. And that is why we need good leaders to inspire us and lead us through the transformation journey.