Cloud is more secure than any on-premises systems. It is also less expensive because you do not necessarily have to procure additional devices to secure the information. Moreover, it is handled by certified technicians who do this day in and day out for a living. It is scalable and elastic and can handle most of the complex attacks such as distributed denial of service. The general perception though still is “I don’t want to store information in the cloud” The thought of having information not under a direct supervision or control is unnerving to some. Especially when security tools themselves are subject to an attack such as the SolarWinds attack, people are more sceptical of the cloud-based security measures.

In general, though, information at rest and in transit is encrypted. The logs are retained. The alerts are instantaneous and the means and methods of detecting events or threats are continuously evolving, hard for any enterprise to keep up with in on-premises systems. Also think about regulatory compliance when it comes to security. The cloud providers most frequently have continuous audits of SOC compliances, FISMA, DIACAP, FEDRAMP, PCI DSS, ISO and the list of certifications are endless. Security though is a shared responsibility. While till the layer to which you are paying the subscription, that is amply protected by the cloud provider, most often the application-level security is often the customer outlook.

For example, allowing customer roles to download PII data into their local devices and not having means to detect such events is a customer responsibility in most cloud models. And that is no different than what you would do in an on-premises application maintenance model. Governance of security, analysing risks and ensuring compliance is a continuous process. Every enterprise needs to have ample controls to ensure the information is protected. Laws such as GDPR in Europe and other places are fast emerging and making this need even more stringent. Business continuity mandates need for cybersecurity talent. The CISO – Chief information security officer is needed to be a part of every enterprise and must play a serious role in the organization.

Inventory all your systems and applications. The best option to load such inventory is either in an ITIL compliant CMDB and if that is not possible then at least in a spreadsheet accompanied with a flow diagram of how the systems interact with each other and their criticality to your enterprise. Once you have done the inventory, determine a roadmap and chart out a plan. While doing this, do consider the 6 R’s iteratively for each system/ application that is inventoried. Optimize your systems landscape where feasible. Homogenize or heterogenized your systems / applications landscape as part of your systems/ applications optimization process. Define latency and placement as you optimize your systems and applications landscape. Define tiers of the optimized landscape. Consider a proof-of-concept before you go wholeheartedly. Timing is critical. Determine crests and troughs in business activity, if necessary for different units, and then chart out the schematic of when what moves to the cloud and what remains on-premises. It is important to consider downtime and business continuity for each system/ application in close discussion with business teams. Critical considerations are recovery point objective and recovery time objective should something go wrong. Some systems must be cutover in a snap, while some can afford more leverage in downtime. Staff right – identify areas of gap, areas of expertise and draw a RACI map of who does what. Determine risks in the critical path(s). Ensure controls are established in a very regimented way and if necessary, security is re-imagined. Swim-lanes can be used to chart phases and streams of each move to give visibility to the parallel nature of the move and the intricacies of the dependencies. Finally size right and cost right. You do not have to oversize when you move to cloud. Remember elasticity is what you bought into to do the cloud.

Moving non-production or business continuity and disaster recovery systems into the cloud, has its own perks. Getting used to the operations in cloud, ensuring your optimization process is right sized and costed right. Some non-production systems need not be lights on all the time. Some can be brought up work hours. Storage for subsystems such as archival systems can be data tiered for storage so that data that has aged is in cold storage. Warm storage is used for the more frequently used data whereas hot storage is only used for current data. All these processes are significant when it can be tried in non-production systems. And again, these can be done as phase 1 of the plan or more of a permanent plan. And then, for some enterprise, this can serve as an alternative location for your non-crucial systems that you always wanted. It could be a parallel landscape for short-term requirements such as an important project that mandates requirement of a n+1 systems landscape and this serves as the most opportune time to keep n systems in-house and retire them after the project and have the n+1 become the new n after the project.

There are also times when you want to move DevOps to a containerized discipline, such as a Kubernetes or Docker and this may be the means to move those non-productive development and test environments encapsulated into the container design with embedded change management philosophy built in into the architecture for a shift from waterfall to agile. And then there are times where in proof-of-concepts are more comfortable for the sceptical to ensure confidence and this may be the right way to change the perspective. All-said there is no one right way to move the systems. Several ways work best for the organization, and one must prudently choose what works best for the organizational vision, mission, and culture.

The cost of damages due to system security breaches alone is projected to cross six trillion dollars by the end of 2021. Every 11 seconds, Ransomware is expected to attack a business. No doubt that traditional high availability and disaster tolerance must follow the measurements of RPO and RTO. In addition to these at the cost of lesser RPO/RTO, enterprises need to use cloud as a mechanism to air-gap and seal their environments the same way that tapes used to be shipped out in years gone by to offsite bunker locations.

Imagine the cloud to be that bunker location and there are several in the globe that you could choose from to have your critical systems omni-present. In defence networks, air-gapped networks ensure communication is physically isolated from internet networks. Airgap is cloud technologies can be done through non-permeable subnets, that are tightly pealed at the core of the onion and would have to pass through several layers to penetrate. Of course, it is not as fool proof as the non-internet connected mechanisms, but this is as good as it can get for enterprises that want to use this means for ensuring business continuity. The two primary functions served are ability to get business back up and running in event of an incident with minimal disruption and ensuring such system is as secure as possible to continue operations. Healthcare, Banking and Utilities companies are fast embracing this given the sensitive nature of the data they amass. This is true though of every enterprise and no reason why others should not also treat their data with the same level of heightened importance given the sensitivity of their data. DEVOPS environments can be replicated easily through a YAML file – predominantly used in most systems landscapes these days. Ensure white-labels are maintained through the layers of air-gapped systems to allow only one-direction permeability.

As you work through the 6 R’s, see what goes where. Determine if the set of system(s) are to be just IaaS – meaning you rent the virtualized hardware and perform a self-install on it. If the process determines that this is a Replace – then one of the options is to see if it is available as a SaaS offering and if those features are compatible with your business goals. If you require more than SaaS and require functionalities such as integrations and interfaces to hybrid applications, then evaluate if PaaS is an option. Serverless, Microservices and FaaS are also options and alternatives to SaaS/PaaS and can be evaluated when replacing existing systems/landscapes. The next aspect is where to place it. If compliance and dedicated hardware is a must then opt for Private Cloud. If options are not available in one cloud, then think multi-cloud. When thinking multi-cloud though remember there are charges for data egress and that is often overlooked. There are SaaS/PaaS solutions that include data ingress/ egress charges in their offerings and when evaluating, see if those options are available. This must be done for all systems and applications that you inventory, and careful thought needs to be given to each. Once the architecture is ready seek expert opinions and thoughts for optimizations. Run a few what-if scenarios and see what emerges as the optimized architecture. Ensure security and controls are in place when optimizing. Once you cross all the T’s and dot all the I’s you should be raring to go into the cloud provider options chosen for your enterprise. It is always best to do a proof-of-concept to ensure what you put on paper works. Test all ends of it and in fact, go a length further to automate the testing process, so if you do want to try multiple what-if scenarios the automated tests help accelerate the process.

Start with a data map. Draw the data flow. Determine what data is required in real-time. What data can go in batch. Colour code the data flow to indicate the data flow. Also, it may be important to display what is one-time vs periodic – for example currency definition is one-time, currency rates may be periodic. Now determine the toolsets and protocols that do the data transfer. Some toolsets allow for API calls. Albeit outdated, file and SOA transfers are still being widely used and may be used for some time in the future. REST calls are new and efficient techniques. Ensure data is encrypted at rest and transit. This technique eliminates any risk of data exposure. When doing batch transfers, data transmission can be reduced by doing delta transfers as opposed to full transfers. It is just necessary to rethink time efficiencies when doing data transfers. Finally comes the tools. Some cloud providers provide tools. Some applications provide tools. It all depends on the efficiency of the handshake. When transferring data from the same vendor it is better to use application-based tools from the same vendor. The tools provided by cloud vendors do compression in transit, which gains time efficiencies. Cloud-provider based tools also come in handy when doing multi-cloud transfers, the lesser the data, the lesser the cost. Then comes the network and protocol security. There may be firewall rules to be put in place. There may be proxies to be put in place. In all of these cases ensure redundancies for critical transfers, since these devices do fail, and you don’t want those failures at crucial business junctures. Last but not the least, trap exceptions and have human interventions to correct those exceptions when and as they happen to avoid business disruptions.

ROI simply put is percentage of net return on investment on cost of investment. Let us exemplify. Let us say, today you have 5 individual employees working full-time supporting your applications/systems. Total cost of ownership is around $200,000 per employee (all benefits and overheads included), which is a Million dollar outgoing every year. This does not include aspects such as net promoter score (how likely your customers will recommend you), customer satisfaction, cost per customer contact, customer lifetime value, retention rates (employee and customer), etc. Your employee productivity is at 60%, since they are spending time experimenting, researching and there is a cost associated with it. They are dedicated to your organization, but you are gaining only 60% of you spend.

While employee cost is imperative to you spend, systems are also equally important aspect of your costs. When sized correctly (on-premises the mantra is to oversize), the costs are low. Also think long-term contracts when instantiating critical systems. There is up to a 60% cost savings with long-term contracts (usually 3 years). Also think lights off time for non-critical (may be non-prod systems). Think going serverless, where possible. Architecting and redesigning your solutions landscape has cost savings within it.

Finally, think cost of security. Today more so than ever, it is a fact that systems on cloud are more secure than on-premises systems. The cost of security also should not be viewed as a transactional investment. It should be viewed as cost of no disruption to your core business. That is significantly indeterminate and not one that can be tangibly measured.