An Approach to Cloud Transformation and Cloud Migration
This article provides a methodology for cloud assessment, strategy, and migration including info on 7R methodology, assessment, and target cloud architecture.
Join the DZone community and get the full member experience.Join For Free
Businesses that have already embarked on their cloud journey have shown greater resiliency and responsiveness to this pandemic. In the near future, it's expected that cloud adoption will significantly increase across industries with a combination of different cloud service models (SaaS, PaaS, IaaS) along with hybrid and multi-cloud topologies. Cloud hosting will become a new essential IT service for businesses.
A well-defined approach for cloud transformation is expected to realize business goals, cost savings, and strategic benefits. This article will briefly outline the elements of a typical approach for application cloud migration, modernization, and transformation. The article combines portfolio rationalization methods that can identify potential savings by reducing spending on non-valuable portfolios, along with cloud migration methods to realize the benefits of the cloud. This article will explain the methodical approach to a successful cloud transformation.
A typical cloud transformation project has 4 phases. Depending on the current transformation stage of an organization, applicable phases must be applied including:
- Strategy and Portfolio Assessment
- Design and Planning
- Migration and Transformation
- Mange Operations and Optimization
This article will focus more on the first two phases i.e. "Strategy and Portfolio Assessment" and "Design and Planning ."The below picture depicts a cloud migration approach that is elaborated in this article.
1.Strategy and Portfolio Assessment
The objective of this phase is to assess the organization's readiness to cloud, define cloud strategy, conduct an application portfolio assessment, and define target disposition.
1.1 Cloud Strategy
Before arriving at a cloud strategy, it is important to understand the organization's current business objectives and priorities, current IT landscape, ongoing transformation initiatives, and technology strategies. Consider the following:
- Define cloud objectives aligned with the organization's vision, business, and IT strategy. Define how the cloud will enable the organization to meet its business objectives or new capabilities.
- Define the primary purposes of adopting cloud. For e.g digital transformation, data center exit, legacy modernization, replacing legacy technologies, launching new business services, improving agility, capacity bursting, cost reduction, improving resiliency, responsiveness, flexibility, or operational efficiency. Define KPI metrics with tangible and intangible benefits for these objectives
- Define the process method for cloud migration and transformation. For e.g Piloting before implementation to address a diverse set of workload scenarios, preference of migration in short sprints over the 'Big Bang' approach.
- Define cloud decisions with rationale, impacts, and benefits. Some of such decisions mentioned below:
- The decision on the selection of cloud service providers (AWS or Azure or GCP). Define the cloud topology if it's ‘private’, ‘hybrid’, or ‘multi-cloud‘. If it's a multi-cloud strategy, define the rationale for the selection of different clouds and what type of workloads can be placed against different clouds (e.g Analytics on AWS and legacy servers on Azure or vice versa).
- The decision on a container platform and containerization strategy.
- Cloud service model selection for application – e.g. SaaS is preferred over PaaS, then CaaS ( container as a service), and then IaaS being the last option.
- Define what cloud services ( IaaS/PaaS) are approved for usage against each cloud service provider. E.g. serverless computing features (e.g Lambda/Azure functions) may not be approved as an enterprise strategy due to various security reasons. Define the process of approval in case of using new cloud services.
- Define any decisions taken or under consideration for a replacement for packaged software or any enterprise applications using SaaS or COTS platforms.
- Define cloud adoption principles- E.g. enforcing standard technology stacks for migrations, applying DevOps principles, self-service, and cloud brokerage principles. Portability principles to avoid vendor lock-in. For example, enforcing Kubernetes based PaaS container platforms to support portability between clouds. "Infrastructure as code" principle to make deployment work on any clouds. Choosing cloud-agnostic databases than the native database. portability options between clouds (e.g. AWS to Azure or Azure to AWS).
- For data migrations like data warehouses or big data and analytics s platforms, a detailed data migration strategy is required either by using cloud-native or new age COTS data platforms.
- Define platforms for multi-cloud integrations ( e.g. using iPaaS and API gateway platforms).
- High-level cloud migration and transformation timelines.
- High-level change management processes like new roles, new skills, change in the deployment process, additional tests that may be required ( e.g. security/penetration's testing), and training needs for new cloud skills
- Define cloud adoption constraints, risks, and mitigations to enterprise - e.g Data security and regulatory constraints and impact due to ongoing strategic initiatives. IT service provider's exit criteria's like cloud subscription/account ownership transfer process. Cloud service provider exit criteria.
- Define cloud governance guidelines and guardrails- i.e. Rules and guidelines for meeting regulatory and compliance process, security guidelines, cloud migration project approval process, operation guidelines, and cost management.
- For datacenter exit strategy, define high-level data center (DC) decommissioning process
- Cloud Strategy is an evolving document. Many times various ambiguities would exist in the beginning. This strategy gets more refined during the design and planning exercise.
1.2 Application Portfolio Assessment
Conduct an enterprise-wide application portfolio assessment. This is required for defining an enterprise-wide transformation strategy. If such exercise is already carried out, then leverage these artifacts for further analysis. If the entire organization is not ready for the cloud, then plan for conducting an assessment of applications of business units that are ready for cloud transformation. There are 7R strategies for migration. These are Rehost, Replatform, Refactor, Rearchitect, Replace, Retain, and Retire. The outcome of the assessment phase is to provide one of the 7R strategies mapped against applications.
Applications need to be assessed from both top-down and bottom-up approaches. This phase involves gathering required application details by conducting workshops and by capturing responses to a set of questionnaires from various application stakeholders. Application and Infrastructure attributes can also be gathered from the configuration management database (CMDB) or existing Enterprise Architecture (EA) repositories. It's all about "knowing the current IT estate" of an organization. For enterprises having a large IT footprint, it is advisable to leverage automated application and infrastructure discovery tools for getting required attributes and application details.
The below table provides a brief description of 7R's. Post analysis, the application may fall into one of these disposition categories.
Identify the Life cycle status of an application. Filter the applications and infrastructure from the assessment list that are 'planned to be retired' in the near term or that are already 'decommissioned' from further assessment.
1.2.1 Data Gathering
Gather the attributes in the below categories for each application.
Application Attributes: Create an inventory with basic applications attributes like functionality, life cycle status of the application, business capability, supporting business unit, hosted location/geography, type of application (web/batch/middleware/transactional/analytics, etc.), Any planned upgrades or changes expected in the near future.
Business Value Attributes: How important this application is to businesses in terms of revenue generation or providing analytics reports or supporting operations. Capture Factors such as alignment to business strategy, current benefits, business criticality, redundant/duplicate functions of this application that exist in other apps, number of users, time taken to release new feature (agility), differentiation factor for the organization, user satisfaction, and the level of automation in this application.
The Total Cost of Ownership: Such as the cost of maintaining an application, Infra costs, and licensing costs.
Technical Value Attributes: Alignment of application to technology strategy, technical debt and performance of the application, ease of supportability, ease of integration, meeting modern technology standards, a current state on meeting non-function requirements (NFRs) like modularity, extensibility, scalability, portability, accessibility, maintainability, response time, recoverability, availability, performance, development and deployment methods, and the quality and accuracy of the data produced.
Risk and Compliance Attributes: Data privacy, security, and regulatory requirements, such as data confidentiality levels, data encryption requirements, application security requirements, organization constraints, local/regional regulation requirements like HIPPA, GDPR, PCI-DSS, etc.
Cloud Amenability (readiness): Check the technical feasibility of moving this application to the cloud. Factors, such as if the application has hardware dependency (appliance) or operating systems (OS) that are not supported in the cloud. If it’s a Packaged COTS app, check for supportability on the cloud. Is the application using legacy technologies like COBOL, C, C++, etc.? Or, it's using modern technologies? Check for database supportability on the cloud, such as hosted location i.e. if it's hosted in-house or through a third-party datacenter.
Complexity: Complexity that can impact migration to the cloud. Factors like distribution of application, configurations, number of hosts, database size, interface technology, number of interfaces (both inbound and outbound), topology/clustering requirements, load balancing needs, code complexity, ease of doing build/test/deployment, and usage of legacy technologies.
It is important to know the organization's cloud strategy, which can influence dispositions. If an organization has a data center consolidation or data center exit strategy within the very short term, then 'Rehost' and 'Replatform' dispositions check could be the first option for existing applications.
This is also applicable to organizations who require faster migration to some of their workloads and modernize the apps in later phases. There could be EOL (End of Life support) for underlying OS or software on which critical business applications are running. Such applications can be candidates for migrating to new software versions or OS versions on cloud where vendor support is available . Some organizations leverage cloud transformation as an opportunity for rationalization and "modernization" of their exiting IT. Some organizations may want to make the applications "ready for containerization" by refactoring into the supported container technology stack (e.g. Docker). Some take an opportunity to transform commercial applications/databases to cheaper open sources to save cost . Some might be looking cloud as an extension for additional capacity needs. Some organizations may look at the cloud for building new capabilities like data lake, analytics and machine learning.
Pharma companies may want to analyze a lot of data to find faster vaccinations for such a pandemic. The cloud can be used for experimentation as well (e.g Piloting/POC). Here is the quick decision tree based on cloud strategy:
As you notice in the above view, Rehost/Replatform strategies are having low risks and fewer migration efforts, but have fewer benefits. Remediation or modernizing applications can have more migration efforts but come with more long term benefits. It's important to assess migration risk vs rewards ratio per applications. Some legacy applications cannot be rehosted or re-platformed due to technology constraints, such application needs remediation (rearchitecting) to new platforms. It is beneficial to rehost "low value" applications on low-cost hardware instead of costly refactoring exercise.
Use data collected from questionnaires and other attributes as mentioned above to analyze the applications for 7R dispositions. Provide a weightage and scoring against attributes in each category. Weightage can be decided based on an organization's business strategy, e.g. time to market may be more important to business than providing user experience. Technical debt can weigh more than high availability.
Business Capability Heap Map: Define the mapping for each application against business capabilities. Identify rationalization opportunities like COTS license reduction opportunities, and redundant applications that can be merged or replaced, or applications/datastores that are too expensive to run.
Based on the scoring of business values, technical value, and cloud amenability, create various analysis models like the 'TIME' model. Charts like 'benefits vs ease of migration,' and 'Technical Value' vs 'Business value.' This would help in identifying potential "Quick Wins" i.e applications that can be migrated faster with low risk but can also provide cost benefits, as well as business value in short term. Sample Analysis templates are shown below:
1.3 Disposition and Recommendation
Create a decision tree and apply the values from the above charts to arrive at a target cloud disposition, e.g. an application with low business value, but high cloud readiness score can simply be 'Rehost' rather than spending efforts for 're-architecting.' Apps with no business value and of low technical value can be considered to retire or rehost on low-cost infrastructure. Apps with very high business benefits but having low technical value (i.e high technical debt) can be considered for replacing, refactor, or rearchitect options. Applications with both high business and technical value can be considered for either Rearchitect/Rehost scenarios based on long term benefits. Some IT service providers have developed analysis tools that maintain standardized scoring values and rule sets for fastening the analysis process. A sample decision tree is shown below:
At this stage, it may be useful to provide a high-level recommendation summary for the applications. Define the short-term and long-term recommendation against each application, e.g. the short term strategy can be 'Rehost' and the long-term strategy can be to rearchitect using a server-less compute sample disposition such as this one shown below:
1.4 Business Case
Once the High level assessment is done, conduct a high-level cost-benefit analysis for applications. Based on the on-premise infrastructure run cost, depreciation, and infrastructure operations cost, determine the total current run cost of the application. Get the expected spend in the next 3 to 4 years. Based on the disposition of the application and database, create an inventory of target infrastructure with proper instance sizing/instance types/storage/network components/PaaS /DbaaS services.
Determine the run cost of the application on target cloud for next 3 to 4 years. Determine the approximate migration cost. Determine savings in current infrastructure operation cost if moved to cloud. Use various cloud provider discounts, long term pricing plans benefits to arrive at the target cost.
Cloud investment will usually be realized in 2 to 3 years. Compare the cost of hosting on different clouds. Cloud provider's online TCO calculators/Monthly spend calculators can be used to arrive at the cost. Include the added intangible benefits like agility, elasticity, flexibility, and scalability features as part of the overall business case.
This business case exercise will provide the business owners and CxOs with decision points for initiating cloud projects. It is also important to include cloud optimization exercise once the application and data are migrated on the cloud.
1.5. Cloud Business Office
For successful cloud adoption and value realization, it is important to have effective strategic oversight and governance in an organization. Establish Cloud Business Office (CBO) that has C-level executives (sponsors), key business stakeholders, app owners, infrastructure leads, security leads, engineering leads, operations leads, procurement team, risk and compliance, and enterprise architects who would drive, accelerate and enable cloud transformation. CBO objectives are to define transformation goals and objectives, driving cloud strategy across the organization, providing budgets, architecture standards, change management, and initiate and govern cloud migration projects, tracking value realizations by measuring metrics and benefits.
Each of the roles will have either long-term or short-term responsibilities for supporting the CBO objectives and decisions around cloud adoption. Such a function or unit can also be called a Cloud Strategy office ( CSO) or COE ( Cloud Center of Excellence).
2. Design and Planning
In this phase, a detailed assessment of the application is performed and the minimum viable architecture is defined to implement the migration strategy. It is also possible to refine the cloud strategy in this phase .
Detailed Assessment: Analyze the application code/software that are planned for refactoring using code scanners. There are many commercial tools available to scan code for refactoring. Azure and Aws cloud also provide code scan tools e.g .NET portability Analyzer/Porting Assistant for .NET etc. There are also tools like AWS App2Contaner, which can even containerize apps and deploy them on the container platforms. Analyze the functionalities and code for rehosting, re-platforming, and rearchitecting applications. Identify any risks and blockers. This exercise will give a details required to arrive efforts estimation for cloud migration.
Transformation Roadmap: Define the migration plan based on the efforts and assessment done. Group the applications with common dependencies and databases. Define a migration for each of such groups. Grouping can also be done by organization functions/domains or technical capabilities (e.g. Webapps, middleware, core transaction systems, Bigdata, etc.). Prioritize applications by complexities. Plan migration of the applications that are of low risk ( "quick wins" ) and of less complexity to start with.
For example, simple web apps or reporting apps can be considered as early movers. Identify the Agile process methods and team structures . Identify number of migration user stories and sprints. Define the migration team structure and identify the right size of team by splitting it into Tribes and Squads. Some organizations may call them PODs structures.
Define the life cycle stages for migration, testing and Cut-Over plans for applications. Successful migrations will create templates for moving the remaining apps. Modernizing applications (rearchitecting or refactoring) may require more time and a long-term strategy. Apply DevOps and Agile methods( e.g. Scrum, SAFe ) for migrations.
Target Architecture: Define the target deployment architecture for the applications, data, and network components. Since the migrations are planned in an agile fashion, it's important to define the architecture (Minimum Viable Architecture) that is simplistic but adequate to implement the migration. Define the target technologies, software/OS versions, and database versions that existing applications and databases will be transformed during migration.
Consider database dependencies, interfaces, external integrations and data migration requirements for the applications. For cases where data and dependent applications going to reside on-premise, consider hybrid cloud architecture. This architecture will keep evolving during migration sprints.
Make architectural decisions, and get the stake holder's buy-in for such decisions. Design architecture with high availability, load balancing, and performance with the "fit for purpose" principle. After all, cloud is built for scalability and availability, hence avoid over-engineering. A sample of a hybrid-cloud architecture is represented below:
DevOps: DevOps has become the de-facto standard for every industry for any transformation and modernization projects. Each migration POD teams should follow DevOps process. For some applications (e.g. COTS), DevOps may be not relevant or can't be applied. Callout such applications in architectural decisions. Such applications can follow existing methods of build and deployment on the target cloud.
Define the tools that would be used for building, testing, deploying and monitoring apps on the target cloud. There are many cloud-native options available. Design the DevOps pipeline (e.g. using Jenkins/AWS code pipeline/Azure DevOps etc.). Consider code vulnerability scanning and security testing before deployments. Plan to automate the steps wherever feasible (e.g. testing). Define how the source code is managed and versioned (e.g. using Github repository and branching). Define how user stories are captured and tracked (e.g. using tools like Jira). Define the various environments that the existing application that will be deployed and tested before going live in production.
The migration process has to be continuous (CI/CD) and iterative for each application until the required testing KPIs are met. Define the application support process and how to monitor the issues post-production. DevOps teams are expected to own the application from code changes and deployment to operations.
Proof Of Concept (POC): Conduct a proof of concept in cloud. Whether it's a migration of application or data warehouse, piloting the migration in a cloud environment will give you the confidence, new learnings, and help in overcoming challenges. POC will help in identifying issues and gaps based on current organizational processes, connectivity, and environment dependencies. Apply DevOps process and tools while migrating, and pick up a medium complex rehost and refactoring application, such as POC, through which the majority of migration uses cases will be addressed. POC will help in refining target application and infrastructure architectures.
Cloud Infrastructure and Security Design: This is very important part of design phase. This is about defining the technical landing zone of the target architecture. An example of an AWS landing zone will include network components like the number of VPCs, connectivity from the datacenter, inter VPC communications, subnets, Route 53, ELB, API gateway, etc.
Compute and storages like EC2, EKS, ECS, RDS, SQS, S3 etc. Security components like IAM groups, users' groups, IAM policies, AD SSO for existing enterprise users, security groups and port controls at network levels. Define tagging (labeling) rules for components. Access control mechanisms for environments, including databases. Define the infrastructure using the infrastructure as a coding principle. Leverage new-age tools like cloud-native infrastructure creation services or cloud independent open sources like terraform. Design the integration with DevOps tools to easily create and destroy infrastructure. This design should address below areas:
Cloud infrastructure components and services; Integration layers; Bigdata and analytic components (if applicable); Network Connectivity; Hybrid cloud network connectivity topology (define location/region-wise connectivity to data centers and external clouds); High Availability design; and disaster recovery approach.
What a Security Architecture Should Address: Access and identity management (e.g. AD integration, AWS account and organizations); Security controls and process of accessing environments/applications and databases; Security auditing and monitoring (e.g. SIEM integration); Data security and encryption; and Assessment of vulnerability/patch management process.
Cloud Operating Model: Cloud operating model is all about how the organization will implement it's cloud transformation. It consists of people, processes, and tools. "People" are critical in driving the successful cloud programs.
Identify stakeholders, team structure, and roles that are aligned to cloud business office, business /domains, operations, security and DevOps. Identify application and data governance processes and policies. Identify compliance requirements and ways to address them.
There can be strategy to either create centralized, de-centralized or shared operating models. De-centralized operating is the preferred model, as it provides more agility and cost management. However, there could be other limitations of such model. For more details, refer to Azure documentation on operating models' comparison documentation.
Change Management: Cloud transformation requires adapting to changes in process technology and tools. There will be changes in governance and infrastructure controls. Address the new changes required in different roles that existing teams might have to take-up. Plan for re-skilling and cloud training for staff. Create a plan for addressing gaps in new required skills.
Cloud migration is mainly a technical change. Many organizations involve a changing of the advisory board (CAB), which is responsible for reviewing and approving such transformation changes. The traditional CAB approval may pose a hindrance for migrations unless the right engagement was done with stakeholders well in advance. It would be worthwhile to consider enterprise change management tools ( e.g. ServiceNow, BMC, Jira Service desk, Freshservice, etc.) for governing and controlling the overall cloud migration process.
There are tools available to complete access control the environments, provisioning, billing/cost controls, security monitoring, incident management, release management, and change management and approvals process. Alternatively, use cloud-native services, such as AWS Config, CloudTrail. The service catalog, AWS console, AWS Organizations, trusted advisor, etc. ) along with enterprise tools to achieve these tasks.
3. Next Steps
The next step is "Migrations and Transformation." Deploy POD teams, migrate applications and data as designed, and plan in previous stages. The "Manage and Optimize" stage is about managing ("RUN") infrastructure, applications, and data post migrations on the cloud. We will address the detailed implementation process, monitoring, and cloud operations in the next article.
- the-cloud/ https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/organize/cloud-center-of-excellence
For further information and copyrights on this article contact here.
Published at DZone with permission of Sandeep Tol. See the original article here.
Opinions expressed by DZone contributors are their own.