Onboarding Enterprise Applications Into The Cloud: A PM's Guide

Enterprise IT leaders are migrating existing software applications to the cloud. There are benefits to moving to the cloud, but many risks in getting it done right, in a way that doesn't interrupt business operations or introduce regression in functionality. 

Below is a guide for projects managers and product owners for structuring cloud onboarding projects. 

WHY MIGRATE AN ENTERPRISE APPLICATION TO THE CLOUD?

There are many reasons. For example: 

• Better digital customer experience - apps in the cloud can be deployed closer geographically to each user group you serve, ensuring lower latency and reliable connectivity. 
• More agile delivery of IT services -  the cloud lets you spin up computing resources and services quickly, allowing developer groups to experiment easily, create new products faster, and respond more quickly to customer demands.
• Scale resources to meet temporary surges in demand. If customer usage spikes, the cloud allows an enterprise to scale resources locally much more easily than an on-prem deployment. When you unveil a major new application where you anticipate massive scale on day 1, you can be prepared to scale for massive demand if needed (think: when President Obama asked every Amercian to sign up for health insurance on the same day at Healthcare.gov)  
• Reduce costs and have more cost certainty by right-sizing workload. By getting off legacy infrastructure, you can potentially reduce costs. Moreover, the elasticity of cloud resources means that you can spin up just the right amount of computing, memory and other resources at just the right time, rather than working with fixed investments in local servers.
• Move from upfront capital expense (capex) to variable operational expense (opex), per the point above.
• More reliable - because of the potential for scaling and elasticity across geographically dispersed locations in the cloud, there is the potential to have stronger redundancy and disaster recovery, especially important for mission-critical applications with a need for high availability.
• Reduce in-house IT management - depending on the way you deploy to the cloud, you can reduce in-house costs for things like asset management, DB maintenance, etc. which can be taken on by the cloud vendor. ​

THE 3 PHASES OF CLOUD ONBOARDING

There are 3 major phases of onboarding any application workload to the cloud:

1. Analysis: what is the business case for moving to the cloud? Is it technically feasible, and if so what are the requirements, SLAs, risks and constraints? What cloud deployment approach should be taken? (IaaS, PaaS, SaaS, etc.)
2. Migration: plan and execute the actual migration of the application and its data in a secure manner. This is where the bulk of the work takes place, leading up to launch.
3. Operations: as soon as the application is launched, it needs to meet ongoing SLAs. It requires performance monitoring, cybersecurity monitoring and response, disaster recovery, and ongoing functional enhancement and defect resolution.

Of the 3 phases above, let's focus most on the analysis phase. A proper analysis is crucial for successful cloud onboarding. Any issues that you can detect and resolve upfront will pay dividends later.

NOTE: this article assumes that the enterprise owns of the code of the application that's being considered for the cloud. If the application is a 3rd party application, then needless to say you need to work with the vendor's team on the steps outlined below.
​
The Business Case
Any application could theoretically be moved to the cloud. The business stakeholders needs to establish a rigorous business case - what are the business outcomes expected as a result of the moving to the cloud? This can't just be a list of buzzwords like "scalability" and "reduced cost". A business case should include revenue projections, cost saving projections, customer experience metrics. 

The business case will need to be done in partnership with IT, who can help vet assumptions such as cost savings. For example, operating an application in the cloud has the potential for cost savings, but not always, or perhaps not without a significant upfront investment. 

Business Requirements and Operational SLAs
Along with the business case, business requirements and operational SLAs should be established. This may just be surfacing the existing requirements of the on-prem application, but it needs to be surfaced clearly so that IT can take into account during feasibility assessment.

Often a move to the cloud is not just a straight migration to the exact same requirements. The business expects to get certain advantages from the cloud. In this case, in addition to documenting the current state requirements, requirements for the cloud version of the application should be documented such as additional functionality expected, greater system availability, or faster recovery time. 

Consider the current state and (cloud) future state (cloud) requirements 

• sensitivity of the business data
• service levels
• transaction rates
• response times
• number of simultaneous users to be supported
• availability requirements
• performance requirements
• backup requirements
• disaster recovery requirements
• monitoring requirements
• security requirements 
• compliance requirements (e.g. isolation, data sovereignty) 

Technical Feasibility
Once a draft of the business case is established and requirements are written down, the IT team can proceed on technical feasibility. There are many areas to examine:

Does the Application Have a Cloud-Friendly Architecture?

Can the application function even in the cloud, and if so, how will its performance be affected? There are a couple of basic architecture considerations:

• Can the application already have the ability to run in a virtual environment?  Compatibility usually isn't a big problem for newer applications such as web application built with a component-based architecture, or applications that are relatively 'standalone' in terms of level of interaction with other applications and services.
• Is the architecture made up of loosely coupled components that are horizontally scalable, or only vertically scalable as legacy enterprise applications tend to be? Legacy enterprise applications were designed to run on a single server, or on a cluster of front-end and application server nodes backed by a database. It's assumed that the app will be running on infrastructure designed for reliability, so hardware failure is taken to be an unlikely exception that requires special backup and disaster recovery procedures. This is quite different from a cloud environment that has built-in multi-site failover capabilities and is designed to 'expect' failure and respond to it by switching resources seamlessly.​

Dependencies 

We talk about onboarding application workloads to the cloud rather than just 'applications'. This is meant to include the application and all of its dependencies such as OS, databases, application services, processing power, monitoring and management tools, security services, authentication services such as Active Directory, and other applications that it interacts with. 

For the application to function in the cloud, each component that it depends on needs to be identified. Each dependency:

• will need to be accessible by the application once it's in the cloud (e.g. in a "hybrid" cloud model), or
• will need to be migrated to the cloud as well, or
• will need to be replaced by an equivalent service that already exists in the cloud.

If a dependent component is missed in the upfront analysis, it can be costly to figure out how to deal with later once the cloud migration work has begun. In the worst case, a missed dependency that is uncovered later could even mean re-thinking the whole onboarding strategy. 

Cloud Migration Path - IaaS/PaaS/SaaS

Workload analysis can also be used to inform decisions about the most appropriate cloud migration path and the most appropriate cloud environment for applications (public, private, hybrid).

Migration paths run a gamut of options such as:

1. Re-host on IaaS. This is colloquially known as the lift-and-shift approach, moving an application that is largely cloud-ready to the cloud without modifying it. 
2. Re-factor for PaaS. Here, the application may be modified to operate natively with some of the cloud provider's services. Its dependent components may be replaced with by cloud native services. 
3. Replace with SaaS. Depending on the business needs, it may be easiest to replace an on-prem application with a new SaaS application that runs natively on the cloud and provides equivalent functionality. For example, replacing a home-grown CRM with an industry-standard cloud CRM such as Microsoft Dynamics365 or Salesforce. However, SaaS applications pose their own challenges, such as integration with an organization's single sign-on or identity access management service, as well as new billing models.

Cloud Migration Path - Public/Private/Hybrid

In addition to the choice of IaaS, PaaS or SaaS, the sensitivity of the application and the data it works with, its performance requirements, as well as the application's dependencies and how they will best be accessed, will dictate whether it should live in a public, private or hybrid cloud:

• General applications such as e-mail and collaboration are not high performance may be good candidates for public cloud.
• At the other end of the spectrum are applications that are business-critical, highly sensitive and require high performance systems, such as an ERP. These may be best run on dedicated systems where IT can provide security and risk analysis.
• Hybrid clouds extend an organization's on-prem network to the cloud, and can be a good fit for an application with dependencies that will remain on-prem, such as an on-prem Active Directory. However, the latency introduced by pushing an application to operate across the on-prem and cloud network may not be acceptable for certain applications.

Most enterprise IT groups have policies established for migration paths of different applications to different cloud deployment options. 

Update the Business Case with IT Costs

Once the technical analysis is done, if cloud onboarding is feasible, the IT team may have a cloud onboarding recommendation or a set of possible options to discuss with the business. Each option requires a cost estimate so that it can be incorporated into the business case and confirm that the business case is still valid.

IT costs are calculated based on various facts:

• What are the CPU, memory, network, storage, available and performance requirements and what will it cost to provide these in a cloud environment? Public cloud providers, such as Microsoft and AWS, generally charge fees based on resource consumption. As such, a cloud-based, high-performance computing environment can become cost-prohibitive. For example, it can cost thousands of dollars per month to operate a single high-performance application in the cloud, mostly due to CPU and disk I/O consumption.
• What refactoring is required of the application and its dependent components? For example, if a legacy application needs to be broken down into a componentized architecture based on microservices, this can be a lengthy process. 
• How many IT team hours/people are required to support the workload and what do they cost?
• What are the costs of licensing?

Of course, onboarding to the cloud can also mean IT savings that should be factored into the calculation, such as the savings the enterprise may incur if the application's legacy infrastructure can be decommissioned.  

Each of the major public cloud providers has a total cost of ownership calculator, such as Amazon Pricing Calculator. While a calculator is not a substitute for doing your own analysis, it can be helpful to make sure you've thought of all the different factors affecting cost. 

Prioritization
Only by establishing a business case - with well-defined cost projections, business requirements and IT requirements - can requests for onboarding then be correctly prioritized, relative to one another, in an overall portfolio roadmap.

PROJECT PLANNING: THE MAIN PHASES OF CLOUD ONBOARDING

The business case is approved, the priority is set, now it's time to plan the execution of cloud migration. The main phases of any cloud migration are as follows:

1. Detailed IT requirements - the team already came up with a list of requirements in the analysis phase, to support the development of a business case and estimate costs. The requirements will need to be documented in further detail. 
2. Detailed target architecture - similarly, the target architecture was probably sketched out during the analysis phase, but needs to be solidified now for delivery of the project. Dependent components like databases may need to be rationalized to work within, or with, the cloud environment. Some dependencies may be replaced altogether by cloud native services.
3. Refactor the application, if needed.  If it was determined that the application needs to be refactored to work within the cloud this is an early pre-requisite before migration can really begin. Refactoring can take several common paths such as:
   • Break down the application into scalable components: how effectively you can turn cloud resources off will depend on how easily you can isolate different application functions. To maximise the cost savings, you can make through downward scalability, break your workload into as many independently scalable components as possible (microservices)
   • Identify and fix performance inefficiencies, for example by rooting out memory leaks or inefficient DB queries. Where possible, isolate compute-intensive components in such a way that they can be scaled independently. If an application is performing inefficiently in any way, it will use more resources than it should; and this can be costly in an environment where it's easy to provision more resources. Identify and fix performance inefficiencies,
   • Enable Resilience and Self-Healing: you want workload components to be loosely coupled so that if one component fails, the others can continue to function. Depending on the criticality of your application, you may also need to ensure a greater degree of self-healing capability to ensure recovery from different types of failure at different levels: hardware, network and application. Safeguards could include process threads that resume on reboot, message queues that can reload the state of the system, and the use of a database rather than memory to write data to. Testing, both before and at the end of the onboarding process, should include different types of failure scenarios to ensure appropriate resilience. 
   • Add security: for example, add encryption where you haven't before, and replace traditional perimeter-based security controls with security built into the application. 
4. Establish a plan for each dependent component - For the PM, this is the critical piece. This can mean negotiating with other teams in the organization who may have other priorities than supporting your particular project, as well as third parties like vendors and partners. It also means validating the target architecture with each dependent group.
5. Detailed IT operations plan - establish the SLAs and determine how each operating team (service desk, ITSM, development support, cloud monitoring, cyber monitoring and response) will support the application day-to-day. What does it mean compared to the status quo?
6. Provision cloud resources - whatever VMs, CPU, storage and supporting services required should be provisioned in the cloud (often simply using the self-service tool of the cloud provider)
7. Establish a secure, bi-directional connectivity bridge -  between the on-prem data center and the cloud (usually through an internet VPN) both for the migration itself and for cross-platform application interactions after migration. 
8. Deploy the application workload. With connectivity in place, VMs can be configured and connected to dependent components that are left on-prem (such as Active Directory), followed by the transfer of the application and any associated databases, software and services being migrated.
9. Ensure two-way integration between the cloud workload and components not migrated
10. Configure monitoring and management tools - for the application as well as the cloud infrastructure itself.
11. Test and validate - Testing is the only way to know how an application will behave in a cloud environment. Has everything been transferred correctly? Are configurations correct? Can you see and manage the cloud environment properly? Does your cloud backup process work? Are performance and resilience inline with requirements?  Establish baselines for comparison.  
12. Security assurance - depending on the criticality of the application, this could involve threat modelling, security use case design and testing, vulnerability assessment, etc. 
13. Pilot and launch - again depending on the criticality, running a pilot or "soft launch" with some real-world users, partners and the operations team can be the last check on any last minute surprises. IT operations launches based on the plan and governance established earlier. 
14. Discontinue the old service. When you're certain that everything is working well, you can give access to users and decommission the old application.