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:
THE 3 PHASES OF CLOUD ONBOARDING
There are 3 major phases of onboarding any application workload to the cloud:
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
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:
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:
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:
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:
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:
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.
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: